String control formatting doesn't work when string control is on a hidden tab page

[m3nth]

Problem Overview:
To display help to the user a help display will be on it's own tab page. Each help display should be loaded and pre-formatted on program startup from a text file that is tagged with a limited number of formatting tags such as: [B], [/B], [U], [/U],[Size=20], [Size=12], etc.

Help panels will be loaded on program startup before the tabs are ever displayed... they will be hidden by default with the functional tab page set as the default page so when they are enabled, the user will see the functional stuff and only click over to the help tab page if they need help.

The code I have works fine for the tasks described above, but in some circumstances, LabVIEW does not apply formatting to the string control correctly when it is not visible. I am looking for a workaround to get LabVIEW to apply formatting correctly without displaying the string control to the user.

See attached code... once again, I am looking for any way to pre-format a non-visible string control that is in it's default (empty or blank) state when the VI is loaded.

[altenbach]

I agree this looks like a bug. Have you reported it to NI?

[JeanPierre]

Did you try to set the control property Advanced>>Synchronous Display? That forces the control to be updated at every change, I assume even if the control is not visible. What you see is a bug, LabVIEW failed to properly update the control, but the synch display might be a workaround (I don't have 7.1 mow to test it myself).

[altenbach]

I actually played with synchronous display (one of the first things I tried before posting the above ;)) and it does not make a difference. He only writes the string via a value property, so I also tried to write directly to an indicator (synchronous display) in a closed sequence before changing the text attributes. Still no go if the indicator is not on the frontmost tab. 😞

[Ben]

Hi M3nth,

You said "I am looking for a workaround to get LabVIEW to apply formatting correctly without displaying the string control to the user.
"

I can confirm the case 1 part of this BUG. I did not try out case two because the attached seemed to fix the case 1 problem.

I the attached VI (LV 7.1) I first defer front panel update and then note which tab is currently selected.

I then set the tab control to "page 1" (remember FP updates are defered so user does not see this) before applying all of the properties in the same order as you example using a single property node.

After that I set the tab back to the way it was to start and un-defer FP updates.

NOTE:
The above only works if you also invoke one of the two following additional actions.
1) Set the string as "syncronous"
or
2) Set the property node to "ignore errors inside node"

I hope this work-around gets you past this issue.

Thoughts on what we are seeing.

Since the syncronous setting is required, it looks like we can only select text offsets within the text field in the string AT THE TIME the selection is applied. The syncronous setting ensures the string is there before we select the offsets.

The ignore errors work-around is a little troubling in that I never saw an error running your example, so there are either "hidden errors" that affect the property node if not set for "ignore..." or that setting lets us do illeagal things like selecting text offsets that do not exist.

Please chime in if you think you can shed more light on this issue.

I hope this helps,

Ben

Message Edited by Ben on 06-25-2005 08:07 AM

[m3nth]

I doubt I will have little light to shed on this matter but to complicate things further 🙂

With your example when I:

- Open the VI you attached as-is, (string is not synchronous update, property node is set to ignore errors)
- Select Page 2
- Run the VI
- Select Page 1: String control appears formatted correctly

The interesting thing is, about half the time I do the 4 above steps, I see the String control flash on Page 1 (which is supposed to not happen with panel updates deferred?)

Undoing the Ignore error option that was set for the property node gives me similiar results:
- It's hit or miss whether I see it flash on the FP
- The string still formats correctly

Undoing the Ignore error and then setting the string to synchronous also gives me same results as above. In all cases, I am closing then opening the VI (since that's easiest to re-initialize it and my VI's will be opening like that for the first time).

So you noted that your workaround only works if one of the two things was enabled, string=synchronous or ignore errors=true, but if you were talking about having the text formatted correctly, it always worked for me no matter what those settings were, and the FP (page 1 string control) flashed on random runs also regardless of those settings.

Now to explain why this is all a little more complicated than it appears from my example:

I am working with a very large program with hundreds of controls, some in VI's that aren't open, and most which are on tab controls which are on other tab controls, which are not visible at startup. Don't think I didn't try what you did... changing the tab control to the correct value then updating... it works good enough if I don't care about the string control flashing every now and then (which I don't--that's a minimal issue). The problems of course are:

- To find the control references to fill in with text, I am searching for the matching control label in the VI of interest (using a static VI Ref or ref opened by name). With the function I use, in goes the control name, out comes the reference. So to work with the tab control I have to back up the chain to the page reference, then to the tab selector reference, then see what page the control is on, and use that for setting which page is active (not impossible, but complicated).

- If the tab controls aren't visible then it doesn't matter if you make the active tab page the one with the string control, it still won't work because it's not being displayed on the front panel. To reproduce this just make the tab control not visible, run the rest of the workaround program you posted as-is, then show the tab control again (no longer works right)

- Even if I could traverse the reference chain and make each tab control visible what about when the control is in a loaded VI that isn't open? I'm guessing it won't work, based on my experiences so far. To get the string control displayed I would have to open the front panel, open the tabs, then set everything back, button it up and close the VI's FP... probably difficult at best and not pretty.

I guess what I was really looking for was something I could set or write to the string, some function or chain of properties I could set that would get it to update right without having to find some way to make it show up on the front panel so it will update (given my hidden controls and situations where they're in unopened VI's). I tried so many different combinations of stuff before I posted that it finally drove me insane enough to see if anyone else had ideas 🙂 The stuff that's been posted so far has been great though--I was surprised that so many heavy hitters have weighed in and I appreciate it a lot (Thanks guys!) At this point however, after messing with it for several days I'm starting to wonder if it's possible given the complexity of the whole thing and in the end, if it's worth it, given that basically all I'm trying to do is make a text box look pretty (er, professional) :).

[Ben]

OK,

I think that example uncovered another short coming in the FP Panel update deferment.

Forget that idea.

The attached does not use "syncronous", "ignore ....", or "FP deferUpdat".

Your follow-up inspired me to try to force LV to take a closer look at the string control AFTER it was written and BEFORE the properties were manipulated.

I used an invoke node to do this as illustrated in the attached VI (LV 7.1) and jpg.

Please try this approach in your application and let us know if that helps.

Ben

PS Ignore comment in jpg and pretend I wired the error cluster through

Message Edited by Ben on 06-25-2005 11:42 AM

[m3nth]

It works!!!! Yipee!!!! A winner for sure.... 🙂 Even when I hide the tab control, so I'm pretty sure that once I get the solution integrated back into my app that it should function properly.

That's probably the last thing I would have come up with but it does seem to function properly... Bravo and a five star rating for that solution!!!

[Ben]

You did say
"I guess what I was really looking for was something I could set or write to the string, some function or chain of properties I could set that would get it to update..."

Proverbs says something like

"As face answereth to face and iron answereth to iron, so does a man trieth words."

Please post after your integration testing.

One way or another, I still think there is a BUG here! Probably a race condition in the setting of the controls value and setting of attributes. This work around just isolates the two operations.

Ben

[TylerS]

I took a look at this problem and definitely agree that something is obviously not expected in the way it was working. I wanted to let you know that I submitted this to R&D and they will look into it and determine what is happening to cause the behavior. As always, thanks for helping each other out!

Tyler S