didierj

That's all right. I absolutely agree with you. :thumbup: ...but, what I tried to say is shown in the attached picture. The snapshots in the profiler were taken after 1,100,200,400 calls of your vi. I have seen applications where people wanted to run an app for long term experiments and somewhere in the middle of the night it crashed, just because of a single forgotten "close ref" and therefore the computer running out of memory.

...NO, I won't ...NO, I can't ...Where's my mommy!!!

1. If you close the only reference, then yes the vi will be unloaded. But you store the ref into a global, therefore it never unloads. 2. I didn't meant the ref to the vi you should close, but the subsequent refs. The one to the panel and the ones to all the ctrls on this panel (see picture).

Nice... I use a similar approach for execution log while debugging applications. If I'm allowed: In your "Write to Text display.vi" you should close the references (panel & controls[]), or your memory consumption might become bigger and bigger (especially if you use this tool quite often). Each call from this vi creates new instances of the references. Didier

Wow! :thumbup: How many times did I execrate NI when I made a "read-ini" based from a "write-ini" (replace all read key by write key) and the copy paste doesn't work... navigating through the palette at each wirte-key isn't handy either.

If I remember correctly there was (about one year ago?) a thread where one could put a constant or something similar onto the diagram, perform some operations and then the element couldn't be selected anymore. It stays on the block diagram unmovable. Unfortunately I don't remember how it worked and haven't found the thread yet. Edit: I have found the thread: "Hide Control" on typedef...

Is it really? I would have said that the drawing area is an activeX-control...

What a nice Intro for the next NI-Week this would make: A live band performing one of these song. ... cool... :thumbup:

Just tested it and I could get the two pps-files, without problem. One 500kB, second 1.9MB in size. If your problem persists, I could pm/mail them to you. Didier

What did you write... dang! I'll have to clean my screen...

I know the way by right clicking on the desktop, selecting "Settings", selecting tab "Screen Saver" and clicking the button "Energieverwaltung" (how was it in english :ninja: , don't remember). But this is done interactively. If you were looking for an automated method, I'm sure there must be an API-call where you can get/set this property, make a seach in MSDN... good luck!

To me it seems you are referencing to the NI/Endevo-Goop tool. This builds a neat packed llb. If the internal primitive "<something> object repository" is password protected, or you installed the tool from a file called "goop6i.exe" (or similar), then it's NI/Endeve-GOOP. To create a new openGoop class select in the menu "Tools\Make new OpenGOOP class...". You'll have to download/install it with OpenG-Commander. Didier

Thanks also from my side. I'm going to try it.

As jpdrolet indicated in his last post and to my opinion it is a bad idea to force the user to change local computer settings. It will have much more impacts, since he won't using his computer just for your app (I assume). Your coustomer will "not be amused" if he has to change such settings (by the way, maybe he might not know how to do it at all). - Let the user write/read to numeric controls (not strings) where applicable. - convert user string-inputs to values using localized decimal point. - convert values to strings for parameter save (e.g. in an ini-file) NOT using localized decimal point. - Where applicable use timestamps as "seconds since ..." Didier

...let me introduce the brand new Matrix movie: "MatiVIEW, the resurection"

Maybe because Windows works more stable (with all the installed 3rd-party stuff) when a clean boot is performed from time to time (meaning on a regular basis every morning).

Hmmm... I see two workarounds: 1. place decos over your color rams so you get the hexagon 2. simulate a color ramp with a picture control. Since it knows the mouse-down, mouse-move, mouse-leave events, you can get the mouse-position in the picture control and then draw a hexagon into the same picture. Didier

Don't think your coffee is involved, I hadn't any yet too... ...but I tried to click on the decal of a "huge" LED-button in LV7.1.1... and nothing happens: The decal seems not to be clickable.

Here are 2 little vi's I often use: I use both (red to yellow sub-vi's) to deal between development and built app (takes the work for me) - First gives back the root path by removing the the vi-name and the "\blabla.exe\" or "\blabla.llb\". It is quite ideal to load ini-files that reside in the app root directory. - Second checks if the path contains an ".exe". I usually put it at the end of the main vi: if the ".exe" is detected, it gives a true to the "quit lv"-primitive, thus quiting the built app. If not detected it doesn't quit the development environment. Didier Download File:post-253-1142926055.zip

I have a 3GHz, 512MB computer at work. As i2dx stated, it mainly depends on your HD and on the "crap" that is on the HD. When my old computer (2GHz) was new (about 1,5 years ago) I could load the vi's by double-click on explorer without getting the error. After about 1 year it suddenly appeared. Also the load time of the computer was increasing continously. At home I have a 1.2GHz Athlon and get this error seldom. If you suddenly get this error, treat it as: clean up your computer and make a >format c:<

I often saw this error with my old computer. Since I got a faster computer from my admin this error disappeared. It seem that the loading procedure of the LV-environment takes too long, so the explorer don't get sort of a "I-got-the-file-you-gave-to-me"-event fast enough and reports a timeout error to the user. It is just something annoying, never seen that it affects your vi's. Didier

Starting with LV3.?? at college and with LV4 on my first job I had this benefit. Do not remember me the screams throughout the laboratory building when someone accidentally selected too much and hit delete or when you hit delete instead of insert... several hours work gone in a fraction of a second...

...and I am still working on my "Extremely"... congratulate jim :worship: