LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Which control of which palette was used to create a FP object?

Solved!
Go to solution

FP objects can be customized in many ways. The result could lose any similarity with the original control available in the palette.

 

How origin of the control can be recognized? I cannot find any manual or scripting method helping to find which control was the “starting point” for the customization.

 

Thank you.

_____________________________________
www.azinterface.net - Interface-based multiple inheritance for LabVIEW OOP
0 Kudos
Message 1 of 12
(379 Views)

I think, there is no way to get "original". Like with VI - if I'll take any VI from examples, then modify it, then you can't say which one was original, there is no unique ID stored inside as far as I know. The same with controls. Indirectly you can get probably list of parts of the control (not sure if this possible programmatically), but modification's history definitively not stored.

0 Kudos
Message 2 of 12
(363 Views)

Thank you, Andrey_Dmitriev. Modification history could be a luxury. However, there should be some way allowing LabVIEW machinery to recognize controls.

 

LabVIEW allows to color Tab Panel created from NXG Style palette and does not allow to do it for one created from System palette.

Numeric control has Increment/Decrement and Simple Numeric doesn't:

 

ctls.png

 

Despite these pairs of controls have same class ID-s and class names.

_____________________________________
www.azinterface.net - Interface-based multiple inheritance for LabVIEW OOP
0 Kudos
Message 3 of 12
(341 Views)

You can add your upvote for the idea here. 

 

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Front-Panel-Object-s-Style-is-shown-under-its-propert...

 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 4 of 12
(316 Views)

LabVIEW is internally very object oriented and FP controls make no exception. The class ID you refer to is about this object hierarchy and is mostly concerned about behavior and very little about appearance. The appearance is determined by attributes that the various controls in the palettes have preset. There are no public tools to change many of the more fundamental attributes such as if a control part can change color or inherits the system color. Other attributes you can change (color, size, etc.).

 

If you go into the customize mode of the Control Editor you can even replace sub parts of a control with other compatible sub parts of a control from a different control palette. In that way your idea to identify the original palette a control came from is in fact not even practical. You can create chimaera controls with sub parts from different palettes and theoretically even replace the entire look with parts from other palettes.

 

But while the Control Editor is a powerful tool it is also from the early days of LabVIEW and can be cranky and  very emotional in the customize mode. Save all your work to a safe place before going into it. And during edit save often! it will crash regularly and usually with unrecoverable fireworks. 😀

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 12
(279 Views)

@rolfk wrote:

LabVIEW is internally very object oriented and FP controls make no exception. The class ID you refer to is about this object hierarchy and is mostly concerned about behavior and very little about appearance. The appearance is determined by attributes that the various controls in the palettes have preset. There are no public tools to change many of the more fundamental attributes such as if a control part can change color or inherits the system color. Other attributes you can change (color, size, etc.).


Yes, this is exactly what I need at end of the day. I need to know what can be done and what cannot be done with each particular control.

 

Look this is VI with two Tab controls.

ColorsFP.pngColors.png

 

The operation performed on NXG tab works fine while the same on the System tab launches the error.

 

I think every developer would like to know which operations can be performed on an object before implementing them not when the implementation is done and an error is encountered. 

 

_____________________________________
www.azinterface.net - Interface-based multiple inheritance for LabVIEW OOP
0 Kudos
Message 6 of 12
(266 Views)

Just try to color the element in the front panel with the color tool. If it works you do NOT have a system control.

What you ask for may feel more easy to you but what tool would you envision to launch to get that information? How is launching such a tool easier than trying to color it manually? I hear help window here? How much more information do you want to put in there? How to you make sure that information is still accurate if the control was heavily customized? Just walk the sub parts list and check each if it is a system part or not? What about performance of the help window if we start to do that and a lot more dynamic information? What if the bounding box is System style, the increment arrow button NXG and the decrement button Modern style, and the numeric shell Classic?

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 12
(251 Views)

@rolfk wrote:

Just try to color the element in the front panel with the color tool.


Probably, there is a misunderstanding. I don’t ask for a new tool but want to know already existing properties. I believe, OOP dictates the same behavior for objects created from the same class. I know only two class identifiers in LabVIEW: Class ID and Class Name. But there should be more. Otherwise: How does LabVIEW know what is alterable and what is not?

 

Let’s limit my question to controls which were not altered so dramatically. Forget about adding/removing/replacing elements. Let’s limit it to the question: How can the developer know which properties can be set using Property Nodes?

 

The suggestion to use color tool is feasible only for small lab projects. Having a large project with thousands of controls, the developer cannot check each control manually with color tool. Specking more generally, a developer should not use try and error approach when accessing a property of a FP control.

 

I can create a script walking through the project, trying to recolor each control and reporting which controls cannot be recolored. However, this looks out as inventing a wheel.

_____________________________________
www.azinterface.net - Interface-based multiple inheritance for LabVIEW OOP
0 Kudos
Message 8 of 12
(240 Views)

I’m still not quite understanding what you want. At first it sounded like you wanted a property you can query to see what palette a control came from (even though that information may already be outdated by customization of parts of the control). This would be something you have to instrument too. Then you say you don’t want to do such instrumentation but simply know what you can do with a particular control. How? Coloring of parts not being possible for System Controls is just one of many operation that depends on the type of control. Are you really expecting a table of all zillion properties in the row header and the various control styles in the column header and what is allowed for them and what not? How would that be easier to use than simply doing runtime checks?

Do you do proper error handling in your 1000ds of VIs that will at least log such errors or do you rather blissfully ignore most errors and try to remember all the dos and dont’s for each property, to apply them perfectly st design time? I for my part rather do proper error handling throughout than trying to stuff that kind of information in my head. Especially since a lot of that information is actually rather volatile in 30 years of LabVIEWing.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 12
(204 Views)

@rolfk wrote:

... simply know what you can do with a particular control. How? Coloring of parts not being possible for System Controls is just one of many operation that depends on the type of control.


In general this discussion about controls is very interesting from "difference" point of view. What exactly different between "System Boolean Button" and another one from Fuze (or Silver) Palette. Why some can be colored, and some not, etc?

 

Let me explain. For example, here simple VI where I collected different Buttons from Palettes out of the box as well as some GUI Controls from different packages available on VIPM:

Screenshot 2024-04-14 16.42.32.png

Some of these buttons "4 States", and some - "6 States", I mentioned amount of Items you can select here:

Screenshot 2024-04-14 16.44.58.png

Also they have different amount of Parts, I mean Parts Window:

Screenshot 2024-04-14 16.46.41.png

All Buttons have three major parts - Name Label, Boolen Button and Boolean Text. But some like Silver have also "Non-colorable Decal" (could be many — one for decoration and another one for Icon), the DMC Control "equipped" with Boolean Divot, Boolean Shadow and Boolean Light. And the Icon placed on the control is not always "Non-colorable Decal", on different controls some differents parts are used like Boolean Glyph or Boolean Light:

Screenshot 2024-04-14 16.50.59.png

And there are no any information how to manipulate Parts in the list. Help only says "Use the Control Parts window to size and position the individual parts of a control or indicator."

Some extended information can be found here — Control Parts.

 

Back to our diffrence between System and Fuze Buttons. In general both are the same, "6 States" and contains the only "basic" Parts. But if we will take a look into the Heap Peek, then we will see that the "Boolean Button" Part (which is ID 21) organized differently:

System Button - just 6 simple entries with some IDs (take a note [1] and [5] are the same).

 

Heap Peek - System Button.png

But on Fuze-designed Button there are Foreground and Background colors, and also different IDs:

Heap Peek - Fuze Button.png

 

I think, this is in general should be reason for such behaviour — behind the scenes we have different items in the list of the pictures and some will allow colorizing, and some — not. I pretty sure, if I'll take different items from different buttons, then behaviour gets changed, may be will be possible to colorize "True" state, but not allow to colorize "false", etc.

 

So, as result the difference between different GUI elements is just different parts list and different content in the items in the individual parts, nothing more.

 

And it looks like some "hidded" unpublished internal knowledge here - how to create such controls "from the scratch"? How to add new parts, may be get this list programmatically, or remove/modify existing, etc? How, by the way" the DMC Button was created? Currently when I modifying some controls, then usually I take one which is most suitable to my needs, but I prefer to do this "from blank page" and don't know how.

 

Message 10 of 12
(190 Views)