Remote window with scrolling text

[John Lokanis]

This set of VIs demonstrates how to setup an independant VI that displays text sent from anywhere in you application and also appends the text to the bottom of the window and autoscrolls up.

I used VI server to implement the independant display VI and control it. You could adapt this code easily to direct the data to a FP display on another VI by passing it's reference around. You would still need to implement a parallel loop in you VI with the display to handle the scrolling of the indicator.

I hope this is useful to some of you.

-John

Download File:post-2411-1144691172.zip

[didierj]

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

[John Lokanis]

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

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?

-John

[didierj]

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

[John Lokanis]

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

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.

-John

Download File:post-2411-1145311174.vi

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

[Rolf Kalbermatter]

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.

It all depends on LabVIEW versions too. Before 7.0 (or 7.1 I'm not exactly sure at the moment) it was imperative to close all references always no matter how you got them. Since then you need to close explicitedly opened references only but as a matter of good style closing all references anyhow properly is always a good idea. LabVIEW will know about those that don't need to be closed explicitedly and just execute a NOP instead of the close operation. This saves you the headache of remembering (or experimenting) what needs to be closed and what not.

Rolf Kalbermatter

[didierj]

Before 7.0 (or 7.1 I'm not exactly sure at the moment) it was imperative...

It must be 7.1, since it's the version I used to make the test.

[Rolf Kalbermatter]

It must be 7.1, since it's the version I used to make the test.

I said BEFORE :laugh: and I verified it's before 7.0.

So what you were experiencing is probably anothere issue. You can check the issue by typecasting the refnums into int32. If the value of a refnum changes between repetitive executes of the VI then it is a refnum that needs to be closed explicitedly in order to avoid memory leaks during execution of the VI. Note that LabVIEW does dispose of refnums anyhow as soon as the top level VI goes idle so if you are not creating refnums over and over again in a loop you are not exactly in deep shit, it's just not a nice and welbehaved application.

Rolf Kalbermatter