Klompmans

O O It seems like I should Read The F***ing Manual. I've looked at quick drop before but never saw the `super quick drop' option or the shortcuts - and without those it's quite useless so I dismissed it without looking further. My bad, should've had faith in NI. Although quick drop is not exactly what I'm looking for (I'd like it to be always-on) it sure seems like a step in the right direction. Imma try the Darren way as well as Vugie's VI (I guess I'll have to adapt it to obtain the exact functionality I want). Thanks guys!

Having been using LV for some time now, I start to get annoyed more and more by the incredible amount of mouse movements/clicks I have to make. For every component you need to move your mouse to the functions/controls box (or right-click), go through several submenus, find your desired function and place it on the diagram. I find that this is not only very (and needlessly) mouse-intensive, but also removes my focus from the code I'm producing, and thereby breaks my concentration and decreases the amount of code I could produce per hour. It would be much easier if this could be done with the keyboard, or some kind of command line interface. Just like in autoCAD, where you can produce a line either by clicking the `line'-button or by pressing the `l'-key and the spacebar. Adapting this for labview would mean that (just an example) typing `BO' - space would give me a boolean constant on my mouse cursor. One hand on the keyboard types the codes needed, the other hand on the mouse places and connects the stuff conjured up by the codes... I could keep my attention on the code itself (increasing concentration and efficiency) and greatly reduce the amount of mouse movement I need to make. I know, this would come at the cost of learning a 2 or 3 character code per function/control you'd like to place, but from my autoCAD experience I can tell you this is well worth the effort. Or, if people don't like to learn these codes, they can still use the mouse to find the appropriate icon for it (among autoCAD users there's also a group of people only using the buttons and never using the command line). It's a matter of taste - I'm more a keyboard kinda guy. Of course a shortcut-key needs to be provided to switch off the command line in order to put regular text on the diagram or in string constants and such. I'd say it's not a lot of work to include this in the next version of LV. Command Line Interfacers! Who's with me? Raise your fist! Klomp P.S. Submitted this idea on the NI wish list a few months ago. No response yet...

QUOTE (mesmith @ Jan 28 2009, 11:20 PM) Hi Mark, The core program should run in a separate thread indeed, the machine is using very delicate and expensive consumable items, and we'd like to protect this part as much as possible from any disruptions. In other words, if a user screws up and LabVIEW hangs, we need the core application to nicely put the system in a `safe state'. Therefore, we cannot make it into a library for it would still run under LabVIEW and crash along with it (I know that LabVIEW has different threads like UI, user1, user2 etc. but that still wouldn't do me any good if LabVIEW hangs. And I have seen LabVIEW go down sometimes...). For the moment the shared variable and Data Socket (which is just a more general shared variable as far as I understand) options look the most attractive. Thank you both, Klompmans

QUOTE (Paul_at_Lowell @ Jan 28 2009, 09:07 PM) Wow, you're fast. Thank you. Err no, the UI needs to be completely seperated so people can change it or use their own without changing the core application. Anyway, the Shared Variable or DataSocket option might work - I'll give it a try. The VIserver option doesn't work anymore as of LabVIEW 8.2 (if you try the example they give, it simply doesn't work). Thank you again!

QUOTE (Paul_at_Lowell @ Jan 28 2009, 05:10 PM) Hi Paul, Indeed, it needs to run without the labview environment. We'll need to communicate with it from either a labview-build executable (stand alone user interface), or from the labview engine (customizable user interface). At the moment third party tools (other than other VIs/labview executables) dont need to be able to communicate with it. Would be a bonus though. Thank you, Klompmans QUOTE (mesmith @ Jan 28 2009, 05:16 PM) A couple of ideas 1) Build the core program as an actual DLL (using the option in the LabVIEW Build Specifications in the Project Explorer to create a Shared Library). This exposes whatever API you have into the core program as conventional C/C++ functions. It's a good way to create core app that could be called from different languages/development environments. Calling it from LabVIEW then requires using a CLN. 2) If you're only going to run the core app standalone or controlled from LabVIEW, then you could deploy the app as a library (folder or llb file) and define some VIs as the API. You could then have a VI that serves as a caller for the core app built as an exe that would run standalone or you could call into your library of VIs (your API) if you want to build a specific UI. Mark Hi Mark, I'm a little unsure what u mean here, 1) If the core program runs from the DLL, I can call another vi in the DLL which can do something to the core program (something like a method vi)? 2) I can define some VIs in a LLB as the API, while the other subVIs in the library cant be called? Maybe it's good to mention here that we want to obscure the core program and its subVIs to the end user, except for the API of course. Thank you

Howdy all, I have the following problem: I need to design a program running a measurement setup, which needs to be separated in two parts: a core program running the hardware (and doing the actual measurements), and a user interface. So far it's not hard. However, the core program needs to be stand-alone/DLL, able to run without LabVIEW, while it should be able to receive its instructions from the user interface. It should be possible to run the user interface under LabVIEW as well as as a standalone. The reason for this is that some users just want to use a standard program (these users might not even have LabVIEW installed), while other users would like to customize/integrate the user interface into their own programs. My first try was to have an executable core program, and to use VI server to set booleans like start, stop etc. on the frontpanel. This worked under 7.1, but not under 8.6... Moreover, it feels like a strange work-around. Has anyone any ideas about how to implement this? I'd be very grateful. I've been looking in lots of forums, examples etc, but I haven't found anything useful. Thank you, Klompmans P.S. If this question is already answered somewhere (I couldn't find it, but hey, the internet is rather large), please redirect me, and I am sorry for bothering you. P.P.S. Sorry for the odd post title, I couldn't come up with something really fitting the problem at hand. I am kinda new to LabVIEW...