Yair

QUOTE(Dirk J. @ Jul 20 2007, 05:03 PM) How is that one any more pure G than the other version? The problem is that uses OS API functions, which in this case will only be available on Windows. I did all my LV work until now on Windows (some of which included interacting with .NET, which is definitely purely Windows so far), but I prefer to avoid OS calls if they are not necessary. In this case, I consider LV's dialog to be good enough, but if I wanted to use this one, I would probably wrap it in a dynamic call.

I just wanted to alert the next person who thinks about posting here that it will be post #333. That's bad karma. You'll be jinxed! :!: Don't do it...

The code would probably be more understandable if you encapsulate the control of the subpanel into subVIs and use arrays to define the properties of your valves. Another option is to use a picture control to do this. You can use the code to decide exactly where each valve should appear and calculate when the user clicks on it, but this method is more complex and has its drawbacks.

QUOTE(Dirk J. @ Jul 20 2007, 02:51 PM) And here's a VI you can use to select the parameters. Now we just need to bundle them together nicely and we're good to go. BTW, I had this VI on my hard drive for a long time, but I avoid it because it's not pure G. To get it play nicely would require only loading it dynamically if you're in Windows and testing for each Windows version, etc.

QUOTE(Dirk J. @ Jul 20 2007, 01:44 PM) The only one you really need is the window handle and that's easy - you just need to call FindWindow from User32.dll and give it the window name (for a VI, this can be accessed using the FP.Title property). The only other option which has some importance is the uFlags parameter, which should be managable by creating a cluster of the boolean options and then converting it to a number. The numeric values of the different options are specified in the shlobj.h header file.

Also, you can have your questions about the event structure use, but I doubt you would get much from the answers. It's obvious the entire application was written quickly (4 hours at night) and so style was not the most important concern. If you're looking for prime examples of how to use event structures, I wouldn't look at that one. It works fine, but it clearly wasn't designed up front with a lot of thought.

If multichart is a subVI, the easiest solution is probably to set those rings to be in the connector pane and then you can feed a value into them when you call the subVI. Invoke and property (or attribute, in your case) nodes are used with object oriented systems (including ActiveX controls), but I don't think it will help you much in this case, because I'm pretty sure LV 5 did not allow accessing the attributes of controls in other VIs. You can do this inside the subVI (for instance, by wiring the selection array into the subVI), but you need an attribute node with the Value property, not an invoke node. Another option is creating a local variable for the control and wiring the value into that. Your other option would be to use some other means of transferring the selected values into the subVI, like a global variable or a functional global.

QUOTE(Lars-Göran @ Jul 18 2007, 09:36 PM) I would have to claim as well, but I'm guessing NI will demo\announce the next version of LV at NIWeek, and I wouldn't be surprised if they will also demo this toolkit. That means you should probably have your answers in about three weeks.

And be sure to check out the lounge. Sorry, that's what you get when you use the View New Posts button - members which don't notice where the post they're replying to actually is.

QUOTE(Val Brown @ Jul 17 2007, 10:14 PM) Do you have the RT module installed on that PC? If I remember correctly, there are two versions of the legacy VIs - one which uses VISA internally and another which uses serpdrv. I remember seeing the second kind in a computer with RT installed, but I suppose it's also possible it is installed by default if you do not install VISA.

Well, I did notice those small balloon icons about two or three weeks ago, when they were added, but I thought they were just meant to make the link stand out. I never hovered over them. I actually noticed this now because I hovered over Tomi's signature and that triggered it. I then (I'm not sure why) hovered over one of the icons at the top and that triggered it too, which was why I figured it was a new feature, since I thought I probably would have seen it before. Providing previews to text links does actually seem to be useful. I will leave this on for the moment and see whether I like it or not.

I just noticed that the site had snapshots for certain links (those are in-window popups which provide you with additional options for a certain thing. You can see an example if you hover over the Digg this, Google this, etc. bar you get at the top of the page when viewing posts) and I was wondering what people thought about them. Personally, it seems to me that they introduce too much clutter. I see where they're coming from, but if I wanted to follow a link, I would just click it. I don't need it to barge into my current page. Then again, this is just an initial impression. P.S. Regardless of what I will end up thinking about this, thank you Michael for trying to improve the site with new features.

QUOTE(orko @ Jul 17 2007, 11:08 PM) :thumbup: QUOTE(Michael_Aivaliotis @ Jul 17 2007, 11:18 PM) Ah, you mean LAVOOP. I love it. :thumbup: Likewise. Very good. QUOTE(Tomi Maila @ Jul 17 2007, 11:44 PM) What about LabVIEW Object-Oriented Dataflow (LVOOD, pronouced 'Elwood'). Oh dear, is that the http://forums.ni.com/ni/board/message?board.id=170&message.id=259564#M259564' target="_blank">second Blues Brothers reference today? :laugh: I still say go with BUGGER.

Actually, technically I think it's not , but we'll let that one slide.

QUOTE(Jan Florjanczyk @ Jul 17 2007, 08:30 PM) The data itself is saved in the VI as a hierarchy of objects, where each structure has its own subdiagram. I'm guessing that the images of the primitives and the wires are bitmaps which are changed according to how you wire the diagram. SubVIs obviously are and so are external nodes. I'm assuming that Xnodes are the same, but I haven't checked it. P.S. Jan, is that an xkcd comic?

I vaguely remember having some problems with that (get serpdrv, put it in the right folder, watch it not working etc.), but the only thing I can say for sure is that the application was ported over to 7.0. As you said, LV has the serial compatibility VIs, which maintain the old interface, but use VISA behind the scenes, but presumably they could disappear at some point in the future.

Seems to be back to normal now. I just got an email right after a post was posted, although the couple of replies before it took roughly 60 and 30 minutes.

I would go with MS Bob. Oh, you can't do that, sorry. XP and 2000 use the same code base, so there shouldn't be that much of a difference between them, but I would probably go with XP, because it's newer and would have support for a longer time period. I haven't seen any serious issues with it if you take care of it properly. It's also (probably) more likely to work with current and future hardware if you need to replace your serial interface. As for working with 5.1, are you using VISA? I remember trying to port a 5.1 application which used serial communication to XP and I eventually had to rebuild it in 7.0, but I'm not sure that was because of the serial comm and that one was using the old style serial VIs anyway.

Relying on the exe extension is problematic. You might have a file which is not an executable file but has an exe extension or you might have a directory which has an .exe at the end of its name or you might be running on Linux or Mac, where you don't have the extension. A better way would simply be to use the property I mentioned and then output T or F based on its value. Another option for simplifying the subVI as it is now is to to use the Call Chain primitive and index out the second element, which would be the calling VI. You can then open a reference to it and get its path using a property node instead of having to wire its path into the subVI, but I would advise the first method. As for the base path VI, it suffers from the same basic problem. I prefer the OpenG method, which is basically getting the path of the VI (using the method I mentioned) and then stripping in a loop until the File/Directory Info primitive returns T in its directory output, like this quick example (which does not do error handling): http://forums.lavag.org/index.php?act=attach&type=post&id=6380 This is also platform independent.

Is it just me, or have email notifications been arriving lately over the past week or so? I just saw a reply which was given almost two hours ago to a thread I replied to and I still haven't received an email about it. There were several other examples as well. P.S. My notifications are set to be immediate.

The Application class has a property called Kind which will return an enum telling you whether you're running inside LabVIEW or in a built executable. You can get it simply by dropping a property node on the diagram.

QUOTE(LV Punk @ Jul 16 2007, 03:15 PM) My thought exactly, and I was even planning to try to use it to practice XControls. Mike, it's really nice.

As both Ton and I said, you should post the code. We can't see the problem just from your description. Also, don't start multiple threads. Choose one thread for your problem. The elapsed time VI posted to the other thread is basically the same as the Elapsed Time express VI, but if it doesn't help you, you should be explicit about what it is you need. As mentioned, you should probably read a few tutorials about LabVIEW first.

I'm impressed by the code (and the icons ) and it doesn't seem to be that much of a hack, but wouldn't it be simpler (and definitely more platform independent) to write a simple file browser using a listbox, where you can enable multiple selection?

Why weren't you using a queue in that case? That would be the right tool as a notifier can only hold a single notification.