Find and replace variables

[billko]

---

@ahatchkins wrote:

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

---

Don't alienate Mike.  He's one of your best resources here.  Maybe I've just gotten used to his style of posting, but I saw nothing really wrong with the "tone" of his post.  One thing I do know for certain is that you have to grow an extra horny layer of epidermis (thick skin) if you want to post to a self-help forum such as this one.  😄

[Hooovahh]

---

@billko wrote:

you have to grow an extra horny layer of epidermis (thick skin)

---

Today I learned what a horny layer of epidermis is.

[ahatchkins]

---

@Sam_Sharp wrote:

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.

---

That's exactly what I meant when I said

---

@antony Hatchkins wrote:

When I tried altering my [enum] typedef to a [cluster of enum+date] typedef

---

Next,

---

@Sam_Sharp wrote:

Note that your enum should also be a type definition (if it isn't already).

---

Yes, it is already. I thought I mentioned it, oh, yes, here it is:

---

@antony Hatchkins wrote:

[enum] typedef

---

Next, 

---

@Sam_Sharp wrote:

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

---

No, Labview is smart enough to keep the selected value of constants intact in most cases of typedef editing. But wrapping an enum into a cluster inside that very same typedef is just a too complicated task for Labview 2011 to handle.

Update:

This issue has been addressed in Labview 2014, and what was impossible in 2011 is a piece of cake now!

It shows a nice dialog:

you approve everything it suggests a couple of times and that's it: all chosen values retain their values after putting enum into a cluster inside typedef!

[ahatchkins]

---

@crossrulz wrote:

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.

---

Yes, Action Engines are nice. But I thought they are a syncronization tool, an alternative to queues for quick and simple tasks. What's the benefit of wrapping the queue into the action engine?

When I change the vi connected with the outside world through two queues (incoming and outgoing) the rest of the code does not care just as yours.

My problem was with altering the queue element type. As far as I can tell the same problem (maybe worse) would arise when changing the format of the command to the AE.

[ahatchkins]

---

@Sam_Sharp wrote:

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 (https://www.ni.com/docs/en-US/bundle/labview/page/using-local-and-global-variables-carefully.html) and there's also a an article detailing the pros/cons of using them (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LXrSAM&l=en-US) - the main one being that it can cause race conditions and is less efficient.

---

That's sort of what I'm doing: I'm updating the queue reference control by writing into it and reading from it from multiple places in the code.

The first link I've surely seen, the second one is interesting. But yes, I read about efficiency somewhere else.

I understand that array variables are inefficient. Copying a queue reference is quite efficient.

And I surely take care about race conditions: I start both cycles only after I've made sure that the queue has been successfully created. And I don't delete the queue until they have finished the execution. I see no other race conditions that could arise when using queue references.

[ahatchkins]

Some snippets to clarify the original problem (and summarize the answer):

That's what I had:

That's what I wanted:

What I tried was creating a new typedef (including manually replacing all instances of it) which

(apart from feeling that I'm doing it wrong 🙂 ) lead me to this:

After which I created a new queue indicator and needed to rename the variables pointing to it.

Now Mike's suggestion (in LV2011) of editing the existing typedef lead me to this:

that is, all enums were reset to the 0-th element - which is supposedly a bug.

The bug has been solved in LV2014, in which the procedure works flawlessly.

So I'm accepting Mike's answer in spite of his bad manners

@bilko

I can't help but notice that other self-help forums, like stackoverflow, don't require that layer.

Do you think it is the problem of propriatory vs open-source? It is it just 'old-school'?

[crossrulz]

---

@ahatchkins wrote:

---

@crossrulz wrote:

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.

---

Yes, Action Engines are nice. But I thought they are a syncronization tool, an alternative to queues for quick and simple tasks. What's the benefit of wrapping the queue into the action engine?

---

Then you do not understand Action Engines.  Action Engines are used to perform specific tasks with a private data that is stored in them.  So in my case, I create an AE to store my queue.  My tasks are Initialize, Send, and Close.  Since there should only ever be 1 reader, you make that process initialize and close and it alone has a reference being used (purely for Dequeue).  If you do this properly, you put the AE inside of a library and make it private.  You then create public VIs that use the AE to send whatever commands you need to.  Anybody can then send the commands through the queue without needing a reference.

I do this for all of my projects.

[mikeporter]

If you think my manners are bad, somebody needs to warn you about catching Sir Dennis on a bad day... 

Mike...

[billko]

---

@mikeporter wrote:

If you think my manners are bad, somebody needs to warn you about catching Sir Dennis on a bad day... 

Mike...

---

Or, ummm... sometimes even me. 

[mikeporter]

Oh yes, one more thing. If you are worried about name space issues, look into LV libraries (lvlib) they create a separate name space for the VI contained in them. Say for example yo take Tim's advice and create a VI that encapsulates the queue creation. Normally you couldn't just call it Create Queue.vi because in a large application that name is not nearly specific enough.

However, if you put that VI into a lvlib named, for example, Input DAQ Data.lvlib, the library name gets prepended to the VI name, so the fully qualified VI name becomes:

Input DAQ Data.lvlib:Create Queue.vi

Now you don't have to remember what you named the create queue VI this time. Obviously, if there are other VIs that you create for working with or manipulating the queue they would also go into the same library. One more thing I llike to do is put the library and all the files associated with it in a directory named the same as the library -- just makes it easy to find things. Good project organization is a huge boon so find something that works for you and stick to it.

Mike...

PS: One MORE thing, don't be afraid of conventions limiting your creativity. My experience has been the exact opposite, which may be a general principal of life. Some of the greatest works of art often came about when painters limited themselves to a restricted color palette, or composers limited themselves to using just certain notes, and sculpters always had to deal with the constraints of the stone they were working with -- but you never know it looking at Michaelangelo's La Pieta or David.