Text Area Slower Than Text Field

Hi,

I am having a problem with the Text Area (Xojo 2014 V2) when the app is compiled in Cocoa. I am loading text from a SQLite database file and when I have more than 3 Text Areas, one lags behind the other three when loading text. Its visually annoying and I was wondering if anyone knew how to fix this.

When you compile for Windows or for Carbon, the problem does not happen. All text loads at the same time. When you have a Text Field and a Text Area loading the same text the Text Field loads the text at a much faster rate and all at once.

I made two videos showing it. The first is a Cocoa compile and the second is compiled under Carbon. The smaller Text Fields are Text Field controls. The larger ones are Text Areas. You can see the the Text Fields load quickly, while the text areas lag.

Cocoa:

link text

Carbon:

link text

Is there anything I can do about this? To me the lagging is very annoying and makes the app look a little bogus.

I was wondering also if there is a way to make the Text Field so it can text wrap and be multiline?

OR are there any Third Party Text Controls that may not have this problem? I would not mind paying for a third party control if it can correct this problem in Cocoa.

Any help would be greatly appreciated.

Jim

If you set the Text property of 4 different TextAreas with string variables copying a text file dragged into the project, the lag is probably around 1/4 second for an 11k text.

What I see in your movie is probably the result of the SQLite data fetching.

The best route is probably not to load directly the text into the TextAreas, but to use shadow variables (seems your text is not styled so simple string variables ought to do), and wait until the data fetching is finished to update all the TextAreas at once from the variables.

While the text is loading you can display a some Progress control. Simplest is a ProgressWheel and a short message such as “Loading …”.

The textfields load quickly because they are only one line. If you look at the first line of TextAreas, they tend to load very fast as well.

Thanks Michel for taking the time to help me. I played around with this a bit more. Its not a result of SQLite database fetching. Its the control itself. Also loading the SQL data in a string first and transferring it to a Text Area did not help either.

This shows the best what happens ----
I made a project with 8 Text Areas. Four of them, I loaded text. The other four are empty. You click a button and the text loads from the text boxes on the left to the text boxes on the right. No database file involved. You will notice that the 4th Textbox lags behind the other two. This happens all the time. If you change the position of the lines of code, the 4th line will cause the lag. See code below:

txt44 will lag with this code:

txt11.Text=txt1.Text txt22.Text=txt2.Text txt33.Text=txt3.Text txt44.Text=txt4.Text

txt11 will lag with this code.

txt22.Text=txt2.Text txt33.Text=txt3.Text txt44.Text=txt4.Text txt11.Text=txt1.Text

I uploaded the project file which can be downloaded at:

Project File

I also made another video of what happens. That is here:

Movie File

Again, this does happen when you compile to Windows, no does it happen when you compile to Carbon. Just Cocoa. It has to be a bug. This is not great since Xojo is now retiring Carbon. The Text Edit control is a common control and have it not working right is not wonderful.

Does anyone know of a third party Text Control I can use? I am not sure whether or not BKeeney’s Formatted Text Control would work either. I am going to try to find out. Does anyone else have a text control for Xojo? I can’t seem to find one.

Any help would be greatly appreciated.

Solution :

  txt11.Visible=false
  txt22.Visible=false
  txt33.Visible=false
  txt44.Visible=false
  
  txt11.Text=txt1.Text
  txt22.Text=txt2.Text
  txt33.Text=txt3.Text
  txt44.Text=txt4.Text
  
  txt11.Visible=true
  txt22.Visible=true
  txt33.Visible=true
  txt44.Visible=true

Tested and works just fine. And yes even though it looks like that would “flicker” it doesn’t because the window is not refreshed until the end of the method.

I would however suggest in a case like this to convert to a ControlSet instead of 8 names TA controls… makes it easier to code for

and isn’t it “The QUICK Brown fox jumped over the lazy dog?”

Frankly, I am amazed how slow TextArea updating are, for such small amounts of text…

I have a solution not unlike Dave’s one.

tabug2.xojo_binary_project

What I did to modify your project is to place a white rectangle over each TextArea, with a width and height 2 pixels less than the TA, placed to come 1 pixel lower and 1 pixel to the right, so it masks the content of the TextArea.

In the button that copies text, after text has been copied, I turn the rectangles visible False, and the text appears instantly. In the Clear button, I make the rectangles visible again.

This has nothing to do with improving the speed of the TextArea load. Simply, I mask the lagging load until everything is ready, and I lift the curtain. Voila !

Smoke and mirrors, but it looks much faster to the user. Maybe that will be enough to alleviate your UI problem.

You may use a Textfield instead of a TextArea, because they are multiline, but you will have to manage yourself the wrapping. It may end up just as slow as a TextArea.

I have no idea if FTC could be faster. As far as I understand it is based on a canvas, so technically it is different to a TextArea. But will it be faster ? Maybe you can ask Bob Keeney.

Dave, You are a genius!!! Thanks so much for your help!!! I really appreciate it. That fixed the problem. I was trying to figure out what was going on for the last 24 hours. It was getting really frustrating. That really helped, and there is no flicker.

Yeah your right about the Quick fox, not the Swift fox… I don’t know what I was thinking… Must be from the lack of sleep. :slight_smile:
Your also right about the control set. It was just a quick example I whipped up.

Thanks again.

Hi Michel,

Thanks so much for taking the time to help. I really appreciate it!!! It basically does the same as Dave’s. They both work flawlessly. A great solution to a problem I could not figure out.

Thanks so much again. I don’t know what I would do without all the kind help I get on this forum. Its terrific! It keeps me in business.

This may of some help as well, from the old Real Studio blog. “Speeding up TextArea modifications under Cocoa”:

http://www.realsoftwareblog.com/2012/11/speeding-up-textarea-modifications.html

I don’t program much on the Mac, so I can’t say it helps, just seems like it is related.

[quote=115433:@Merv Pate]This may of some help as well, from the old Real Studio blog. “Speeding up TextArea modifications under Cocoa”:

http://www.realsoftwareblog.com/2012/11/speeding-up-textarea-modifications.htmld.[/quote]

Was also mentioned in the latest issue of xDev (formerly REALbasic Developer Magazine - see http://www.xdevmag.com/about.shtml), where the Tips&Tricks column was devoted to “Speed Tricks” :wink:

[quote=115427:@James Redway]Hi Michel,

Thanks so much for taking the time to help. I really appreciate it!!! It basically does the same as Dave’s. They both work flawlessly. A great solution to a problem I could not figure out. [/quote]

The principle is the same : update behind the curtain, then lift the curtain. But in Dave method, rendering the TextArea entirely invisible maybe a little strange to the user. Especially when you simply want to clear the text. Hiding the text zone without hiding the entire control looks probably more natural.

Hope it helps.

You may want to check the link Merv Pate posted, though. It looks interesting for Cocoa.

Why add more controls to hide the TA… when VISIBLE does the trick… as mentioned… you do not notice any change in the visual aspect of the display, because by the time the window/controls refresh … VISIBLE is back to true again

Oh. I did not realize the change in visibility did not reflect because refresh had not occurred. Nifty ! Congratulations !