LabVIEW
Replace cluster bug
@Yamaeda wrote:
BTW, it works with Error clusters!
/Y
If you add something to the error cluster and then replace it, you get a generic error cluster so it is following the same rule (replacing the control with a brand new one). [edit] I guess error clusters are pre-defined. [/edit]
I'm with Jeff on this one. It's inconvenient sometimes, but it's expected behavior. The suggestion is right where it belongs - in the idea exchange. I'm not sure that even a lopsided vote will effect a change, because this sounds like a core change, not something cosmetic or high-level.
@johnsold wrote:
The question that should be asked by NI is "When would someone use Replace on a cluster and NOT want to retain the contents of the original cluster?" Never when the control is a type def. Often if the control needs to be replaced by a type def. What is the use case for the existing behavior, even if it has been there for a long time? See above This moves the discussion to the area of programmer productivity.
If I have a cluster and want to change the style, it is very unlikely that I want a new cluster with different components. You should have type def'd that cluster
For a new cluster I would simply create a new one. Type def the darned cluster too
to save you problem down the road
Lynn
Absolutely! Edit the type def, change the style! Apply changes, Save.
@johnsold wrote:
The question that should be asked by NI is "When would someone use Replace on a cluster and NOT want to retain the contents of the original cluster?" What is the use case for the existing behavior, even if it has been there for a long time? This moves the discussion to the area of programmer productivity.
If I have a cluster and want to change the style, it is very unlikely that I want a new cluster with different components. For a new cluster I would simply create a new one.
Lynn
Actually, I'm not disputing the issue of whether or not it should be implemented; the reasoning behind such a change is sound. What I am saying is, I'm sure that even if it was fairly difficult to do, it would've been implemented. I think the avenue was explored and deemed to dangerous to implement. Maybe it could potentially break more stuff than it would fix.
To a certain extent it applies to Enums also, if it's type def'd (not strict) and you change style it's emptied, but if it's a free enum it works to change!
Changing the type def is ofc a good idea, except the bug applies to the type def also, you cant change the cluster there either. There are ofc ways to work around it, as with most problems, but as a cluster is a Struct, i shouldn't need to work around it.
/Y
Old thread I know, but it seemed the most relavent post. So we understand the current implementation where a cluster (or any container control) will be replaced with an empty one, instead of just replacing the container. So my question is has anyone been able to accomplish the replace that's been discussed, using scripting?
I'm seeing the same with an array and am interested in how I could replace the array with a different style. The best I can think of is, for all controls in the containing control, make a copy, then replace the container, then paste in the original controls. For an array this is easy enough because there is only one control in the array. For a cluster it can be a bit more complicated because there are other settings in the cluster that I'm unsure how they will be affected, like control order in the cluster, and AutoSizing.
Then there is the fact that this scripting function needs to be able to be recursive, or while loop recursion so that an array in a cluster is handled, or a cluster in a cluster.
And the comment about how clusters should be type def'ed is fine, but the same issue remains for an array, which I generally don't type def.
Okay I put something together quick which has some code that started a while ago. Unzip all the files and run the Replace Controls.vi. This should open a template VI's front panel and replace all the controls making them modern. It doesn't support all control types, but it does go into clusters and arrays. My intent is to eventually make this a tools menu item that will replace controls in API drivers to be modern instead of silver and classic.
If you don't want to replace the controls inside it you can modify the code to support that.
@Hooovahh Did you develop this tool further? I plan to add it to NattifyVI Quick Drop, but I noticed a bug when changing an array style - the values are cleared. Do you have a fix for it or should I take care of it myself?
What is more it changes control names.
I think that this could be fixed with OpenG Variant Data (name and value could be temporarily stored as variant and then recreated after applying new style).
