Preserving font properties after concatenate string and updating control

[BowenM]

Is there a better way to do this?  My method is unusably slow.  I have played with several options (making assumptions about words separated by space having same font info, etc), but I haven't really found anything I'm happy with.

[JÞB · Accepted solution]

Defer FP updates method.  You are updating the text properties character by character. dump them all into the transfer buffer and update them all at once.

[mikeporter]

Why are you updating things one character at a time? What is it that you are trying to do? Where it s the string coming from?

Mike...

[JÞB]

---

@mikeporter wrote:
Why are you updating things one character at a time? What is it that you are trying to do? Where it s the string coming from?

Mike...

---

Did I not say that?  

I do miss saying what I mean to say sometimes.. Go "get-r'done" Mr. Porter

[BowenM]

---

@mikeporter wrote:
Why are you updating things one character at a time?

Mike...

---

Can you think of a better way to preserve font properties within LabVIEW?  I tried updating one "word" at a time (separated by a space), but that overrode fonts in rare cases.

I hadn't tried defer FP updates though. It should speed things up for the 2nd for loop while I update the fonts, but not the first while I read font information.

[JÞB]

---

@BowenM wrote:

---

@mikeporter wrote:
Why are you updating things one character at a time?

Mike...

---

Can you think of a better way to preserve font properties within LabVIEW?  I tried updating one "word" at a time (separated by a space), but that overrode fonts in rare cases.

I hadn't tried defer FP updates though. It should speed things up for the 2nd for loop while I update the fonts, but not the first while I read font information.

---

Try it

[Hooovahh]

Huh, I guess I've never had to do this before so I can see why this might be an issue.  Use defer as others have said will improve speed a bit.  Another possible improvement is to see if the font is the same from one character to the next, and then if it is when you set the font back, you can do so more than one character at a time.  Again this might help a bit but still requires reading font settings one character at a time.  This just helps because the set can be done in sections.

The unconventional method might be to use something like LVMark.  It's a text markup language that applies font changes.  To do this right you'd need to keep in memory the original string that made up the markup string, then append to that the new string including the markup text, apply it, and keep that for next time.  Certainly not ideal, but it won't involve charater by character font reading.

[Matthew_Kelton]

Deferring updates will help tremendously.  I wasn't quite as granular as you, but saw tremendous improvements when I was color coding status messages.

What you can also do is store the font properties array.  This way you are not constantly re-reading the properties.

[Hooovahh]

Okay so I did a speed test on some methods.  All of these methods are semi flawed because updating the UI might be done asychronously and the timing might not be exact but I think it gives a rough idea of the improvemetns possible.

The first method is your and in my test took roughly 0.3seconds.  I then added the defer and undefer and got it down to 0.04seconds.  I then added code which would set the font in batches, but still have to read each character one at a time, I also added the defer undefer, and this method took 0.02seconds.

So if you just go with defer undefer I think your improvements will be enough.

[BowenM]

I ended up going with a combination of defer updates and storing the font properties in a shift register to make it quick enough. I didn't realize defer updates would make THAT much of a difference...  thank you.