Jump to content

Aitor Solar

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Aitor Solar

  1. Oops, I haven't seen this until now, sorry :oops:

    One request from our customer is that he don't want to right-click and request control but to get the control automatically at first (and every) startup of the remote panel. Is this possible and how?

    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.

    Second question is again what is loaded to a remote client?
    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.
    I understand that the loading time depends on the "deep" of the used front panel objects.

    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 :unsure: ).

    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.



  2. thanks Aitor Solar,

    See my sample, the vi can hide the task bar firstly running, as I press hide window, the bar is showing ? why ? cann't hide it again.

    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.



  3. 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

  4. thanks Entropy, I think a simple sample will help me better. anybody can help ? thanks @!

    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.



    Download File:post-1450-1144673625.vi

  5. Ok thanks.. I thought it was possible because of my sequence structure.. So, if I understand, if I put a stacked sequence diagram, and place a event struture in the first part of the sequence, this event struture will be active for all the sequences of the sequence diagram?

    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.



  6. When I execute the VI, the messages appears and when I click "Ok" to confirm the stopping or closing of Labview, it works. The problem is when I click on "Cancel". The dialog box is closed, and the VI seems to continue working but the User Interface is blocked. I can't click on the buttons or modify a value anymore...

    Strange. Maybe after that event something executes and takes the control of the UI thread. Or perhaps you have a hidden dialog somewhere... :blink:

    Could you attach the whole VI?



  7. 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:



  8. Hi,

    does anyone know how to detect if a VI is stopped througth "abort"?


    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?



  9. So, it doesn't look like there's an easy way out. Guess I'll have to live with the 2 copies.

    Thanks for pointing that out, 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.



  10. I hate the thought of having 2 identical copies of a VI clogging up memory. :thumbdown:

    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.



  11. Point well taken, perhaps there could be an effect

    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.



  12. You can just associate "Value Change" event to the control path. It works well. See attach VI.

    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,


  13. :oops: Oh wait, I do know this one. I've been through this already trying to do the exact same thing. All drag and drop events only work within Labview. Doesn't seem too useful if you can't drag and drop from outside of Labview.

    Ok, thanks, you have saved me a lot of time trying :yes:. 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 :wacko: .



  14. - configuration of VI property. Dont really help, either (Sub)VI will be loaded/run on startup or the user has to click it in the Backpanel to have the VI popup.

    But how can I call it dynamically from the Frontpanel?

    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 ;-)




  15. I'm not sure if this is it, but do you have "Allow drop" checked in the Advanced menu for the control?

    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 :wacko: .



  16. 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?




  17. I do not foresee compression affecting program performance, since the vi's are loaded into memory off of disk prior to execution.

    Yes, but AFAIK that's not the case with dynamic called VIs. Could affect an application with continuous VI Server callings?



  • Create New...

Important Information

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