ni.com checkout is currently experiencing issues.

Support teams are actively working on the resolution.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
midam

Automatically deleting the case in the case structure where the selector has been removed from enum typedef

Status: Declined
see comments below

Hi, I've been cleaning up my LabView code and needed to delete one of the element from the enum typedef.

As a result, LabView compiler gave me lots of error because the case structures which had the deleted element as a selector were still looking for this selector.

I needed to open up each VIs that generated these errors and delete the case of the case structure which is not available anymore.

It was OK since the number of case structure required the fix was managalbe but if it was a larger application then this approach would be rather tedious.

Is there any way to do this automatically or it is better to be done manually for some reason?

Thanks!

Steve

7 Comments
drjdpowell
Trusted Enthusiast

Ah, but what happens when you need to add a new case to that enum with its tendrils growing throughout your large application?  You're proposing a (rather dangerous) treatment of one symptom of a deeper problem.  An enum that runs throughout a large application is an arcitecture that scales very poorly.  

midam
Member

Hi drjdpowell,

Can you shed more light why adding new case would be problem and enum is no good in terms of scalability? At the moment, I'm using (abusing?) lots of enum in typedef for medium sized (1200+ VIs) application.

Also, I don't see

Cheers.

drjdpowell
Trusted Enthusiast

I may be speaking too glibly as I don't know your application, but I think it is difficult to maintain an application with many, many case structures for an enum.  It's a lot of work to add or remove an enum case, and it is easy to forget about some case structure somewhere with a "default" case that doesn't flag an error when you add a new case.  Personnally, I tend to use LVOOP classes instead of enums that might be needed in many places.  Each case of the enum is replaced by a different child class.  Removing a child is trivially easy, but more importantly, adding a "case" can be done by extending ("inheriting from") another similar case, so that only a few "case structures" (in LVOOP, these are "overridable methods") need to be modified.

 

 

midam
Member

Oh, I see. That is a fundamental problem with enum and case structure. At least I'm happy to know that it is not only me who found removing an enum case is a hassle. Then would'n it be an idea to automatically remove the enum case which is no longer available?

P.S. Maybe it is time for me to dig in LVOOP which I have avoided so far

Smiley Happy

 

.

 

drjdpowell
Trusted Enthusiast

> Then wouldn't it be an idea to automatically remove the enum case which is no longer available?

The problem there is I can see some clumsy people (i.e. ME) accidental deleting an enum case without realizing it.  Maybe if the delete wasn't automatic, but required selecting a special menu option.

 

> P.S. Maybe it is time for me to dig in LVOOP which I have avoided so far

Give it a go.  It's particularly useful when you need to adapt a new thing that is just a small variation of an old thing.  Make a "child" of the old thing and "override" just the things that are different.  

johnsold
Knight of NI

I would not want the auto-delete.  With enums I usually do not make a default case (if at all) until the code stabilizes, so removing an element breaks the code.

 

If the case contains terminals, auto-delete may cause extra complications.

 

Even if the case will be eventually deleted, some of the code within may need to be duplicated for another location.

 

Deleting the code first assures that the enum item is really not needed.

 

I think this would create more problems than it would solve.

 

Lynn

Tori_W
NI Employee (retired)
Status changed to: Declined
see comments below
National Instruments