LV Bug? Why does the button blink?

[CoastalMaineBird]

I'll repeat an interesting fact: the blinking DOES NOT happen if I DISCONNECT from TYPEDEF.

On my machine it lasts 0.2-0.3 sec sometimes.

That's not drawing speed.  That's drawing when you don't have to.

[JÞB]

Take a peek at the export strings with the Type def connected and disconnected

[CoastalMaineBird]

Take a peek at the export strings with the Type def connected and disconnected

OK, I figured out how to export strings, and I see differences between them, but nothing that means anything to me.

Can you be more specific?

[JÞB]

Sorry Steve, I didn't mean to sound Offensive or obscure.

the export strings hint at some GUESSES I have about how the IDE operates.  LabVIEW is allways looking at the code (to see if it needs to break the run arrow) and the compiler would be digging all the way through the extra layers that a type def can affect, hence more indentations in the export strings with a type def.  the Complier would optomize this a run time so there is much less overhead than when dealing with the FP from the IDE since more object properties are available during development and there are no vi server referances so there is probably no compiled code where those properties aren't CONSTANTS.

Add to that the (sometimes) painfully slow performance of the XML parser in LabVIEW and I begin to guess that there is some voodoo under the hood delaying the fp update.  Possibly related to compiler optomizations taking the time to examine the code when you change how the IDE presents the FP.  We know already that Latching Booleans have some voodoo under the hood and maybe that is why the effect is visable more often on boolean types

I AM Totally looking through mud here but - maybe this is closer to an undesired secondary effect (annoying) than a bug (incorrect behavior).

EASY enough to work-around if you disconnect type defs in the build spec.  (Now, I suspect I know why that option got in there and will use it more often)

[CoastalMaineBird]

No offense taken, but guessing is not my strong suit today.

I'm building an EXE now, so I'll test your speculation in a bit ( it takes 15+ minutes to build - whoops - it just failed with the generic I/O error again. Time to reboot, I suppose).

If it was simply slow redraws, I would point out a couple of things.

It never happens on the row LOSING focus, only on the row RECEIVING it.

I would think that it needs to redraw both.

Also, there really is no need to redraw the button, just because I clicked on a numeric field in the same cluster as the button.

But that's all speculation, and my mud is no clearer than yours.

BTW, use care when you disconnect TypeDefs in EXE files.  If the TypeDef is Large and there are many instances, you can bloat your EXE.

When you disconnect, you force every control to carry around its own copy of the descriptor, rather than using the central copy.

[JÞB]

If it was simply slow redraws, I would point out a couple of things.

It never happens on the row LOSING focus, only on the row RECEIVING it.

I would think that it needs to redraw both.

<<<<< LabVIEW already has a handle to the row losing focus and needs to obtain the info for the row gaining- One clue but, not enough to find root cause

<<<<I'm GUESSING the entire control is redrawn.  Since it is type def'd, the entire control may need refresh.  We could test this by type def-ing the ARRAY and see what happens but, I'll leave that for another day.

you can bloat your EXE.

<<<<<<<THANKS for the tip. 

That makes three things I learned from this thread.  Glad I took the time

[CoastalMaineBird]

FWIW, building the EXE makes the problem go away.

I don't know whether your explanation for HOW it happens is right or wrong, but it looks like I don't need to worry about it, as my client will be using the EXE anyway.

Thanks for the ideas.

[JÞB]

---

@CoastalMaineBird wrote:

FWIW, building the EXE makes the problem go away.

I don't know whether your explanation for HOW it happens is right or wrong, but it looks like I don't need to worry about it, as my client will be using the EXE anyway.

Thanks for the ideas.

---

NIETHER do I but, its what can be considered a "working" hypothosys.  It may be based on speculation and erroneous but, provides a basis to predict results.

<sea story time>

Back in another century I was learning about electronics.  My classmates and I noted that Lamps are designated on schematics as "DSx"...and tried to find out how that made sense.  We derived that Lamps do not emit light (or they would designate as LEx for light emittors) and, in reality they may  suck darkness and DS meant Dark Sucker.  This working hypothisys explained many phonominae related to light bulb that we can observe:

• When "Full" they stop working and even have some residual dark deposited on the bulbs interior.
• Shadows are caused because they can't suck the darkness behind a barrier.
• since Black is the presence of all pigments- this model simplified color filters for dark suckers over the light emission model....

In point, this working hypothisys does not fail until you use experiments with observations beyond the capabilities of human senses... e.g. testing for the presence of Tungston depositions on the inside of "full" bulbs.

Certainly I'ld like to know the "truth" - Call me pedantic!  but we derived the closest thing with the information available and that is sufficeint to the scientific method.

Interesting phenominae should always be explored

[JtotheB]

Hey CoastalMaineBird,

I'm pretty sure that is just a redraw artifact. As far as the asymmetry between the behavior on something that loses focus, and something that gains focus, I think we can attribute that to the event structures in your code. I would imagine that many of your events check for focus or activity, rather than losing focus of the control, thus the asymmetrical redraw behavior. I'll show your screencast to some developers and see if I can get a more specific answer for you, but I'm confident that redrawing is the cause of that behavior. Have a great evening!

[CoastalMaineBird]

 I think we can attribute that to the event structures in your code. 

I don't think so.  That seems completely off the mark. It's not about events in my code.

Read point #3 in my original post again:

3... IT DOESN'T MATTER IF THE PROGRAM IS RUNNING OR NOT.   (!!!)

Also read point #4:

if I disconnect the array's cluster from the TypeDef, the blinking doesn't happen anymore.

If it's my code that's doing it, it seems strange that it doesn't have to even be running.

Also, it wouldn't change when I build an EXE.