didierj

Then I usually must do something wrong. My diagrams tend to go to (rarely over) the limits of 1280x1024, usually only on one dimension (e.g. when I read from an ini-file or doing instrument reading/writing). In production we also have older computers with 17" tube monitors. But all can in any way (worst 60Hz) display 1280x1024. Older computer have only DOS. The FP I keep to less than 1024x768. Didier

See this topic: labview and VisualC++6 --> do not break your path into root and file, but just feed the whole to the command line input. Dunno why, but should work better. Didier

There is a topic on how to create an arbitrary text-ring in the NI knowledge base. Unfortunately one would need CVI. There is no other way to have it directly in LV6.1. They appeared in LV7 Here the link: Arbitrary text-ring Didier

For everyone who don't know the song already, here is the official site: Schnappi Site

I don't think so. My baby is not 4 month old and a song that is no 1 all over europe is her favourite and could run all day long: "Schnappi, das kleine Krokodil" (all german speaking people know it). A work mate told me once, he bought his children quite early a walkman. Not to coddle the children, but just for selfprotection!

I enable/disable blinking of a listbox via property node. This should let the selected item(s) in the listbox blink. When I run the vi floating, it's working fine, but when I have it as a subpanel the listbox doesn't blink. Is this behaviour normal and a limitation of the subpanel? Didier

Combine the two methods: 1. create a template (see picture) the same way you would do with a normal vi. Vi and templates are same, except of the tailing "t" in the file extension. In the explorer (for Windoze) one can convert from one type to the other by removing/adding the "t". 2. Call this template with the "call by reference node". LV creates a vi-instance of this template, and you are not limited to one instance. Didier

From the moment you want to scroll through your graph, change scaling,... you end up to have to extract the needed portion of your data and always updating your graph/chart. At my workplace we use such a program. It is quite slow and even gets slower after a few hours running (acquiring about 5 samples per seconds over serial!), or when displaying lot of data and scrolling through your graph. When you scroll through the graph you'll have first to read the new position of the graph (beginning and end time), find the array indexes of these times in your data, extract this portion of data, redraw your graph. When scrolling with the "hand"-tool (pick-and-move), either your graph updates ever 2 seconds or your data acquisition (when done with serial or similar) hangs. I recommend to use the chart and set the chart history length to a value that probably won't ever be reached. For actual computer with 256MB and more memory this is not a problem. Chart updates are done much more efficient when LV handles it internally than when written in LV. Didier

Seems you are in the same boat as me . This programming technique is traditionally called "C code programmed with LabVIEW" - we have several programs in our company written this way... how funny to debug them Your Idea is good, but I suspect that replacing the global variable (in the code) with a property node would be helpful. You better replace the global with LV2-global. But this would be only the first step. You still don't know when and where a variable is read/modified. Sooner or later it would be easier to look at what the program ought to do and then rewrite the whole bunch by scratch! You could also begin by replacing module by module with e.g. openGoop or so. Didier

Cooooooool :worship: :thumbup: For sure we should. This would mean that we first should define exactly what the menu should be able to do, on which implementation we base (or if we begin again from scratch),... Should we switch to personal messages to avoid getting an endless thread? Also my oppinion! These are details, I chose "my" look to follow the standard of NI's controls&indicators. Overlapping aso. are details easily changable. What I made is the basic implementation. Build a few vi's around the different parts and you end with 2-3 vi's. Greate Idea :thumbup: !

Do your two booleans are (in the written code) handled by the event structure? If so and the two booleans are "latch" booleans, then they have to reside IN the corresponding event cases. Although an event structure handles the event of controls, it does NOT read the control. This means for booleans with latch they never get read if you don't have them (the control terminal not a ref/local variable/property node) in the structure. Your event is handled only once. Hope this helps... Didier

Congratulation Heiko, :thumbup: You outraced me by 2 days. I still want to present my solution here, so the time I used isn't totally wasted . My approach isn't quite the same as yours. It's based on what I did prior. To Michaels and Jims delightment its based on OpenGoop. - It still works like (MS) pulldown-menus with mouse AND key navigation (up/down/left/right arrow/ESC/Enter). - The nested elements are indicated with a ">" sign. Do not insert a blank before, otherwise it isn't recognized. - Separator lines are marked as "<Separator>" and can have also n ">" signs before. The separator lenght adapt to the longest text length in a menu. - Unfortunately you'll have to assign/hanlde a menu for each control. Try the Demo and right click on the string control. Didier Download File:post-253-1105008908.zip

Before you make any transmission read out the buffer. For this go to the palette Instrument I/O>Serial use the VISA Bytes at Serial Port and wire it to the byte count input of the VISA read. Didier

Do you mean that when you define different font sizes, on the target computer the execuable has just one size? If so, I assume you are using Windows NT4. I have the same problem in our facility and I have no solution to that. Didier

If you want to "clone" frontpanel vi's, then you'll have to first make a template vi (not reentrant) and then call it with vi-server. Alternatively use the Open VI Clone Reference.vi from OpenG. Didier

Use an indicator, set the text right justified (see picture), resize the text to the desired length and width and place it on the right side of your panel. Hope it is what you searched for? ...Or do you mean a page on the printer? Didier

Is the current EULA with the passus LabVIEW Software License Agreement not something that should protect NI from such developments?

In this point I agree with you. being the sole player somewhere hasn't ever be profitable in the technical point of view. But as you should have seen if you read this topic, is that LV also has quite a few problems regarding patents.

Yes, I was thinking of making a version that allows nested menus. Yet I didn't made up on the format the "data" would have to be. What do you think? Would a string array, where nested elements are built like paths (with backslash separating the levels), be enough? ...about the OpenGoop, I know and use it well, but somehow on general tools I prefer to use this way. It is an implementation way I use since quite a while (longer than I know OpenGoop). Infrequently (but it happens) I get problems of overriding and such stuff, when I use Goop, OpenGoop, and LV-made VI's and port it to other computers. I prefer to have the whole stuff packed in 1 .llb. Didier BTW: How I have implemented it is the way how GOOP (from Endevo, distributed by NI) is built. The LV5.x version of GOOP wasn't password protected and so I found about the internals. Unfortunately I don't have this version in my archives anymore.

Have a separate app (I name it "helper" app) that looks in regular intervals at this location. If the creation date of the exe (acquisition-app) is newer than the one is running, then this means that a new version exists. This "helper" app can be run from windows with the scheduler - check in the system settings, there is a tool to add a task (haven't got the english name since my computer runs german). If all your apps (the one that checks and the one that acquires data) are written in LV, then the "helper" app could access the other one with VI-server, set there e.g. a global variable to stop the acquisition-app (having so a controlled termination, not just a task kill). Then your "helper" app copies the exe and restarts the acquisition-app. I haven't got an example ready, but it's on my to-do list for our facility programs we wrote and use. Didier

I would even say if they already made the way to the EULA then NI's toolkits (or at least some of them) are already nuts and are not worth the money. The second programming language I use, Delphi, comes with 2! filled CD's with companion products and toolkits from their community. Quite a few of them are direct competitors to the tools you get when you make a standard installation. What I mean with this is, Borland doesn't need to repress their community. They are even happy when someone brings a tool that is better than what they did (e.g. Rave reports, Indy-DB,... included in the standard package). For me it seems that NI wants to be the sole player for Graphical programming. They would better focus back to their roots and look, IMHO, that LV finally reaches the level other languages holds (e.g. UI, programming techniques, project management). Around the world are so many people who are willing to help NI by wiring nice tools and "helpers". If these clauses keeps in the EULA NI is going to destroy his own supporters. Didier

I took Michael's example onto the drawing-board and "enhanced" it a bit. To my feeling the pull-down menu now works quite like Windows ones (sorry, don't know if it works like mac/linux ones). Main features: - no (yet) hierarchy - put "<Separator>" to produce a horizontal line, that divides the pull-down into visual sections - change the selected element also with the keyboard (up-/down-key). - width set to largest text - Saved in LV7.0 use the "Demo" to see how it works. Download File:post-253-1103190660.llb

No LabWindows can't! There is no other legal method to build executables (some hack are known, search the LV resources spread over the net, but not usable/legal when you want to sell your app). The only legal method to run VI's on an other computer without app-builder, would be to install a full LV on each computer - but this would mean that you'll have to buy a development license for each installation. Didier

:thumbup: :thumbup: :thumbup: Really good point of view! That is also my oppinion: 1. Think 2. Read 3. Ask There are soooo many good books about LV-programming around the world, and the online help IS helpful (not like many Windoze-helps... sorry Bill). Didier BTW, when I begun the actual job I had to learn Delphi. Even with countless crashes and 3! OS-reinstalls I still think it is a great language (LV is great toooo ).

Yes I am sure it's not pressed nor stuck (<ctrl>+<e> works like it should). On my keyboard (swiss german layout) The '#' is written by pressing <AltGr>+<3>. I don't know if this makes the difference?? But, You're right... if I switch to standard-layout (english), then it works. Maybe I should report it as a bug!