Yair

QUOTE(Yen @ Nov 9 2007, 01:58 PM) Just to elaborate, I meant things which work correctly, but don't work in particular instances because of the way the executable is built or because the code does not take that fact into account. Examples would be relative paths and interacting with front panels which were not included in the executable.

QUOTE(BrokenArrow @ Nov 8 2007, 10:25 PM) These are all essentially properties of the object (in this case the string control). You can change them either through the UI or programmatically. Of course, if you change them and you want them to stick, you need to save the VI. Once you do that, it should work in the same in the EXE even if you don't do anything. If you want some other examples: Displaying increment buttons in numerics, changing the browse settings on a path control, changing the properties of a graph. They should all remain the same in the EXE as they were when you saved the VI QUOTE 3) When the help for a given function/node/invoke etc. says it's "Available in Run-Time Engine", does that ALWAYS mean it will work in an EXE? It should work, barring any issues which would be unique to the executable, but I have seen some cases where the help was wrong (in both directions).

Michael, recently I've had several occasions where the forums remove spaces after periods and line breaks from my posts, causing them to be quite hard to read. Editing and fixing it doesn't always work the first time. Note - I have the HTML formatting off.

I didn't see any great positive reaction or helpful suggestions, and I've been quite busy, so I put it aside for a while. I still use this all the time and it's great, but as I said, it has some issues. The single biggest issue is managing the names and aliases and it has several sub-issues: Getting the item names in versions below 8. At the moment I can think of four options: Build them manually (not really an option). Hack the mnu files. I gave it a quick look and it doesn't look easy for primitives. Do the palettes in 8.x and find a way to change whatever needs changing. See if the palette API can handle mnu files from 7.x. How to generate unique and consistent IDs for functions? If the IDs are not unique, some of the functions will be in the list, but selecting them will drop the other function. We could generate a unique list for each computer, but then the lists will not be exportable between computers, unless we come up with a way of preparing them for export. That might actually be the most practical idea. One option I thought about was using namespaced strings instead of I32, but I'm not sure how that will affect performance and it's still not guranteed to be unique and consistent. How to manage function names which change between versions. I don't have an example off hand, but I have seen NI VIs and primitives which had their name changed. This will only need to be changed in one place (where the ID is), but the key would be identifying it. Maybe scan the entire previous list when upgrading and display all entries which don't match? And speaking of the previous version list, I still haven't thought about a useful structure for managing different versions and toolkits. We will probably need a hierarchy of separate files and folders. I haven't thought about a useful UI for managing the aliases (adding, changing, deleting).

Definitely a good idea. Sounds like a visit to NI's product suggestion center is in order. To reduce the number of wires, you can also use a single cluster for all the data. See a recent discussion here.

Welcome to LAVA.

If you want, I posted a pure G version once here. It essentially does what eaolson decribed, so the quality is far from great, but it works for some things. If you want another, search the OpenG site for a utility called Bird's Eye View, where you can find a VI which does bi-cubic interpolation in pure G.

For what it's worth, it was my punchline first, so I can complain more.

QUOTE(Aristos Queue @ Nov 7 2007, 05:59 AM) Mis-take. I can still see people ten years in the future, when this won't work, coming in and saying "But AQ said...". :laugh:

For the moment, you can probably write your own. Write a floating VI with two buttons ("Copy" and "Apply") and some checkboxes for the options. Pressing Copy copies the properties from the currently selected control and pressing Apply copies the checked properties into the currently selected control. Not the simplest thing in the world, but a basic demo can be has been written in a few minutes.

Welcome to LAVA. Your "electroplating" setup sounds interesting. What exactly does it do?

I don't get it. What's the problem? Someone wants to give you a lot of money and you don't want to take it? Maybe it's one of alfa's friends.

QUOTE(neB @ Nov 3 2007, 04:49 PM) The color <-> RGB VIs are available in a standard LV 7.0 (at least in the pro version).

Sounds interesting, but unfortunately requires the internet toolkit.

Your mission, Punk, should you choose to accept it, is to get past everyone in the 10 bit group. As always, should any member of your team be caught or killed, the secretary will disavow any knowledge of your actions. The only question now is "Do you feel lucky?". Well, do you, punk?

QUOTE(Gavin Burnell @ Nov 2 2007, 12:30 AM) You mean like an http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=5' target="_blank">obfuscated Hello World program?

In that case, don't bother. I think getting a real community will be hard and take time, but I wanted to do an initial test to see what the reaction is. It's not something which is worth putting too much effort into at the moment. Thanks for trying.

It seems you've made some changes, but they didn't really help. Is there any chance of asking the IPB people about this?

QUOTE(crelf @ Oct 31 2007, 03:57 PM) I always prefered "Walk this way"...

QUOTE(tcplomp @ Oct 28 2007, 10:22 AM) I still don't understand how I can get the All of LAVA feed into Gmail. Can you post a more detailed explanation?

QUOTE(BrokenArrow @ Oct 27 2007, 08:46 PM) I definitely agree. QUOTE(tcplomp @ Oct 27 2007, 08:54 PM) Create a Tool VI that: finds the center of the current selected wire, get the datatype, drop a system label with the correct make-up. I don't know how practical that would be on a per-wire basis (invoking it might be too time consuming), but we could probably do it for all wires if we add a tag to each wire describing its name. Of course, that has a host of other issues.

QUOTE(BrokenArrow @ Oct 27 2007, 08:29 PM) Why? The cluster is simply the state machine data cluster. It holds all the data the SM needs to do its work. I consider that concept to be very simple and elegant and it has the added advantages of making your work easier, your code much cleaner and of satisfying your requirement. If you don't use the cluster in subVIs, you don't even have to make it a typedef. QUOTE 2. Neat, but as I said in my last entry, this type of label could "get lost" couldn't it? Yes, it could.

A few additional relevant options for the present: Use a cluster for your state machine SR. This allows you to pass multiple values on a single wire and makes it easier if you need to add new states. Handling the value is simply a matter of unbundling and bundling by name. Use the label available in the system controls palette. Drop one on your FP and then drag it to the BD. It has the advantage of having its background adapt to whatever is under it, so you can place it on the wire itself and it looks nice. Create some merge VIs with the relevant labels. This will probably speed up your process somewhat.

QUOTE(crelf @ Oct 26 2007, 03:53 PM) Why not? You just set the default value to be an invalid value (e.g. NaN) and test for it. Checking for equality works perfectly well if it's a predetermined value.

At the moment, there is no other way to do this. You can see some more details here.