Aitor Solar

Yep, and it's a pretty good system that allows a lot of customization like connecting simultaneously with several instances of the same executable, etc. Another option is to compile the exes as ActiveX servers, then you can communicate between them in a very similar way (in fact you just need one of them to be registered as a server, the other one reads and writes on it). An example is attached. The advantage of this system is you can communicate with the program through another languages, not just LV. That been said, I was wondering about the shared variables in two local exes too, 'cause it seems a simpler solution in some cases. My guess is they should be the network type, because for each one the other application is external, even if they are running in the same machine (the same holds true for VI server, when you must use remote access and a valid port number though you never go through the net), but unfortunately I still haven't be able to check it, because the shared variables crash my PC :-(. Saludos, Aitor

I found it funny. The problem is, you know, 1st April is not Fool's Day in all the world. Can we have fun of you in OUR Fool's Day? Saludos, Aitor

Oops, I haven't seen this until now, sorry Yes, it's possible. The easiest solution is just to embed the first remote panel in a html file. In the object call, include the request parameter: <PARAM name="REQCTRL" value=true> Or, if you are using embed, <EMBED (...) REQCTRL=true> From that point on, the client will have control of all the remote panels the first one launches. Now, if you don't want to use html files, I think (this memory of mine...) you can use the "Remote Panel Client Request Control" Application method from the LV instance in the client machine. That's a difficult question. From my tests, it seems it transmits all but the block diagram objects. That is: the front panel, the code and the data. Because of that, is imperative to check the default values objects have, because they go in the data part; I had a big bad problem caused by an array which default value had thounsands of values; incidentally I developed a VI that checks memory usage of all VIs to avoid this kind of mistakes. In fact it depends on a lot of things, as IMHO the RP protocol is not as optimized as should be. That way, net acceleration and compression work great when downloading a remote panel and reduce loading times (but strangely, the data like graph plots or signal arrays don't seem to go faster with this kind of systems). For example, in my original tests I saw the amount of data sent was roughly twice the needed. Luckily, NI developed a patch for 7.1.1 that resolved that error (I don't know if it was a public patch or just for us, I tstll have to check this in LV8 to see if it's included ). I hope you still need the info; if you have any doubt don't hesitate to ask, even if I don't know it (something usual), I'll check it because I have a heavily remote-paneled application and any new info can make it better. Saludos, Aitor

Not sure, but probably a minimized state prevents a VI being un-minimizeable, sounds logical. If you want to minimize and not to have a taskbutton (that is, the VI to dissapear from view), just use the "hidden" FP state, is much simpler. Saludos, Aitor

I had the same error yesterday (with 8.0.1), it was caused by an empty "black" tunnel too, this time in a case structure and it was pretty hard to find. I had to delete case by case to find the culprit. Saludos, Aitor

Here you have an example, it works. Saludos, Aitor Download File:post-1450-1144831619.zip

IIRC, when a front panel has both "allow user to resize window" and "allow user to minimize window" options disabled, it has no taskbar button (maybe the same happens if its modal, I don't remember). If you want to get rid of the LabVIEW taskbar button too, use "HideRootWindow=True" in the application .ini file. To have the taskbar button back, just change those options dinamically through a VI Server call (FP.Resizeable and FP.Minimizeable). Hope that helps

OK, here you have an example of simulating a keystroke. But as I said, if you just type "simulate keyboard" or "simulate keystroke" in the ni.com search, you will find more. The same applies for the cursor change, is not so difficult. Saludos, Aitor Download File:post-1450-1144673625.vi

You can use the Windows API to simulate keystrokes, use user32.dll (keybd_event), there are examples in ni.com. As to disable mouse / keyboard, probably there's a similar method but I don't know it. You can change mouse cursor to an empty image, so the result would be almost the same. Saludos, Aitor

AFAIK, event listeners are active all the execution. So well, it's not impossible have two event structures, just a good advice. But if you have two or more event listeners (structures), and (like in your case) they listen for the same events, all of them will respond to that event, even if execution haven't reached their sequence yet. In fact, you could just uncheck the "lock front panel" option in the second event structure's registered events, so the FP won't hang. But I think that's not a good solution because when you reach the second event structure, you probably will already have a waiting event. Since that the "just one event structure" advice. Saludos, Aitor

OK, I see the problem. You have two event structures, so the second one is taking control... but execution is still in the first frame, so it doesn't respond. You can't [OK, too strict, you just probably shouldn't] have more than one event structure for one front panel. You'll have to remove one of them. Saludos, Aitor

Strange. Maybe after that event something executes and takes the control of the UI thread. Or perhaps you have a hidden dialog somewhere... Could you attach the whole VI? Saludos, Aitor

Notifiers (and queues, etc) don't work between different applications, like two exes. You'll have to use another way of sharing information, like ActiveX. Will LabVIEW Queues or Semaphores Work Between Executables? Saludos, Aitor

As said before, the key here is the degree of control you have over that DOS application. ActiveX is the easiest way of communication between two applications, but it requires the app is prepared for it (or, as Irene_he points, the possibility of changing its code). You always can try DDE, the old way of cross-application comm, still supported by LV, but you will have the same problem if that app is not prepared for DDE. Or reading/writing files for exchange info... If you don't have any control over that DOS program... I don't see any solution right now :thumbdown: Saludos, Aitor

Ummm. You can program the VI to change the value of some boolean indicator when it finishes normally (well, just the last thing it does before the end). So, if it's aborted, that value would be different. Is that what you were asking? Saludos, Aitor

You're welcome. I don't know your application, but I'm pretty sure you could find a way of not having that VI as a subVI. For example, if you launch it through VI Server (i.e., dinamically) and check to true the "Wait until done" option, the program behavior will be almost the same as if it was a normal subVI. Saludos, Aitor

I'm afraid you'll have. Keep in mind that the subVI is loaded in memory under your program, so when you try con control it programmatically, you are fighting against your own code. In my experience, when you call programmatically a VI you shouldn't have it as a subVI, even if that subVI is never called or is disabled. My advice is to avoid that situation. If that's impossible, try calling it as a template (because each instance will have a different name and different memory allocation). Hope that helps. Saludos, Aitor

You can use "Move" to rename directories, like old MS-DOS. See attached image. Saludos, Aitor

Maybe. I have compared VIServer launching times for VIs in llbs and as independent files, in LV7.1.1. Independent files are launched about 3% faster, not a great deal compared with the rest of time-consuming actions. I still haven't checked it in LV8, though. Saludos, Aitor

Yep, it's a good advice, thanks. In the end, I have emulated the pane behavior I was looking for by creating a transparent path control that covers all the FP. When VI is frontmost, the path control goes invisible, allowing the user to manipulate the rest of controls as usual. When VI is not frontmost, the path control goes visible and so it catches the files the user drag'n'drop from Windows. Maybe not the cleanest solution, but it works. Thanks everybody, Aitor

Ok, thanks, you have saved me a lot of time trying . But it's still a pity we don't have an event for external drag'n'drop. I'll forget that feature, then. Just thought it would be great to add that to the application in the LV8 version. In fact, what I had in mind was having a drag'n'drop event for all the pane, like Word, etc. But I guess that's even more impossible . Saludos, Aitor

Err, I think we have a misconception here. I don't know what is the Backpanel, but if you are talking about the Diagram Block, keep in mind that's where the code goes. All the user sees is the Front Panel. Now, in the FP you have to put a control for the user to select which VI he wants. You can put several buttons or a ring, or an enum... In the BD you have to check a value change in that control, and launch the selected VI (for example, a case structure and each VI in its case). Be sure the VIs are set to "show front panel when called". And then, of course, you have to run the program ;-) Saludos, Aitor

Yes. In fact it's true by default for path controls. I don't know, maybe this event is just for inner LabVIEW drag'n'drop . Saludos, Aitor

Hi all, I must be doing something wrong. I want an event to control when the user drops an external file into a Path control. So, I create an Event Structure and add an event case ("Drop") linked to the path control. I drag and drop the external files: the Path updates with the new file path, but the events doesn't trigger. What else is necessary? :headbang: Saludos, Aitor

If you don't want to have all the VIs loaded in memory, you can call them dinamically through Open VI Reference (you'll find it in the Application Control palette). Not really sure if that's you're looking for, though. Could you elaborate? Saludos, Aitor