LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 11 of 22
(4,064 Views)

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

0 Kudos
Message 12 of 22
(4,039 Views)

@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 clusterSmiley Wink  For a new cluster I would simply create a new one. Type def the darned cluster tooSmiley Surprised to save you problem down the road

 

Lynn


Absolutely!   Edit the type def, change the style!  Apply changes, Save.


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 22
(4,027 Views)

@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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 14 of 22
(4,002 Views)

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

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 15 of 22
(3,970 Views)

@Yamaeda

You already Kudos'd the Idea- (so have 284 others including myself)  Again, I would still call this a feature request and not a bug.  I like the current "Replace" functionality and would hate to have it suddenly changed.  But, I would use a "Change Style" RCM option if it became available.


"Should be" isn't "Is" -Jay
0 Kudos
Message 16 of 22
(3,966 Views)

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.

0 Kudos
Message 17 of 22
(3,872 Views)

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.

Message 18 of 22
(3,862 Views)

@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?

bug.png

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).

Michał Bieńkowski
CLA, CTA

Someone devote his time to help solve your problem? Appreciate it and give kudos. Problem solved? Accept as a solution so that others can find it faster in the future.
Make a contribution to the development of TestStand - vote on TestStand Idea Exchange.
0 Kudos
Message 19 of 22
(2,036 Views)

Here is my quick and dirty fix.

Michał Bieńkowski
CLA, CTA

Someone devote his time to help solve your problem? Appreciate it and give kudos. Problem solved? Accept as a solution so that others can find it faster in the future.
Make a contribution to the development of TestStand - vote on TestStand Idea Exchange.
Message 20 of 22
(2,027 Views)