didierj

:headbang: O.K... It was Friday, I'm an ingeneer, my brain searches to often the complicated solutions instead of the evident...

at least if you want to limit the elements to numeric here is a first approach: It doesn't limit everything (e.g. multiple decimal points, minus in the middle of the number, exponential format,...). But if the value isn't valid when you remove the focus (value changed) the entered text is corrected. To get a full value-element into the table, I'm still working (and chewing) on it. To use the arrow keys use the event structure with the "Key Down?" event. there is an output terminal "VKey". It gives you an enum-element to the special key pressed (Enter, Arrow up/down, F1, Alt,...). I agree with you that the table could get an update, allowing custom elements, like numeric, rings, boolean,... Didier [Edit] Picture updated

From what I have seen in a few minutes, this options reveals a "huge" set of properties and methods from the Property Node- and Invoke Method-primitives. If they are different from the "SuperPrivateScriptingFeatureVisible", or just arranged in a different matter, I haven't checked. I think the topic BD.Open VI property falls into this segment. ...all in all, another nice and creative keyname. Does anyone could find enough time to try if combinations with ,"huge","mega","giga","private","hidden","unrevealed",... resolve to any valid keyname in LV.ini??? Didier

Try it and your installer will stop with an error, reporting that an installation is already ongoing... :thumbdown: IMHO running the two installations from batch-files (what will result if I can't include the rte into the app installer) is a bit old fashioned. Especially I'd like to make the stuff transparent to the user and avoid the additional panels. BTW I was already asked to provide the program in swedish, danish,...

Unfortunately, I suspect this won't work, since the content of the applibs directory is totally different from the rte directory under Shared. In shared you'll find the dll's and the control prototypes and in the applibs they are packed into the ".msm" merge modules which (to my knowledge) are used for the dist-kit builder. Tell me if I'm wrong Didier

sorry Thomas, if I repeated what you already said. Seems as we just got into a "race condition": you sent your answer while I was still typing....

First of all you should know what oo is... :thumbup: The openGoop is a form of static classes. For each class (NOT the instances) in your project define an unique name. Each class is then organized in a directory structure. The structure holds the subdirectories: core: all the vi's needed so the opengoop works properly data structure: the controls (typedefs) so the opengoop works properly template: templates of the public methods create by your own: public: place where you will put your public methods private: place where you will put your private methods, create if needed. In the data structure you get a typedef <class name> data.ctl: edit it at your whish so it holds all the properties of your class. After editing it go to core, open <class name> Object Data Store VI Ref Type.vi and drag-n-drop the sub-vi from the block diagram onto the "VI Refnum" on the frontpanel. Also in data structure open <class name> Object Refnum - Enum.ctl and edit the text in the enum with e.g. the class name. That will give you a reference typedef that is unique to your class. In core" you'll fine the vi's <class name> Get Data.vi, <class name> Get Data to Modify.vi and <class name> Set Modified Data.vi These are primitives that give you access to the INSTANCE properties. You'll have to handle the properties in a whole (organized in the cluster you saw in the <class name> Data.ctl)! With Get Data just read the properties, with Get Data to Modify read the data an lock them (to make modifications) and with Set Modified Data write the modified data-cluster back and release the lock. NEVER try to access the properties in any other way, you'll run into race conditions and probably loose data. At the end open <class name> - VI Tree.vi and close it to save all changes. Also put your created public/private methods in this vi. The intention of this vi is to be the "central class management point". When implementing an instance, use <class name> Create.vi (derived from the template). You get a reference that is (this time) unique to your OBJECT! When you want to call any other method or the properties ALWAYS wire this reference or you get errors. Implement your methods based on <class name> Read Data.vit template when you don't have to write back something to your properties. Implement based on <class name> Modify Data.vit when you modify properties. At the end, when the Instance isn't used anymore release the memory with <class name> Destroy.vi. To find an implementation look at my version of the pop-up menu in Popup menu. Also have a look at OpenG.org: OpenGOOP. It hold's further descriptions. Didier

Hi, Does anyone know a place where to find the contents of the "<lv dir>\applibs" for the different (german, french) languages in a windows system? To explain my problem: I have an app that I want to distribute in english, french and german. The labview app-builder allows you to select the language for the installer, but (that's the problem) JUST the installer, not the runtime on the target system itself. It is in the language of your development system. When the user then runs the "german app" and e.g. right-clicks a graph he gets an english pull-down... not really the behaviour of a "good" program. :thumbdown: Especially I'm looking for the ".msi" modules in french and LabVIEW version 6.1 (found the german version somewhere inhouse)! Didier ...it's not an option to run the rte-installer (downloadable from ni.com) after the app install!

In your example you build an array of 1000 elements which you wire to the input (f) of the formula node.

Your problem lies there, that the formula node requires a single value instead of the array. When using LV6.1 I get a strange error report ("Left brace required"???), in LV7.1 the error reports the real problem. Didier

As long as the separate vi's run in the same development env you can use queues/notifiers to communicate. use a separate queue for each separate vi (don't forget to give each queue a name, otherwise you end up with one single queue). Either just read from the GPIB and put the results on the according queue or wait that the separate vi asks for data, read from GPIB and send it. You will have to set up the priority by coding accordingly. Also have a look to the examples with serach-key "client-server", "queue",... Didier

On thing is quite interesting for me as ingeneer: With these $3.3 million on NI side (and probably a similar ammount on Softwire's side), how many ingeneers could have been employed and with these additional forces how many of our whishes whould have been implemented??? ...but time to wake up, real world is different!

:beer: Congratulation :beer: , and if it's your first baby, welcome to the club! ... It's quite a good feeling be dad, isn't it ???

Tell me if I'm wrong, but do you try to wire an output of the node directly to an input? If yes, then it won't work. This breakes the dataflow paradigm, If no, jump over this section: A operation in LV is only performed when all its inputs got a value (turn on debug mode, with bulb in the icon-bar, this is true when on every single input of your node a wandering dot reached it. When you try to wire an output to an input of the same operation/node/vi, then it won't ever work, because the output can only be set when your node has run, but to run your node all inputs have to be set (like when a dog chases his own tail). Customizing controls is quite something painful (I suppose you know how to do it). If you own the Datalogging and Supervisory toolbox, then you have quite a lot of items (pumps, valves,...). Alternatively you can put a background picture (drawn with your favourite paint program) to your frontpanel. To add a (static) picture to your frontpanel select in the menu Edit>>Import Picture from File..., choose your picture (gif, jpg, png, bmp), go to the frontpanel and make a paste (<Ctrl>+<V> or menu Edit>>Paste). Didier

That is what I usually see. The effect I described yesterday is something new, never seen before. But I was in a hurry (was in a meeting), so I did not a print-screen .

An uninstall/reinstall do not resolve the problem. Due to other problems (with my computer) I had to reinstall LV 2! times and still get this odd behaviour. One was a clean install from a freshly installed Win. My computer is shut down every evening. An undo/redo also solves the problem. Last recent (yesterday) behaviour: I wired a Unbundle By Name and got a relatively long element. I changed to a shorter one and... bingo... the handles stayed where they originally were... and the Unbundle was unusable. Didier p.s. Since I have no SSP, Ed please feel free to forward it to NI, Thanks.

Did you do it? If yes, have you a modified lvapp.lib or how did you made it? I know Microangelo, where one can retreive/modify the icon's in any executable. But unfortunately after modifing something the executable is broken. Didier

Merlin, Did you try the picture ring for your purposes? There you embed the images directly into the control (at design-time) and select the desired picture by index at runtime. It is located in the Ring & Enum palette. Select Image by Image from Menu>>Import Picture from File and then with RMB on the control select Import Picture on the desired ring item. Didier

I have seen the "ASRL" name on com-ports usually when I installed a computer (or at least additional com-ports) and haven't yet run MAX at least once. After running MAX the com-ports shows as COMx.

But how do you then react on a button-press without having to decode the position for each control (on your panel that is then behind the picture control) and manually react on the mouse press (then again you are without the event-structure)?

Has anyone a solution to get the mouse position when over a vi that works: 1. on LV6.1 2. on all platforms (no win-API) Didier

As it seems, when you get the data from your source, you get an array with one valid value (78) and the rest 0's. Extract the valid value of your array (If you are lucky it's on first or last index of your 1D-array) and wire just this sole value to the chart. To find where the value is in you array run your acquisition just once and wire it to your chart. The index is the x-value of your chart. Then put in your loop an Index Array from the array palette to extract the valid value. Didier

I also noticed it. Till now I always resolved it with an undo. Didier

how cute, just 1.42cm! Anyway, for all who become in some near future or are not yet daddy, It's a great feeling to see your baby move in the ultrasound, feel it move in the abdomen... and the birth itself... WOW! Afterwards everything goes so fast! Yesterday I went buying some clothes for my girl. I glanced at the clothes for newborn babies and got some sort of shock , seing that she was once (and not so long ago) so small. :beer: Good luck :beer: Didier

There is an other way of programming it, avoiding the "before LV6" programming style. Especially when one already use the event structure. This makes "mixed-mode" code. In the Info-LabVIEW there was an other solution with mouse-up and value change. Unfortunately this won't work, when the mouse is moved avay of the knob while pressed. Here is my solution: 1. use the mouse-down of the knob to set a flag. 2. in the mouse-up of the vi read the flag and if it is set, read the knob value. Download File:post-253-1108621995.vi (LV6.1) Didier