Yair

You can open the BD of the VI, select the content and (if I'm not mistaken) even copy it to the clipboard.

I agree from a defensive programming point of view, but I actually consider the issue shown in the other thread to be a bug. I can see the technical reasons for why it was implemented as such, but as a user of the event structure, I most definitely expect the event cases to execute in the order in which the events were fired. I think this expectation is so basic and obvious that it doesn't even need to be documented. However, I can see some other potential cases where events would not be executed in the order in which they were fired (e.g. if an event structure needs to wait on a filter event, maybe it skips to the next events in its queue?).

There are a number of ways of handing continuous events. In the case of the Value Change event, the easiest thing to do is to compare the NewVal terminal to the control terminal and only perform the code if they are equal. This works because the control terminal always holds the latest value, but the NewVal terminal will cycle through all the intermediary values. If the false case of the structure has no code, the event structure will breeze through the events and will only run the code for the most recent value.

I know that this can happen if you have both dynamic events and static events fire at the same time because they go into two queues and the order is only determined by the millisecond timer. See here. As far as I know, this should NOT apply to val(sgnl) events you string together. I believe they should execute in order.

And not wanting to sleep on the couch?

It's probably because you need to exaggerate in order to get the non-enthusiasts to take notice. If you say "Those Europeans say guns are bad" no one cares, but if say "Those bloody French are trying to prevent you from exercising your consitutional right!" you will get attention. And it's by far not limited to right-wing organizations. Newspapers and reporters do it when they don't report a story accurately, reality TV does it when it edits things to show you only the spicy stuff and yes, even left wing organizations do it (various "human rights" groups come to mind. Some of them mean well, but have no idea what they're talking about and spread things which are simply not true).

Karissa, I pointed a coworker to this for something he needed and he really liked it, but we also have a couple of points of feedback: It's advisable to defer the updates when updating the display. If you don't, you see all the changes as they are made and (worse) you suffer considerable performance degradation if you have more than a few items. The XControl doesn't work correctly when building an executable. The reason is that the column width is decided by placing text in a decoration in a subVI and checking the size of the decoration. The problem is that the FP of the subVI is removed when building, so this doesn't work. The easiest way of working around this is creating a property node for one of the controls in the subVI. The node doesn't have to do anything, but just having it causes the subVI to keep the FP when building the EXE. You use the listbox as a storage area for the string array. I would suggest moving the actual string array into the state shift register and always operating on that. The listbox can than just be updated when needed.

I can't let everyone else advance their count and not join as well, so here's my congrats.

This is no longer true. At least so far, every version since 8.2 can save all the way back to 8.0. Yes, but the numbers are reasonably large. You may not be able to open your 5.0 VIs in the newest versions, but you can definitely open the 7.0 VIs. Why are these "highest" on your list? Do you move code between versions often?

The reparenting functions in the Win32 API are very simple (they basically just need the handles of the parent and child windows which you can easily get using the window name or even some private properties in LV), but there are some gotchas. If you search both here (although here the search sucks and many of the old attachments are missing) and in the NI forums for "MDI" or "parent window" you should find some examples, as well as some details.

You'd better make sure your boss isn't too friendly with the IT department, or come the next performance review, all those logged URLs could mean a lot of trouble.

The RTE size has been roughly doubling with every major version of LV, but LabVIEW is certainly far from the only one. Java and .NET are two examples that come to mind of frameworks which have run-times of comparable size. If you wish, there are any number of file hosting sites which will be happy to take your file for free and will take files up to a couple of hundred MB. Mediafire comes to mind, but there are many others.

There was a crash in the site which caused some attachments to disappear. We can ask the moderator to try to find them manually (which I've now done), but I don't know if they will find it or how long it will take them.

As someone who grew up playing games by Sierra, I would say that's a price worth paying. Wouldn't you?

Michael, the thread you linked to says this issue was fixed with version 3.0.5 of the forums. Since this is from two days ago I'm *guessing* you didn't upgrade yet? Is there an upgrade planned in the near future?

You're right. I didn't notice that now because I was actually looking at a subVI which had the output labeled something like "create new VI?".

Or something like this: I bet by now the OP is really sorry about posting.

I don't have any experience in doing something like this (and I doubt many others do), but it seems to me that the cumbersome syntax needed to call that many VIs by reference makes it impractical (and that's before touching on LLBs compiled for another RTE). In Java, this works because the syntax doesn't change. Some options, off the top of my head: Look more closely into VIPM. You might be able to use it to manage the all the versions and maybe automate some of the deployment process yourself. Similarly, you could have a build server so that you don't have to manually build the new version when updating the reuse library. Use more LVOOP. Dynamic dispatch can simplify the syntax (I think), but you will have to be careful about your dependencies and class hierarchies. Then again, you already know enough about that. Compile the reuse code in each version into LLBs and distribute that for each application. If app X was built in LV 2009, place the LLBs which were compiled in 2009 in its folder. You could probably even do this without and dynamic linking by configuring the destinations when building the EXE. OpenG builder or VIPM might help you there.

If I'm understanding you correctly, you want to compile your reuse code into enclosed components which you will dynamically link to both from the IDE and from executable code. Maybe we can call them Dynamic Link Libraries. What's your motivation for doing this? I can see some advantages, but it seems to me that the headaches involved far outweigh the advantages. That said, here's one possible implementation - You could probably use the Get VI Version method to get the version of the VI (although I'm not sure it will work when you run it in the RTE. You might need to save the version in the "DLL" somehow). You will then need to launch a background process with the correct version (RTE) and open and run the VI using VI server. As I said, I think the cons (not least of which are the perfomance issues you'll probably run into) outweigh the pros. As for this: Are you sure they both ran the same version (e.g. the EXE would have its own copy by default unless you explicitly call the VI on disk by ref)? Also, one way you could probably break it is by having incompatible typedefs like Ton said. There are probably others, but these are corner cases. I can't say I personally see the need for running after them. Of course, if you are going to be playing with this stuff, you will want to know what can bite you.

Here's the document. It doesn't mention what the output value should be, but as I said, the only valid values I know of are 1 and 0. LabVIEW_Dev_Environment_Event_Callbacks.rtf

And a hot pink and purple for the controls and labels?

No commercial entity can guarantee that it will do something before it knows what that something is. Contrived example - what if someone posts "I want the LV RTE to be 5 MB in size and work without installation"? Certainly, everyone would want that, but it would be impractical for NI to try to implement that. Obviously, more transparent criteria would be welcome, but I can understand NI not wanting to disclose such things, both because they're probably not set in stone (e.g. an idea might get more weight even if it wasn't very popular because NI realizes it will be really useful or really easy to implement) and because such things tend to become political (e.g. users will think "these criteria discriminate against me because X"). If you think it's not worth wasting time in there, that's your business, but you certainly don't have any other official course of action.

The idea exchange is extremely new (a few months) and didn't even have time for a single version in which to implement any idea. If you'll look at the status summaries, you will see that there are some ideas are in the implementation process. These are not necessarily the most popular ideas, nor would I expect them to be. Deciding which ideas to implement should not be based only on how much users want it, but also on other considerations such as how difficult it is implement, whether it's even correct to implement, whether it will become obselete due to other features, etc. NI had the product suggestion center before the idea exchange, and I'm sure that if they saw a good idea they didn't think of, they used it even if it wasn't already on the road map. The "black hole" nature of the PSC, however, prevents outside users from knowing how many of those ideas originated from the users. The idea exchange is considerably better (although it has its own share of serious usability issues). As an aside, expecting your suggestion to be one of the most popular ones is a bit arrogant, for lack of a better word. I've had several good suggestions which simply didn't get that many votes (which I hope will not prevent NI from implementing them). Incidentally, there was actually someone who posted an idea along the lines of "we need better controls" without specifying and (if memory serves) didn't get that many votes. On the opposite side, Altenbach suggested flat controls (with sample images) and got the votes. As Chris said, you need to have specific suggestions for people to be able to vote on them. Also, here are some which have already been implemented, include one which has been implemented as a direct result of the request and even released as a patch.

I'm surprised no one mentioned skinning a cat yet (or a Cat, perhaps? ). It just remains to be seen whether we'll get the same conversation that's been had recently (and in the meantime, I'll go hide under the couch). I would agree with Chris that skinning is far from a critical feature in LV and that the tools are already basically there. I would be surprised if other IDEs offer a built in method for skinning. For most, if not all, I suspect special (or pre-existing, like Kshif's library I linked to) code would need to be written. Also, one other method of skinning is using the system controls and colors. Granted, the GUI for controlling the actual customization is out of your hands and this won't work for non-system controls, such as graphs, or for different sizes, etc., but it is one valid answers. P.S. Re. LV as a "general" language, I don't think I ever heard anyone at NI say that either. They certainly refered to it as a general purpose language, in the sense that it's not limited to test and measurement, or whatever, but I don't remember them claiming that it's ideal for everything.

Actually, that's a bad example, as 8.5 and 8.5.1 were binary compatible and you did not have to recompile VIs written in one to run in the other. This actually presented a problem in fixes made in the code generation in 8.5.1, because if you had a VI which was buggy in 8.5, it remained buggy in 8.5.1 until you forced a compile (either by editing and saving or by force or mass compiling). The example is valid for older bugfix versions (and maybe newer as well). That's correct. Version X of the RTE can only run VIs saved in that version of LV. As such, the points made here: are also correct. For the last part, I'm pretty sure you would need to explicitly load the VIs in the correct RTE by running an application compiled in that version and using VI server to call that application (the app input on the Open VI Reference function), although I believe DLLs don't need this, presumably because they have a standard mechanism of using the correct run-time. As for the actual question, what are you trying to get to? I don't know Java, but it seems to me that binary comptibility is akin to the different versions of LV and source compatibility is akin to not being able to open code written in a newer version or to having your code stop work if the API's interface was changed (like the report generation VIs in 8.6 or the config file VIs in 2009 which were put into libraries and therefore caused you to lose the ability to do certain things (which, admitedly, were not in the public APIs as represented in the palettes). In any case, I don't think you have to borrow things from other languages. Some concepts apply and some don't.