smenjoulet

Why can't you dynamically dispatch off the user event and resort to casing out based on class name. DD works for me. See attached. I guess Stephen alluded to this in his post. Not sure if I'm really answering your question or just misunderstanding, but you can register/unregister for user events during runtime. Doesn't that qualify as add/remove. Again, see attached. I apologize if I'm not following you completely. Then what's going on here in 2009. Am I missing something: Class User Events Folder.zip

OK, I got piping/redirection to work. The key was some code/info posted on this C# thread. There are a couple more kernel32 dll calls now, so it's even farther from pure .NET. However, it works pretty good, both from console and System Exec. Next up: Develop similar method to allow a LabVIEW program to accept input from StdIn. -Scott Write Std Out with Redirection.vi

No, nothing special in the ini. In fact you don't even need the ini. I'm on XP and Jim has tried it on Win7. What are you using for the command line in System exec? I wouldn't expect a console Window to open (I don't get one), which leads me to believe you are using cmd /c or start on the command line. Just try the path to the exe and see if that works. -Scott EDIT: I see you've already figured it out. I'm working on the redirection issue. If I get it figured out, I'll post the solution.

Here it is. I've called it from System Exec in both 2009 and 8.6 and in both cases I get output in the 'standard output' indicator. If it still doesnt work for you, can you add any info about your setup. -Scott testso.zip

No. If there is a pure .NET way, I haven't found it yet. I haven't searched real hard, so it may still be out there. Positive. I just tried it again to be sure. I'm on XP. To be honest, I was a little surprised that it did work. More about that below. I don't pretend to fully understand it yet, but my interpretation is that you're not really writing to stdout, but to the console which I think is a distinct but subtle difference. That is why I believe (at this point) that piping and redirection don't work, but also why I was surprised that the .NET WriteLine output appeared on stdout of System Exec (at least for me). There's a contradiction there, so more investigation of what is really happening is needed. -Scott

Interesting. I haven't looked into it any further but if you use the .NET methods, it does work with System Exec. I've attached an example (LV20009) which allows writing with both kernel32 dll calls and .NET. The writes using the dll will not appear in STDOUT as you found, but the writes using .NET will. Also, neither method as used works with redirection or piping, but it might be possible to get that to work as well if someone wanted to investigate it. IIRC, The method in Linux of writing directly to dev/stdout with the file functions does support redirection at least (never tried piping). -Scott Write Std Out Example.vi

As far as .NET goes, you can use System.Console to control your console window (write, write line, position cursor, etc.) but unfortunately I think you still need one API call to kernal32.dll for either AllocConsole() or AttachConsole() before any .NET calls. You can then either use asbo's solution using start or use the props/methods of System.Console to position the cursor and "erase" part of the screen before writing your text if you're just wanting to make it look nice. The latter is a little hacky. If there is a pure .NET solution, I haven't found it, so if you figure it out let us know. Incidentally, in Linux I always just used the 'Write to Text File' function with a path of dev/stdout and it worked great. -Scott

AQ, Out of curiosity, is there any particular reason you used a single iteration For loop over a single iteration While loop in Get Reference, or is it just your preferred way to build it? -Scott

First, Norm, thanks for the kudos. This was born of a desire to have a pure G app interface/control scheme similar to ActiveX, hence the name. And no, I didn't name it, but it managed to stick. I'm not going to add anything to his post. He explains it pretty well. If you decide you want to look at this technique further and need some more guidance, I'm sure one of us will help you out. Second, while VI server can be a bit tricky, the discussion is making it over complicated. Here is what you need in your EXE's ini to make it work: [your ini] Yes, that's right. Nothing. Of course that's an oversimplification, because then you have to manage the VI server settings within your application yourself (setting it enabled, setting port, setting machine access, setting VI access, etc.). The defaults will be port=3363, server=off, machine access=localhost, VI access=*. If you are at all concerned about security, that may be your best bet. If not, the following settings may be a little more reasonable: [your ini] server.tcp.port=xxxx server.tcp.enabled=true That will set your port and enable VI server. Machine access will default to localhost and VI access will default to * (all VI's accesssible) If you want to set only specific VI's as accesible than add the line: server.vi.access="{your VI names/patterns}" To change machine access settings, add a line like this: server.tcp.acl="290000000A000000010000001D00000003000000010000002A10000000030000000000010000000000" -> This is the value to give all machines access. You can set all this in your project properties and it will be part of your ini when you build. If you go with the small exe, then the technique Norm describes will work great for you. No need to periodically monitor a file. Just send a message directly to the app. Or simply just run a VI remotely to load/launch your main VI. Also, it is possible to load/run your main VI directly into your small app (from say an llb build) to do the work if you didn't want to launch a separate exe. Lots of options... - Scott

Boo, I say to that! Here I thought you were a thoughful intelligent human being and then you had to spoil it. j/k... Seriously, great series for the Pens. I liked them a lot better after they got rid of that doofus of a coach Michel Therrien. Look forward to three in a row! -Scott Oh, yes... Kudos to you, Toby, for your accomplishment.

Nice! While I think the lightwieght exe approach would work great, here's another alternative for you to consider. Look at the SysInternals tools (now a part of Microsoft), specifically PsExec. This allows you to run processes on remote machines, provided you have the proper access of course, which I assume you would. -Scott

Because it is part of a library and is marked as a private item. Looks like you'll need to use the one from 8.6. -Scott

Changed Name and location C:\Program Files\National Instruments\LabVIEW 2009\vi.lib\Palette API\ResMgr\Save Resource.vi -Scott

But wait, the sequence structure doesn't have a frame selector, so it "could" be a flat sequence structure (or maybe a 1 frame stacked sequence). That might be more presciently palatabe. Slightly...

Sure, but the NRA and "climate-change" deniers might stand in your way!

OK, now I see what your problem is and why I didn't see it. The problem is with the default VI server port, not that the IDE is preventing another VI server from functioning correctly. Only 1 server can run on any given port at a time (of course). If you have the VI server set to startup in the exe (per the ini) and don't specify a port, it will try and start at port 3363. If any other VI server (LabVIEW IDE or other exe) is active on that port, then the VI server for that exe won't start. If you try and set the port to a different number later and restart the server, it will generate an error and not start. Actually, in LV2009, it looks like even if the server isn't enabled in the ini, you can't restart it later on a different port. That may be the intended action by NI for some reason, but it seems like a bug to me and I don't recall how it worked in earlier versions. In either case, the property node for server port will return 3363, even though the node didn't generate an error when trying to set it to a different number. That also seems like a bug to me. The reason I didn't have any problems on my end initially: I never run my IDE on the default port! So how to fix it... Use a defined startup port that the VI server for the exe will start on. This is only for startup so it won't conflict with any other instances of your exe. Find an unused port and reset the VI server to use that port instead of your startup port. That frees the startup for use when another instance of your exe launches. Hope that helps! -Scott

I added a little bit of code to read back the current server port in my snippet and it returns the value I last set. As for actual testing, I open a connection to the exe from LabVIEW and ask it for some information (e.g. exported VI's in memory). If the port I'm using in LabVIEW doesn't match the port setting last used in the exe, it doesn't work. When they match, success! -Scott

Well, I don't know what's different about your environment, but I just tried the snippet I posted and it works fine for me. Can you post a VI or snippet of what you're actually doing? -Scott

Yes, you can. See the attached snippet. Just drop it in a project and make a build. You can also put it in the ini as Antoine explains, but this allows you change it on the fly or keep it private, if that is your intent. -Scott

Assuming you never post again (yeah, right!), I estimate I would catch your post count at about the same time you catch me in the kid department (at a modest 4.1 posts per day) . That is if you wanted to take up that challenge... Congratulations Chris! Now go put some skates on that boy.

This should get you what you need... (In case it's not clear, ActPlot is Active Plot) -Scott

John, I think what you want is under the preferences (Edit >> Preferences...). See the attached image. Also, in your workspace configuration, you probably want Submit Options set to 'leaveunchanged+reopen'. -Scott

You need to look at the next I16 value after the base type. 0x03 is a waveform; 0x06 is a timestamp. The current version of OpenG LVData/Variant tools don't catch this. But the NI tools (...\LabVIEW xx\vi.lib\Utility\VariantDataType\...) will catch it.

I don't know of one and it probably doesn't exist, but I bet you could code up a quick utility or JKI RCF plugin that will do the trick. I've already tested that the Remove Structure method of the Structure class will do exactly what you want. - Scott

That's what it does. The path doesn't have to exist for strip path to work. It will give you the stripped path and the stripped name. I haven't had any problems with this. I think the issue is what it should do with \\server\share UNC name. Rolf explained the technical details. It may not be what you expect, but it is consistent. The nomenclature \\server\share is similar to a drive letter (i.e. X:\). If you try to strip past X:\, you'll get X in the name an empty stripped path, the same as you get for \\server\share. -Scott