XControl refnum probe

[jzoller]

Just for Friday fun...

As Stephen pointed out via Darren here, an XControl embedded in a custom probe is always "running", and allows exploration of the data probed after execution finishes.

If the probe is for a refnum, the XControl will keep the refnum alive even after execution finishes (as long as the probe is open). This allows modification of the data and properties in anything with a reference from within a relatively simple probe.

I could see this being useful for unit or off the cuff testing, given some development. You could even build your own custom editing menus. Does anyone else have a good use for it?

Of course, in combination with some rusty nails, some very strange results might be accomplished.

Have a good weekend all,

Joe Z.

[Aristos Queue]

QUOTE(jzoller @ Jun 22 2007, 01:40 PM)

If the probe is for a refnum, the XControl will keep the refnum alive even after execution finishes (as long as the probe is open). This allows modification of the data and properties in anything with a reference from within a relatively simple probe.

The probe would have to be the VI that *opens* the refnum. A refnum goes invalid when the VI that opened the refnum goes idle even if you pass that refnum to some other VI by some means. The other VI can be using that refnum and the number will start returning errors for invalid refnum when the original VI goes idle.

With something like the queue or notifier refnums, you might be able to look up the item's name and open a new reference to the same item. But for file refnums and similar, there's only one refnum and when it goes stale, there's no other way to get the reference.

[Rolf Kalbermatter]

QUOTE(Aristos Queue @ Jun 22 2007, 08:18 PM)

The probe would have to be the VI that *opens* the refnum. A refnum goes invalid when the VI that opened the refnum goes idle even if you pass that refnum to some other VI by some means. The other VI can be using that refnum and the number will start returning errors for invalid refnum when the original VI goes idle.

With something like the queue or notifier refnums, you might be able to look up the item's name and open a new reference to the same item. But for file refnums and similar, there's only one refnum and when it goes stale, there's no other way to get the reference.

Actually there is a primitive somewhere that returns the file name for a given file refnum. So it would be possible to find out the file name and open a new refnum to that file, provided the access and deny rights from the initial open allow for that.

Rolf Kalbermatter