Michael Aivaliotis

That's golden. I would have liked to be there to capture the look of that customers face.

Did you also think that the movie "Broken Arrow" was a story about a frustrated LabVIEW programmer battling the forces of evil to get his little Vi to work?... I did. Broken Arrow

Excellent question! It has a surprisingly easy answer. Just open a reference to the main polymorphic VI and using a property node, get the list of Callees. See image.

Ok guys. I have an issue with this implementation with respect to showing new users how to do things. I now understand what you are trying to show Alex but the "proper" conversion of a CSV file to an array would go something like this: Let's not forget that the original question was asking about a CSV (comma separated values) string.

Yes, this is possible. Do you know the old password?

What method were you using before to open the front panel?

Are you using LabVIEW? If not, then you are on the the wrong forums.

A quick search on the NI site came up with this:

I don't mean to correct you Alex but I think you would need to specify a comma for a delimeter, no?

This is PJM's personal palette. Perhaps with a little coaxing, we can get him to submit an openg package with these goodies... I believe the closest thing OpenG has to scripting is the ogmnu_appcontrol_plus package. It can be downloaded with Commander.

Here is a presentation with lots of examples that explains how to use templates with process spawning (multiple VI instances): http://lavausergroup.org/niweek2004/meetin...niweek_2004.zip

Rule number one in my company is: 1. No Global variables Rule number two is: 2. Read rule number one. Anyone caught breaking this rule is reprimanded. Forget globals, remove it from your palette (if you can). The solution you provide is worse! You know how slow your read and writes are gonna be? oh man! Open a reference to the global vi then using property nodes, wholy cow! Very very slow. especially if you have 600 of them. Very bad programming style. Why re-invent the wheel? Read this: What are USR Globals? Spend a day or two and rewrite the global calls to USR globals it's well worth it. Do it behind your bosses back. The program will run better and faster and you will be a hero. Also, if you feel like reading, here: http://forums.lavausergroup.org/index.php?showtopic=652

Why are you using VISA? Why not use the standard tcpip functions? I always use those.

Since the new OpenG Forums are up and running, I decided to close this thread and hand-off any further discussions on this topic to the new OpenG Forums. This topic thread is now closed. Please continue all further discussions on this topic here: http://forums.openg.org/viewtopic.php?t=32

The new OpenG Forums are now live and running. The decision has been made to move forward and make this into an OpenG package. This thread is now closed and a new one has opened on the OpenG Forums here: http://forums.openg.org/viewtopic.php?t=31 Please continue all discussion there. Nice work everyone. :thumbup:

Yes, Child windows are possible using Windows API calls. I've attached a Vi that does this. Download File:post-2-1106002183.viLV6.0 It was written in LV 6.1. I noticed you are using LV6.0 so I did a save with options to V6.0. I can't test it on that version so let me know if it doesn't work.

I'm using it. What is your question?

I suspect that you are asking this question because you are having speed problems. Relatively speaking, any internal data passing method you choose will be light years faster than your serial connection. Local variables would be faster and queues mentioned by @johnRH would be good as well but none of these changes will give you "noticable" speed improvements.

Not really, I think this is educational for all. Yes, I realize that. Perhaps it would be nice to create some function VI's that operate on the "look and feel" of the menu. This way the colors and style can be programmaticaly changed. We can also have 3-4 "preset" looks that people can choose from. Remember, the key here is to satisfy a broader audience. Ok, I just wanted to clarify that this should be the direction. Do you want to work on this? I think it would be a great way to combine forces. This way there is no overlap.

First, please review this topic: http://forums.lavausergroup.org/index.php?showtopic=771 It contains recommendations for posting images to the LAVA Forums. It is not acceptable to post large images inside posts. -------- Now for your problem. You state the following: Do you mean that if you do NOT call a "Sub-VI" with an event structure in it, everything works fine? Also I noticed this: I hope you are not splitting this reference. It is not recommended to split or share user events between event structures. Perhaps this is your problem.

Read this: http://openg.org/tiki/tiki-index.php?page=...ng%20Guidelines

Why not read the data from a file and write the values in the globals?

My comments follow: hfettig, your code has a path problem: I'm not sure what you're trying to do with the name mangling. I took that out and it worked. Menu look and feel. hfettig, in your implementation, I noticed that when you hover over an item that leads to a submenu, nothing happens. You have to click on the item for the submenu to fold out. This is contrary to standard menu behavior. In general, I noticed both (hfettig and didierj) implementations have menu's that are non-standard. The question arises, what is standard. Well, in my opinion the menu's should match the system colors and schema whenever possible. For example, dotted lines as separators is not standard. Also, didierj, when a submenu unfolds, it should be slightly overlapping the previous menu. Architecture hfettig, I like how you've implemented the architecture to match the built-in menu functions of LabVIEW. However frankly do you think that's easy to program with? It simply takes up too much valuable digram real-estate and requires an extensive concatenation of VI's. I love didierj's method of describing the whole structure in a string array. Perhaps we should target that approach. The more I think about it the more I come to the conclusion that we should create a menu builder GUI . If you think about it, this is what NI did because they also realized that you can't rely totaly on VI's to create your menus every time. For the casual menu user, a menu editor that saves the menu architecture to a file is all that is really required. However, you still need the VI's to manipulate the menu for dynamic situations. Perhaps we can keep hfettig's approach for dynamic menu manipulation and just build a GUI for menu building. Programmer Usability hfettig, I like how there is minimal code required for the launching of the menu. Ideally I would love to have a 3 VI implementation. As long as you have a control reference then that is all you really need. didierj, there is simply too much code required to feed into the functions from the toplevel. Look at how hfettig has used a subvi to capture the control coordinates to minimize the amount of work the programmer has to do for implementation. I believe we can minimize the overhead even more. Here is what I envision for the final implementation:

This is great! Thank you to all in this thread for your enthusiasm. :thumbup: . I would really like to see the pop-up menu system (RCPM) become an official openg package. I currently have a use case for this tool to use it in the next generation openg package manager which we've named Commander. Before this happens, I'd like to debug the RCPM and create it into a package. I've been busy working on the release of the NEW openg website but I will spend some time working with the RCPM and give you my feedback in this thread ASAP. Once the new openg website is up and running we can transfer this discussion over there.