didierj

Yes, I store the ref in a global. In the example code, I do close that ref when the user exits.

With regards to the references to the controls accessed via property nodes, since these 'references' were never opened, there is no need to 'close' them. They exist in memory as long as the VI that they belong to exists. They are really just pointers or 'sub-references' of the VI and not independant instances of the control in question.

A good experiment would be to open several instances to a single VI, then close them one at a time and test your references after each close to see if they are still valid. You should see that the references not closed are still valid, since the VI is still in memory until the last reference to it is closed.

Now, open a single reference to a VI and then access the references to the controls on that VI's front panel. Test each of these control references to see if they are vaild. Now, close the reference to the VI and re-test the control references, you should see that they are now invalid, since the VI is no longer in memory, even though you never 'closed' the references to the controls.

A reference to a VI adds 1 to the # of callers list and causes it to stay in memory as long as the callers list is >1. This is the same way Windows works with DLLs.

A reference to a control is neither opened or closed and is just a 'far pointer' to a data/display element of a VI in memory.

I hope that clears things up a bit. See the attached VI as a demonstration of this.

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.

A well written VI in 3-d would be an absolute must!

Imagine trying to debug code that looks like this but with wires everywhere. Yeeeeaache.

...NO, I won't

...NO, I can't

...Where's my mommy!!!

In France the students are very well organized; but the boots and fists of police and secret police services are stronger then the head of a Sorbona

Hmmm.... If I close the only open reference to the VI, won't it be unloaded from memory? :question:

Besides that, by only opening the reference on 'first call' and then storing it in a global (which is used on subsequent calls), there never should be more than one open reference, right?

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.

I tried to rebuild it for a LV 5.1.1 application on the same machine. Error list shows up

I would be glad to see, if there were a possibility to add a copyright information to the Block Diagramm, which can only be removed with a password. It could look like e.g. the "Demo Version Branding".

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

...and (drumroll please) it's written completely in LabVIEW! :worship:

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

I still have yet to see them integrated into a funny marketing video internally - which is pretty hard to believe. I guess maybe I will have to step up to the plate.

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

... cool... :thumbup:

I'd like to read presentations "Five Techniques for Better LabVIEW Code" and "Applying UML to TestStand and LabVIEW" from http://www.bloomy.com/resources/ but links are dead.

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

Co.. ....rfa... but ..r..l invi...... to fi...rpr..ts on t.. d....ay......n!

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!

Everything works. However, I'm surprised because OpenGOOP creates each class in one ".llb" file.

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.

It makes me wonder if I can seek OS language setting information through Labview and display a pop-up window to remind our cusomter to change their language setting if it is not English before they launch our GUI software.

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

...USB 2.0 Brain Plug

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

Interesting, I for one have never understood why we cannot have our PCs start up in 2 seconds.

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

Something must be screwed up with my LV 7.0 because I have a nice big std round Green LED button with decal (which is easy to show/hide by popup) and no effect when I click on it. I haven't had my 15 cup of coffee today, so I'm a little slow. Did clickable decals come in 7.1+ ?

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

Lets hear what some basic spec's are on the pc's your able to run that don't encounter this error!

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

I never had to enjoy the benefit of no undo

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

Jim's gone over 500 posts and has been promoted from "Extremely Active" to "<customize this text>" - congratulations Jim!

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