Jump to content

Aitor Solar

Members
  • Content Count

    259
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Aitor Solar

  1. 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
  2. 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
  3. 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 clien
  4. 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
  5. 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
  6. Here you have an example, it works. Saludos, Aitor Download File:post-1450-1144831619.zip
  7. 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
  8. 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
  9. 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
  10. 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 wai
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. You can use "Move" to rename directories, like old MS-DOS. See attached image. Saludos, Aitor
  19. 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
  20. 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
  21. 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
  22. 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 ;-)
  23. 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
  24. 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
  25. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.