"Replace all" in type defined clusters

[_Y_]

I have no solution for quite a simple problem. Surprisingly it did not appear in may work before.

Project has multiple nested type definitions. One typedef must be replaced with another one in all or in many places. Conventional search and replace does not work.

This is a simple LabVIEW 2019 project illustrating the question

 It contains four typedefs:

 Two contains clusters. String StringTypedef.ctl is the only member in each cluster.

Now I search all instances of StringTypedef.ctl. Both instances are found. Then NumericTypedef.ctl is selected to replace it:

 

But clicking button Replace all or selecting and using Replace selected do not give any result.

How such multiple replacement can be done?

To be frank I am ashamed to ask so simple question but cannot find any answer on my own.

Test project is attached.

[cbutcher]

In LabVIEW 2019, I was able to right click on "StringTypedef.ctl" in the Project Explorer, and then choose "Replace with..." and choose the NumericTypedef.ctl file.

That gave me a warning about how I basically wouldn't be able to undo the action, but then it worked as it seems you'd like it to.

Does that work for you?

[crossrulz]

---

@cbutcher wrote:

In LabVIEW 2019, I was able to right click on "StringTypedef.ctl" in the Project Explorer, and then choose "Replace with..." and choose the NumericTypedef.ctl file.

---

There is also the Quick Drop option (CTRL+Space, type in name of type def, CRTL+r).

[_Y_]

---

@cbutcher wrote:

In LabVIEW 2019, I was able to right click on "StringTypedef.ctl" in the Project Explorer, and then choose "Replace with..." and choose the NumericTypedef.ctl file.

That gave me a warning about how I basically wouldn't be able to undo the action, but then it worked as it seems you'd like it to.

Does that work for you?

---

Actually it must work for me because "old" and "new" code is well separated in current project. So thank you very much, you saved a lot of my time.

Unfortunately it would not work in general case because replacing only some instances cannot be easy. And I believe button Replace selected is used more often. So, I keep the question open.

[Darren]

---

@crossrulz wrote:

---

---

There is also the Quick Drop option (CTRL+Space, type in name of type def, CRTL+r).

---

Quick Drop Replace is Ctrl-P (not Ctrl-R). Also, it supports multi-select within a single VI.

[wiebe@CARYA]

This might work, EDIT:but only if you need to replace them all.

It's a hack, make sure SCC is in place.

Close the project.

Delete (or rename) the control to be replaced.

Open the project.

When LV complains, browse to the new control.

EDIT: Optionally change back the name, and use SCC to revert the VIs that need to use the old control.

That might effectively replace all instances. Or not. Can't really recommend to do this, but I'd do it if I'm frustrated enough.

[crossrulz]

---

@Darren wrote:

---

@crossrulz wrote:

---

---

There is also the Quick Drop option (CTRL+Space, type in name of type def, CRTL+r).

---

Quick Drop Replace is Ctrl-P (not Ctrl-R). Also, it supports multi-select within a single VI.

---

Wow, that was a major brain fart on my part.  Maybe I should dig up one of my QD mousepads...

[_Y_]

Multiple attempts and tests gave unpleasant result.

I tried both: 1) Replace with... in project and 2) removing old typedef then opening project and pointing to new typedef. Both methods work in test projects but don't in real large project. Unfortunately I cannot find any reason for such difference in behavior.

Probably I shall create a wheel, i.e. a script replacing all instances of typedef in project one by one😵

[wiebe@CARYA]

There must be some complication that distinguishes a "test project" from a "real large project". I don't think it's just scale.

I had problems with type defs owned by classes, where the class was blocked because the type def was changed, and the type def was blocked because the class was changed. I tend to forget the details once I found a workaround. But a seemingly simple "recursion" like that could be the showstopper.

[_Y_]

---

wiebe@CARYA wrote:

There must be some complication that distinguishes a "test project" from a "real large project". I don't think it's just scale.

I had problems with type defs owned by classes, where the class was blocked because the type def was changed, and the type def was blocked because the class was changed. I tend to forget the details once I found a workaround. But a seemingly simple "recursion" like that could be the showstopper.

---

Yes, this is the problem. I cannot find the basic difference between "test" and "real" projects.

Yes, typedefs can belong to GOOP classes or LVLIB-s. However replacement works with "test".

Recursion? May be. What happens if a typedef is member of a class while the class attributes contain this typedef? I shall test it.