LabVIEW Development Best Practices Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Update on typedef triggering re-compilation in LV2012

Solved!
Go to solution

AristosQueue wrote:


Why are you surprised?

I'm surprised that this would be considered a good idea when strict typedefs were created. I'm surprised that this final (in terms of the stack of decisions made to get to the what the user/dev sees) behavior is still allowed in 2014. I'm surprised that you're defending it in any way.

0 Kudos
Message 21 of 44
(2,060 Views)

AristosQueue wrote:

If it is a strict typedef, all the size and layout computations of the front panel have to be redone when the display font changes. That's a huge, time intensive process, and it triggers a docmod. It's worked that way since strict typedefs were introduced almost two decades ago.

Another reason I haven't used a Strict Type Def in at least 5 years.  Strict Type Defs are good for GUIs, but that is it.  And I say they are limited with that. Just use Type Def and this won't be an issue.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 22 of 44
(2,060 Views)

It would be great if there were some way to separate the view from the underlying data type.  In a nutshell, this idea requests the ability to create multiple views for the same type such that the developer can assign any one of the views to a given panel instance.  The font issue could be handled however it's handled today with non-strict type defs.  There really wouldn't be a need for stricts.


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Message 23 of 44
(2,060 Views)

I agree with crossrulz, we avoid strict type def's. I almost never use them anymore, even for GUI stuff.

QFang
-------------
CLD LabVIEW 7.1 to 2016
0 Kudos
Message 24 of 44
(2,060 Views)

David Staab wrote:

I'm surprised that this would be considered a good idea when strict typedefs were created. I'm surprised that this final (in terms of the stack of decisions made to get to the what the user/dev sees) behavior is still allowed in 2014. I'm surprised that you're defending it in any way.

What functionality would you expect? You specifically designed something that says "update all the UIs when I change" and then you used a font that is system dependent and then you loaded it on a system where it changed -- exactly matching your request. I'm not only defending it, I'm saying that's exactly what the feature was designed to do and if you wanted different behavior, why are you using a strict typedef with a system-dependent font?

0 Kudos
Message 25 of 44
(2,060 Views)

AristosQueue wrote:

What functionality would you expect?

I want a data typedef and not a display typedef. Or the other way 'round. Stricts in LV are both. I see no benefit to mixing those functions.

0 Kudos
Message 26 of 44
(2,061 Views)

AristosQueue wrote:

But one developer pointed out that in all probability, when you load a hierachy that "hasn't changed" on a new machine and you get docmods, if you then ask "which typedef is responsible for this change?" the answer is likely to be "all of the strict ones." That's because one of the biggest reasons for this sort of change is the fonts. If the system fonts are different between two computers, that generally impacts the strict typedefs, and they all then push changes out to all the VIs that depend upon them.

Brilliant. AQ, you...that's just beautiful. I mean it. I hadn't ever considered that and it makes sense.

I usually stay away from strict typedefs, but I know my partner in crime here uses them extensively. Upon further investigation his re-use libraries are littered with them. Maybe, just maybe, that's the reason. It'll take time to sort this out (assuming there's no reason for strictness) on our large project but a plausible explanation for this has given me hope on an aspect of LabVIEW which has dogged us for years.

Seriously, the problems when dealing with SCC have been my biggest criticism of LabVIEW for large application development. Yanking the compiled code from the VIs was a huge step in the right direction, and this typedef thing is the only outstanding issue in that department. If it's as simple as strictness...I can only hope that's the case.

Message 27 of 44
(2,061 Views)

David Staab wrote:

I want a data typedef and not a display typedef.

Then don't use a Strict Type Def.  Just use a standard Type Def.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 28 of 44
(2,061 Views)

This font thing is new to me.  I had no idea.  So, since I rarely use strict typedefs, I just did a search of my offending code and found that I had no strict typedefs in *my* code.  But, I found one in an OpenG function I was using and 5 from vi.lib.  Of those, 4 were because of the Simple Error Handler and one was from the Get System Directory function.  Not sure how I can fix this if the problem is coming from within NI...

FWIW, i was unable to determine why any of these wold be set to 'strict' as they appeared to only be of the 'data' type and not for display.

-John
------------------------
Certified LabVIEW Architect
Message 29 of 44
(2,061 Views)

jlokanis wrote:

This font thing is new to me.  I had no idea.  So, since I rarely use strict typedefs, I just did a search of my offending code and found that I had no strict typedefs in *my* code.  But, I found one in an OpenG function I was using and 5 from vi.lib.  Of those, 4 were because of the Simple Error Handler and one was from the Get System Directory function.  Not sure how I can fix this if the problem is coming from within NI...

FWIW, i was unable to determine why any of these wold be set to 'strict' as they appeared to only be of the 'data' type and not for display.

Rings.  The SEH uses rings instead of enums.  I'm guessing that it was made before LabVIEW had enums.  Therefore they had to use rings.  You need those to be a Strict Type Def to make sure the values and items don't get changed on you.  I say Stephen should make a CAR for that.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 30 of 44
(2,061 Views)