Using a TypeDef from a TypeDef

[CoastalMaineBird]

Or maybe just manually copy the master .CTL definition to the slave CTL definition, and than re-set the font.

Should name the slave something like BoldItalic20PtTransparentUnits.ctl, so I remember to change everything.

Hopefully I won't do this every day.

[CoastalMaineBird]

Would an XControl work? 

I don't believe XControls work on RT.  And just being CTL/Indicator doesn't answer the whole problem, I have 15 pt indicators and 20 Pt indicators.

[paul_cardinale]

Use 3 typedefs.

1. A top level master typedef that has the definitions.
2. A strict typedef for controls, that contains the master typedef
3. A strict typedef for indicators, that contains the master typedef

[PiDi]

Use your current enum typedef to define elements. Use rings for GUI.

Convert enum elements to ring elements. See the attached project in zip.

This is how it looks:

And this is Convert Enum To Ring VI:

Downside: you have to create a bit of code to initialize rings. It's really just a few prop nodes to drop. But any change to your typedef will autmatically propagate to your rings then. And you won't have any problems with LV automagically destroying your controls formatting.... PROFIT! 🙂

[wiebe@CARYA]

Short answer is this is how it is (messed up). It seems you exhausted the solution space (e.g. tried everything). It's clear why these attempts fail. I'd resort to non-ideal solutions.

Keep the one typedef, since it's convenient in the program. Make a scripting VI that somehow (by label and type) re-formats color, font etc. Run this when LV decides to flush the formatting.

Hardly a solution, but if nothing else works it will do the trick.

[daveTW]

Hello,

I think, PiDi's solution ist simple, clean and easy to understand. You could replace the SubVI with a (hidden) Enum-control and a property node with the property "strings[]".

This code is even possible with LV 5

[Ben]

Crazy idea...

Create two Tree VIs that contain two parts of your affected code. In one Tree VI, include all of those VIs that use version 1 of the type def. The other VIs that use Version 2 are in the second Tree VI.

Continuing no on the assumption that you do not have hierahies that result in both groups of VIs loading. The key is to ensure that only the VIs that user Version 1 are loaded at any one time.

Now with the project closed, open the first Tree VI. Open the type-def, set the font as needed and then set the type-def as "strict". Apply the changes and save all. Then switch the type def back to a normal non-strict type def. All of the VIs that use that type def should now look the same but are normal type defs.

Repeat that process for the second Tree VI.

What I believe will happen is they will share the data definition but have two different display styles.

Give it a try if you are not stuck with over-lapping hierarchies.

Ben

[CoastalMaineBird]

Make a scripting VI that somehow (by label and type) re-formats color, font etc. Run this when LV decides to flush the formatting.

That may be what I end up doing.

I have some other VIs that do alignment of things, based on a conditional symbol.  It insures perfect alignment if I adjust the size or something, but it doesn't need to execute every time.

Something I forgot, since I haven't revisited this code in some time, is the fact that I have code that displays the units values BY REFERENCE.  That might gum up the idea of having two or more typedefs.  I'll have to investigate whether a reference to a enum TypeDef is compatible with a reference to a different enum TypeDef, even if the value strings are the same.  Need to find out if there's a speed penalty there, as well (comparing strings at runtime).  I hope not.

[wiebe@CARYA]

---

@CoastalMaineBird wrote:

Make a scripting VI that somehow (by label and type) re-formats color, font etc. Run this when LV decides to flush the formatting.

That may be what I end up doing.

I have some other VIs that do alignment of things, based on a conditional symbol.  It insures perfect alignment if I adjust the size or something, but it doesn't need to execute every time.

Something I forgot, since I haven't revisited this code in some time, is the fact that I have code that displays the units values BY REFERENCE.  That might gum up the idea of having two or more typedefs.  I'll have to investigate whether a reference to a enum TypeDef is compatible with a reference to a different enum TypeDef, even if the value strings are the same.  Need to find out if there's a speed penalty there, as well (comparing strings at runtime).  I hope not.

---

Yes, come to think of it, Scripting isn't needed, VI Server is probably enough. And this means it can be done at runtime and in executable.

[CoastalMaineBird · Accepted solution]

For the record, what I ended up doing was:

-- Defining several TYPEDEFs that are string indicators.  One with 20pt font, one with 15pt font, etc...

-- Changing my code to convert the UNITS enum into strings at display time.

Since a string is a string, and a ref to a string indicator is a ref to a string indicator, then the code that changes the display doesn't care about fonts, etc. There is no TYPE difference, unlike the ENUM possibility.

Because these indicators only change when the user chooses a different channel, then the extra time is not a real problem.

Thanks to everyone for the thoughts.