Find and replace variables

[ahatchkins]

Hi, everyone

Setup

I have a queue that connects two cycles in two different vi's.

The vi's share the queue by a reference.

Now that I've changed the format of the queue element from enum to a cluster of enum and date

my queue reference has changed as well.

Question

How do I replace (rebind) all instances of 'old_queue' queue refnum variables with 'new_queue' queue refnum variables?

What I tried

I tried to use 'Find and Replace' but it doesn't let me do it: in textual mode it shows a strikeout icon near to all

of the instances it has found, and in graphical mode it doesn't has such an option as replace it with a refnum variable.

[mikeporter · Accepted solution]

First: a lesson for next time. Make the datatype for the queue a typedef. Now the problem goes away. Change the typedef and all the references change.

Bonus lesson for next time don't pass queue references around. It's unnecessary. Queues can be named. To get another reference to the same queue, all you need to know is its name.

To answer your basic question, you can't. You will just have to follow the wires around and replace them manually.

Mike...

[ahatchkins]

> To answer your basic question, you can't.

Wrong. To answer my basic question, you can't.

First lesson for next time:

use the following snippet to Find and Replace variables:

Bonus lesson for next time:

don't answer questions if you don't know LabView well enough and don't teach lessons unless you're explicitly asked to.

Antony...

[Sam_Sharp]

I think that was a very rude response to Mike's answer.

VI Scripting is an advanced & fairly undocumented/unsupported LabVIEW feature - considering it was your first post on the forums it wasn't unreasonable to think that you were a beginner/intermediate LabVIEW user.

Had your queue reference been based on a type definition in the first place as Mike suggested, every instance of the queue reference would have updated when you changed the type definition. This is a fairly basic LabVIEW practice. It also looks like you are using local variables to pass your queue reference around - this is also considered bad practice. You should either wire the reference around or use named queues as Mike suggested to obtain the reference where you need to.

You can also just click on the local variable to rebind it to a different control/indicator but your scripting solution automates that. The pain in having to update the local variables manually is a lesson in using type definitions and not using local variables to pass references around!

[ahatchkins]

Hi Sam,

Sorry for my rudeness, but I really didn't expect such a tone even towards a newbie.

My queue references are (and were) in fact based on type definition.

What I tried initially was manually replacing the [enum] typedef to a [cluster of [enum] typedef + date] typedef.

That lead me to the problems of renaming the queue described in the original question.

When I tried altering my [enum] typedef to a [cluster of enum+date] typedef as suggested by Mike I ran into another problem:

everywhere in my code where I feed a message to the queue the message has been (after otherwise correct conversion to a correct type

of cluster of enum+date) reset to the first item of enum.

- a new problem which I didn't have in my original approach.

As for naming the queues, it may be a good idea for middle-sized programs like mine, but might become a headache for huge libraries since it pollutes the global namespace.

As for wiring the queues, I honestly wire everthing I can (yes, dataflow model is cool 🙂 ), but in this case I found that wiring this specific queue harnesses the readability. And the existence of queue naming mechanism shows that at least I'm not the only one who ran into this issue.

> The pain in having to update the local variables manually...

Programming languages should as painless as possible. They should provide means for developers to express their ideas, and not limit them with One Right Way to do something. In fact Labview is pretty good in this aspect.

I'm still compelled to think that that's a drawback of the GUI to have variables in the language and not users let "Find and Replace" their binding.

[crossrulz]

---

Sam_Sharp wrote: It also looks like you are using local variables to pass your queue reference around - this is also considered bad practice. You should either wire the reference around or use named queues as Mike suggested to obtain the reference where you need to.

---

Personally, I like to keep my queues in Action Engines.  I then make wrappers for each of my commands.  It is then very simple to update the calling VIs and the rest of the code just does not care.  This is called Decoupling the message from the sending code.

[Sam_Sharp]

My queue references are (and were) in fact based on type definition.

What I tried initially was manually replacing the [enum] typedef to a [cluster of [enum] typedef + date] typedef.

That lead me to the problems of renaming the queue described in the original question.

What you should have done here was update the original type definition - open the enum type definition, drop in a cluster, put your enum inside the cluster, add your other data types etc. then this change will propagate across everywhere the type definition is used. If you use a different type definition it means you'll need to re-link everything to the new type definition. You can also open the type definition and 'save as' and there's an option there to update all instances to use the new type definition instead.

everywhere in my code where I feed a message to the queue the message has been (after otherwise correct conversion to a correct type

of cluster of enum+date) reset to the first item of enum.

Always bundle the items into the cluster. If I remember correctly, any time you update the type definition, any constants will reset to their default values when the update to the type definition propagates across your code. Note that your enum should also be a type definition (if it isn't already).

While there are uses for local variables, they should not be seen as data storage like variables in other languages and should be seen as a way to update a control/indicator from multiple places in the code. There's an NI tutorial about local variables and how they should be used (http://www.ni.com/white-paper/7585/en/) and there's also a an article detailing the pros/cons of using them (http://digital.ni.com/public.nsf/allkb/74ECB57D3C6DF2CE86256BE30074EC47) - the main one being that it can cause race conditions and is less efficient.

As for your final/edited point - Yes, programming languages are a tool and there are an infinite number of ways of achieving the same end result but some methods provide better efficiency, readability, modularity etc. etc., however, every programming language has some 'best practice guidelines' (e.g. MISRA C) and this is what Mike and myself are trying to encourage you towards - National Instruments themselves even publish one for LabVIEW! Part of being a professional software developer I've found is that I am continually finding new/different/better ways to achieve my goals - even at the highest level of certification!

[mikeporter]

So Tony, you didn't expect "such a tone".

My tone was one of someone who has been using LabVIEW longer than you have been alive trying to teach you how to avoid the problem going forward.

It also seems like you have a lot of excuses for your less than optimum development practices -- which is too bad. Assuming you are out of school, there is one more lesson to learn: This work is not about ego.

If you hope to be any good at what it is that you do, you need to be learning every day -- I know I am. You need to be experimenting, trying things out. At the end of the day, there are Right Ways to do things and you job as a professional is to find those ways, remembering that someone else is going to be maintain your code.

Mike...

[Hooovahh]

A lot of topics going around, but I picked up on one that I don't personally agree with.

---

@mikeporter wrote:

Bonus lesson for next time don't pass queue references around. It's unnecessary. Queues can be named. To get another reference to the same queue, all you need to know is its name.

---

I do no think this is the right way of doing it.  Having data that I like to think of as private, being accessed by name could lead to trouble.  It also can be hard to debug code that opens references to queues without any easy way of finding them.  Passing the reference to the queue around is an acceptable method in my mind.  An action engine is a more prefered method because you can at least perform a Find All Instances on that and find where the reference is being read and used.  When referencing a queue by name you can search for the string, unless it is a common string, or if the string is being built at runtime.

[billko]

---

@crossrulz wrote:

---

Sam_Sharp wrote: It also looks like you are using local variables to pass your queue reference around - this is also considered bad practice. You should either wire the reference around or use named queues as Mike suggested to obtain the reference where you need to.

---

Personally, I like to keep my queues in Action Engines.  I then make wrappers for each of my commands.  It is then very simple to update the calling VIs and the rest of the code just does not care.  This is called Decoupling the message from the sending code.

---

I actually learned this from you from an earlier post of yours.  Besides the advantage of what you posted, it makes for neater code, too.  Making neater code while maintaining LabVIEW "best practices" is a BIG PLUS in my book.  🙂