Jim Kring

I have heard that the "Conditional Disable Structure" does not work for blocks of code that call subVIs. Maybe this is why you ran into problems, on occasion.

This is exactly the problem that I am having. I am spawning communication handers and my application stops communicating when the root loop hangs -- For example: when the General Error Handler (or other dialog) is open. Talk about annoying!

xeyes is an application that has a window with two eyeballs that look at your mouse position, presumaby so that it is easy for you to know where your mouse pointer is located. It is available on almost any Xwindows system (used for Linux displays). I opened the xeyes app so that it would be obvious that it was a linux environment. If you want to try out xeyes, there is a Win32 version that you can download from here: http://www.shemesh.biz/code.html ==> Win32 Xeyes -Jim PS - your desktop picture is scary

I do Linux development on my Laptop using VMware Workstation (an x86 emulator), and I have 3 LabVIEW for Linux versions installed in addition to the four versions that I run on Windows XP.

After thinking about it, I thought that you had hidden a feedback node: But, after reading your hint about data sources, I realized that the code "makes sense":

I see the same thing!?

If you are referring the Dev Zone forum thread, it is located here. You need to send the following command, first: MAIL FROM:<you@email.com> Take a look at "OGIC_SMTP_Main.vi" which provides a working example. Regards, -Jim

In my experience, LabVIEW cannot load two different DLLs with the same name at the same time.

Wire a valid string control reference into "Server Response IN". This is used by the VI for sending status information to a user interface.

I suggest that you work on an example, and let others help you along.

You can add this to your LabVIEW.ini file: coerceFromVariant=TRUE This will cause Variants to automatically coerce to any data type. But be careful, there is no error handling. I wouldn't use this in your applications, but it is interesting.

Hmmm, it might be possible, but what I think you want to do is create a CTL file (which is a VI of type custom control) and then set it to be a strict typedef. Then drop this item using the New VI Object function, using the typedef CTL file's path as the source of the new object.

Hello, all. Michael Aivaliotis gave a good NI Week presentation on process spawning. One factor to consider is the apparent limitation of LabVIEW in that it cannot instantiate new VIs when the root loop hangs (please the bug posting here for more info). Do any of you out there use this (Process Spawning) design pattern?

I didn't write LabVIEW and I don't know exactly how the guts of it works, but it appears that the Root Loop (a synchronous task handling loop at the very core of LabVIEW) hangs when the pull-down (or Run-Time) menu is in-use, a pop-up menu is in-use, or a dialog (such as the error dialog, file dialog, etc) is open. By "Instantiate New VIs", I mean: Open a VI Reference to a VI on disk that is not already in memory Open a VI Reference to a reentrant VI, thus creating a new instance Open a VI Reference to a VI Template on disk, thus creating a new instance The implication of this fact is that one cannot: Spawn a process using either the VI Template or Reentrant VI approach Instantiate Instances of OpenGOOP objects (which use a reentrant VI instance as the data store) This is too, bad since spawning VIs is a very powerful technique. Is this a problem/bug for the majority of the power-users out there? IMO, process spawning and GOOP are very important design patterns that my applications cannot live without. Is there something that I missed and is it possible to get around this issue?

You can also read the image file into a picture control and save the picture control's default value once it has been populated.

Often you find the need two run an instance of the LabVIEW development environment on the host PC and the RT target simultaneously. This is useful for debugging a client-server applications where you need to debug the client and server simultaneously. This is very easy to do in Windows. Take a look at the following FAQ: How to run multiple instances of LabVIEW You can create two batch files that will each open a new instance of LabVIEW... L_Drive_LabVIEW.bat subst l: "C:\Program Files\National Instruments\LabVIEW 7.0" start l:\labview M_Drive_LabVIEW.bat subst m: "C:\Program Files\National Instruments\LabVIEW 7.0" start m:\labview When you reboot, the L:\ and M:\ drives will disappear. Or you can use the /d switch to delete the temporary drives. Use the /? switch for more info on the SUBST command.

Norm, Set a session cookie with a unique session ID once the user successfully logs in. This cookie will be destroyed by the user's browser when they close their browser or there is inactivity (~20min). You can also destroy the session on the server side, by overwriting the cookie and destroying the session ID in your "active sessions" look-up table. On the server side will will need a map (lookup table) between session IDs and user/session information. PHP, for example, stores these in files located in the temp dir: /tmp/sess_{SESSION_ID} Best of luck, -Jim

It should be noted that HTTP and FTP are only supported on Windows :thumbdown:

I had a lapse of reason -- the VI that I wrote doesn't coerce variants, it strips typedefs. I solved a different, but related problem. I'll think about the original problem some more.

Ed, here (attached) is a spec file that will package NI's PID Control Toolkit, if its installed. This won't work with the current release of the OpenG Package Builder, since the package builder does not allow pathroots in the Source Directory of a File Group. I will re-release a new version of the OGPI that does support this feature, so that the ni_control.spec file will build correctly. I can work with you to create spec files for all the toolkits, which will allow you to create your own OpenG Packages, from the installed toolkits. You can, oviously, only distribute the OpenG Packages inside your organization, insofar as you have appropriate software licenses for the toolkits. Regards, -Jim Download File:post-17-1091488235.zip

Michael, it is possible and much easier than I first thought. Here (attached) is a working, and fairly complete solution -- it supports compound types including nested variants (variants containing variants). It is currently sub-optimal for arrays, which can be improved... but that solution is also non-trivial :laugh: Jean-Pierre (et al.), I was thinking that we could use this VI as a replacement for "Remove Typedefs from Variant" in the lvdata package. Maybe we could add a "Recursive?" boolean argument that defaults to FALSE so that the original behavior is preserved for existing users (but would they even want the original behavior?). Any thoughts? Cheers, -Jim Download File:post-17-1091340674.zip

Take a look at this posting.

There are binary files, and only NI has the tools to read and write them. These can be created using the palette editor. There are instructions in the LabVIEW User Manual.

Nope. It's still there in 7.1.

Well, I'm not really, back. I am stuck in a hotel in Albany, NY :headbang: I was thinking of testing that VI, but I figured that it would work. I didn't realize that the coercion only occurs when the output is strictly typed... too bad. Yes, this would be a non-trivial problem to solve in G. For now, we'll leave that one for the wishlist, I guess. Cheers