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

crossrulz wrote:

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

And if I want to control aesthetic appearance without fixing the data structure?

0 Kudos
Message 31 of 44
(1,090 Views)

Fair enough, but would it be so hard to get an intern to rewrite it sometime in the last 10 years...

I wonder if I could somehow get both of my systems to have the same fonts.  Since they are both Win7 and based off the same image and I have not customized them in anyway, I am curious as to why they would be different.  I am not conviced they are different.  This could just be another red herring.

-John
------------------------
Certified LabVIEW Architect
0 Kudos
Message 32 of 44
(1,090 Views)

As a side note, if you use use the 'Control VI Type' property to only find 'strict typedef' it considers all class private data controls to be strict.  So, I guess my previous comment was incorrect as I have many of those types of controls. 

-John
------------------------
Certified LabVIEW Architect
0 Kudos
Message 33 of 44
(1,090 Views)

Years ago I set LabVIEW to use Tahoma as the default font for everything.

Options > Environment > Fonts

Every time you place a control its font is Tahoma, not system, not application, Tahoma.

I was sick of my UIs being mangled because a user decided to change their system.

You take 1 hit in source control when you go though and make the change in all the existing typedefs, but it seems it may be worth it.

Thank you all for sharing your observations in this thread, it turns out this also prevents strict typedefs from wanting to update when moved to another PC etc.

Seems like setting all fonts to be something other than system or application may turn out to be another item on the "best practice" list.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
0 Kudos
Message 34 of 44
(1,090 Views)

Wow - thank you for this!!!  This explains an issue thats been driving me nuts but I have not yet had time to fully investigate!!!

0 Kudos
Message 35 of 44
(1,090 Views)

jlokanis a écrit:

Not wanting to thread-jack, but I will answer your question.  I stopped using SCC while developing LVOOP (and specifically LVOOP based command pattern messaging) because of how often I am creating new classes, and new VIs and then renaming them.  I realize this is due to lack of a detailed design, but I tend to only put my concepts down on paper and leave the implementation details to the coding work.  As a result of this, I find that I tend to add/remove/rename the private data elements often while creating a class.  I then need to cleanup the accessors I already created.  I also often rename a class.  And I often move it on disk after renaming it, since I want my file layout to reflect my code structure where possible.

All this churn at the file level is a nightmare for SCC integrated into the IDE and even if I just turned that off, It is still a mess to deal with between commits.  I would be constantly deleting from SCC and adding the new version with the new name.  Since I really do not care about the history of the code when it is a fresh project that is seeing a high level of change, I decided that I could live with an old school method of simple code backup.

Once my project is stable and working, I will check it all into SCC and then use that for maintenence.

That's quite an interesting and pragmatic approach, as for me, in the initial phase of development I still do SCC, with pretty big commits.

Back to the original point, can you share with us the triggers that cause LV to think the typedef was changed?  And can you request an enhancement to at least tell us which typedef LV thinks changed?

I guess the main case for me is VIs that take typedefed clusters as inputs/outputs argument. I've got many of this in my project.  This might be mitigated by moving them to classes, but it means creating a lot of additional VIs, one per cluster element for accessors. I know that it's mostly automated by LabVIEW, so it's not a problem of time. It's just that I'm reluctant to this massive creation of doing-nothing files...

0 Kudos
Message 36 of 44
(1,090 Views)

AristosQueue a écrit:

CharlesB64 & kegghead:

I went to talk to the development team. Although 2013 cleared up a lot of issues, we are continuing to work on the typedefs as a pain point. Our lead developer on typedefs believes that both of your complaints should be substantially improved and possibly even addressed in LabVIEW 2014. Please go to ni.com/beta and register for the LV 2014 beta if you'd like to evaluate whether that upgrade has the fixes you need. I am fully aware that upgrading LabVIEW is not possible for everyone and sometimes us saying "it's fixed here!" is not a viable solution. I'm trying to offer what help I can.

Thank you AQ, will test this as soon as I'm approved. Glad to here that it's taken care of, and thanks everyone for insightful digressions

0 Kudos
Message 37 of 44
(1,090 Views)

crossrulz wrote:

I'm guessing that it was made before LabVIEW had enums.  Therefore they had to use rings. 

No. It is because rings are localizable without triggering recompile and enums are not. Because we localize our VIs for the local display, we most frequently use rings where most people would use enums. In recent years, you've seen more APIs that use enums because some of us feel that the loss of localization is worth the gain of the fixed strings instead of magic constants as the APIs have gotten larger, but they aren't common and we generally have to argue for them on a case-by-case basis. The non-English users really don't like us using enums ever.

Message 38 of 44
(1,090 Views)

David Staab wrote:

And if I want to control aesthetic appearance without fixing the data structure?

If you want to control the aesthetics, you're going to take the docmod hit when those fonts change regardless of whether data type is tied to it or not. The separation of data type and display is totally orthogonal and unrelated to the current discussion.

0 Kudos
Message 39 of 44
(1,090 Views)

Strict type definition also precludes the use of rings and combo boxes which feature programmatically configurable items and values (e.g. load valid P/Ns from file at run-time).

Because ring items are by design not part of the ring data type (type = numeric-only), ring items are considered part of the view.  Placing the ring in a strict cluster for example locks its items, defeating the purpose of the ring in most cases (i.e. configurability).  A workaround I've used in the past is to use a plain type def and temporarily change it to a strict when I want to update all instances to the new view, but I doubt that mitigates the docmod VCS issue.

Since the current strict implementation has the disadvantage of causing docmods when fonts change, negates the purpose of ring and combo box controls, and limits the developer to a single view per definition, it seems like it may be time to take a step back. In most cases I would trade pure-strictness (specified font, ring items, etc.) for loose strictness (control size, layout) in order to gain the expected VCS and ring behavior.  Icing on the cake would be having multiple, pre-defined views for the same type (e.g. cluster with buttons vs. cluster with LEDs depending on whether it's deployed as a control or indicator) as I illustrated in the idea.


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.
0 Kudos
Message 40 of 44
(1,090 Views)