LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Deleting a control from a typedef Cluster

Thanks for your reaction,

But I d' not have the same problem in  C, it's correct that if you use the byte offsets to reference the items in a structure you can messed up your program when you change it. But that's not necessary, it is possible to reference directly, so we can change the structure without messing up your program. Referencing directly to the item is not possible in LabVIEW (only via the index)

0 Kudos
Message 31 of 36
(987 Views)

How the "unbundle by name nodes" can handle the reordering of the controls in the typedef cluster without an issue? If I delete something from the typdef then at all instances where I have used that given element the code will be broken which I am completely fine with. It does not mess up the code though just makes it broken which is an easy fix.

 

I have no idea what kind of an underlying mechanism is used in Labview to handle the "unbundle by name" function, but to for me the "unbundle by name" is equivalent to the "value" property node of the individual control elements in the typdef. (<<<again, not saying that they are programmed the same way under the hood.) Why it is possible that I can access the value of the cluster elements without a problem even if I reorder the typdef cluster, but I can do the same with other properties of the elements?

 

I abandonded this topic 2 years ago when I learnt that no matter who is wrong or right, this problem will not get solved. Its good to get some new thoughts about it though.

0 Kudos
Message 32 of 36
(976 Views)

@1984 wrote:

...

 

I abandonded this topic 2 years ago when I learnt that no matter who is wrong or right, this problem will not get solved. Its good to get some new thoughts about it though.


I was not around for round one of this topic but I do have some suggestions that may make your life easier.

 

1) If you can avoid it, do not delete elements in type-defined cluster.

2) If you cannot avoid and absolutely must then try...

 

A) Open the type-def and find the element you want to remove.

B) Change the data type to something that will break the code. Example, change control ref to string.

C) Save the changes and update All

D) Use the broken run arrow to find all sub-VIs that use that element in the cluster. Delete the wires and the named element from bundle and unblundle by name.

Note: ath this point all of the instances fo that element of the cluster should be gone.

E) Return to the typ-def and delete the element.

F) Lather rinse repeat for all other items you want to remove.

 

General comment

 

I have fought with bugs with typedefs for years and have been through all of the approaches, keep everything open, or edit only while dependent VIs are closed...

 

I have had the best success with using Trees to make sure everything that uses a type is in memory, save and apply changes regularly (often as I can actually) and only change one thing at at time to let LV try and keep up. it a minor miracle the type-defs work as well as they do. Do not expect a major miracle.

 

Like I said, just trying to help reduce the pain.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 33 of 36
(971 Views)

I completely agree with Ben.  For complicated reasons, we had a data acquisition/experiment control routine that was "driven" by an Excel Workbook, with three active WorkSheets, with about 160 "Variables" (mostly columns on the Experiment Sheet, whose rows were the individual Trials we were performing).  As part of the program, we created a Gigunda-Cluster with all of the Variables (we actually wrote LabVIEW routines to parse the Excel Workbook and, using a Script, create the Cluster Definition for us from an "Excel Master Workbook").

 

Anyway, "things change", and the Master Workbook evolved.  This means the Cluster and its TypeDef changed.  I used a half-dozen Trees (in a hierarchy) to, as Ben notes, ensure that all the VIs were in memory before I modified the Cluster.  I then looked for every place the TypeDef was referenced, looking for Broken Wires.

 

In my experience, adding or renaming existing Cluster Elements was rarely a problem (though I would recommend renaming one element at a time and testing for broken wires).  The problems that I found were when wires were deleted.  But by carefully checking all TypeDef references, and knowing the Logic that governed the TypeDef (we're talking Enums here, mostly), these were pretty easy to spot.

 

Bob Schor

Message 34 of 36
(954 Views)

I do exactly the same as Ben when I have to delete a control, but in most cases I don't delete it but set them as invisible spare ( to avoid confusing on the front panel) or unbundle/bundle if only the values are changing and sometimes with a search on the reference by name.

 

Erik

0 Kudos
Message 35 of 36
(931 Views)

I went back and reread the thread over the weekend.  It's now more clear to me that the complaints relate specifically to GUI-related programming (event handling, cluster element properties, etc.) rather than data-related programming.

 

While exploring a bit, I noticed that "Value Change" events are fired only for the enclosing cluster and that the event data only provides access to the individual elements of that cluster via an array of control refs.  So I think I have a better understanding of how you started down the road of using that array of control refs.

 

I've not run into this that I can recall, and that's probably because I've been in the habit of putting individual controls on my front panel rather than clusters full of controls or indicators.  This makes event handling very straightforward and it's still quite easy to build up the typedef'ed cluster when needed.

 

If way back in the dawn of LabVIEW the programmers had decided to expose the cluster's control ref's as a *cluster* of named refs rather than an *array*, there could have been a mechanism for LabVIEW to auto-correct with some intelligence when the typedef changed.  It seems to me like that *could* have been an option originally.  Strictly in this sense, I can now see how this could be viewed as "a LabVIEW problem."  However, I also think it's much too late now for NI to change it.  It would break far too much existing code.  The array of refs is the past, present, and future.  (Unless perhaps this was revisited in NXG?  I've not tried it yet...) 

 

The forward-looking lesson is advice given previously in the thread by GerdW and Intaris.  Any UI elements you need to manipulate individually in your program should not be contained in a front panel cluster.   I adopted this habit long ago for other reasons, and it has had the side benefit of keeping me safely away from the trouble you've found.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 36 of 36
(906 Views)