Michael Aivaliotis

Yes, you can do it that way too. The main motivator for my approach is when you have to do this on many many controls. It becomes very tedious. Hmm, interesting idea. I don't think you can invoke the clipboard with scripting but you can use some windows API. After the past you might be able to use a scripting function for re-link. I'll get right on that...

I've started experimenting with creating a LabVIEW development environment tool that would run and assist in various programming tasks. The initial task is to determine what is selected. This is important because you can find out what is selected then perform certain actions on these selected objects. One small area that I touched upon was the need to duplicate the same property nodes from one control to another. First of all you would select the property node. Determine what properties are there then buffer that in memory. Finally you would re-create a new property node for a newly selected control and apply the previous buffered property items. This works like a charm with controls of the same class. If you do it across classes then the creator node errors out. You can ignore the error but you end up with duplicate properties that were not there in the original. There seems like no way to only create properties of valid items for the new node. You have to feed it an array of property items. If one of them is invalid then you're out of luck. This is just one example of what you can do with a tool that runs while you code. I'm thinking of adding more functionality. Several other VI utilities posted in the forums could be added as well. This could be a nice way to package all the scripting tools. Anyone wanna help? LV7.0 Download File:post-2-1096874964.llb

Well I guess I was the first, right jpdrolet?

If you can give me a use case (a possible scenario) then I can show an alternate solution. You have to consider what the purpose of this would be. Would you be talking to different hardware with each executable or common hardware? I think this would be a key factor. The easiest way to work with multiple exe's would be just to rename them... no? Have the original exe create a copy of itself and then just launch it. Sounds possible.

Have you read this FAQ? Can I run multiple instances of LabVIEW?

I see your one of the few here using Internet Explorer ... We have to get you to switch to Firefox. :thumbup:

Yes. I took this picture during a sailing trip on lake Ontario. Geeze, what a scary image! Since you like those kind of movies, have you seen the movie "Resident Evil: Apocalypse"? It was actually filmed entirely in Toronto. One of the main action scenes shows a round shaped building blowing up. That is actually Toronto City Hall.

Yes, this is normal. There is a rule in LabVIEW execution flow. ALL loops must execute at least once before they stop. This is because LabVIEW MUST iterate in order to read the value of the boolean and then it will decide that it should stop the loop from running a second time. If you don't want to run the loops at all, you must use a case structure around the FOR loop set to false.

Ok, I'm starting another useless thread. Here are some screen captures of my desktop with the ultimate. Four versions of LabVIEW running at the same time. I challenge someone to beat that. I'm also showing my desktop... naked. Show us your desktop...

Doh! Thanks Alex, this is what I should have recommended. . I use that in my programs as well. It slipped my mind. Hey, at least this shows you read all the posts...

Try the status function.

Oh man! These ideas keep getting better and better!

Congratulations! :thumbup: You've discovered a bug. I'm moving this topic to the "7.1 bugs" section. I was able to reproduce this from scratch with a blank tab control. I believe the bug appears when you have "allow multiple rows" OFF and locate the tabs to the bottom.

I recommend you read this post (if you haven't already): http://forums.lavausergroup.org/index.php?...=findpost&p=675 So the issue really is that with globals is this. LabVIEW really has no way of protecting access to the global data. To work around this, LabVIEW allocates a seperate parallel memory buffer for each and every instance of the global. In other words, it does NOT reuse memory buffers allocated to globals like it does with other nodes. So if you plop 5MB of graph data into a global that is located in 10 different diagram locations, you will have allocated 50MB of memory space. Well, in general the fastest data access time is always a plain ol' wire. The value property ranks as the slowest (over 10x slower) method of data manipulation. Even slower than using a local. In my first post I said never use globals. My second comment would be: almost never use the value property. I choose locals over value every time. Finally, you may ask, well then what the hell do you use? LV2-style globals rank #1 for me with GOOP as a close second. GOOP is the ultimate in accessing data by reference. I would re-think that. Program execution is never linear in LabVIEW unless you're forcing execution with sequence structures or wires. Yes jpdrolet I agree. A modification that I would recommend to your image is a s follows based on your last statement: This entire code with the while loop would make up the the LV2 global VI.

Actually, the problem occurs with using the Variant form of the data (non-strict). If you are using the strict control refernece then this problem does not occur. This is because the refnum contains the type information on the wire and does not rely on the variant to data function. So in other words, your original implementation would not have this problem.

Excellent idea!

Hmmm.... I think I know what you are trying to do. Are you trying to move the menu from the top of the VI to the middle of the window? There is no way that I know of at the moment to do this. However, If you like to play with some methods. Here is an older post with some info: http://forums.lavausergroup.org/index.php?showtopic=639

Check out this post. There is a solution there for you. http://forums.lavausergroup.org/index.php?showtopic=356

Why do you have to change every instance? The constant is a strict-type. It will get updated when you change the master strict-type control. I'm not following your logic.

Well, I don't want to act like a smart-#ss... well ok, I'll be a smart-#ss. Why are you using globals? Globals in general are a no no. I don't know if you heard this before, but if not, here it is. Never use globals. I know you should never use the word never, but I'm using it here: never use globals. Ok, now something else. If you still want to use globals then here is a solution that will avoid having to update your control refnum control. Make a generic (non-strict) control refnum control. Use this in your global. Notice in the attached image that there is a coercion dot where the control reference meets the indicator? This is ok. It is ok to have a coercion dot here. This means that the strict reference is being upcast to a more generic cluster reference. This will avoid you having to re-create the control since it's immune to change. Thus no broken wires. On the receiving end you need to convert the variant to the proper data type. This is where you would use the actual strict-type control constant as the data type.

I'm not sure what you mean. Does your VI hang? Do you want to make the front panel controls "enabled"? You can use a property node to enable or disable any front panel control.

I don't know (and cannot find) any application that can read these *.ptc files. However, if you look into the same directory, you will find some other files called *.3ds. These are a standard 3D format used by many 3D rendering applications. You can probably download a free viewer somewhere for these. I haven't figured out why there are so few *.sds file compared to *.ptc files. Even if you figure out how to create your own *.ptc files, you are not finished yet. How do you "compile" a new control to use these images? It would be great if NI gave us the tools to do all of this. . This problem has been raised in these forums before. For example, how do you create irregular shaped controls with equally irregular hotspots!

I downconverted it for you: Download File:post-2-1095691375.viversion->LV7.0

Ah, yes. It reminds me of those visual optical tricks you read in puzzle books. The optical illusion here is the idea that data always exits a VI on the right-hand side. This forces your eye to follow the data from left to right. What you don't notice is that the constant "2048" is wired to ALL locals... I hope you shot the programmer...

Jim, your VI makes sense because you're not taking the outputs of the math functions and passing them along. It's more like the attached image: