Passing devices as variables

Tryll

Can I place previously defined devices into more temporary variables?

DEFINE_DEVICE

dv = 5001:9:0
dv2 = 5001:10:0

DEFINE_VARIABLE

DEV tempdv

DEFINE_EVENT

BUTTON_EVENT[TP,1]
{
PUSH:
{
tempdv = dv
Call 'doThing' (tempdv)
}
}

While this isn't what I'm doing, it reflects the same concepts. Can I push a device into a temporary variable and then act on it as though it is the original device? If so, what type of variable would tempdv above be defined as? Using DEV doesn't colorize in studio, so I'm figuring something is wrong.

KennyProgram

Tryll wrote:

Can I push a device into a temporary variable and then act on it as though it is the original device?.

Yes you can...

Tryll wrote:

If so, what type of variable would tempdv above be defined as? Using DEV doesn't colorize in studio, so I'm figuring something is wrong.

Nothing wrong, DEV is correct.

I guess my question is...Why not just pass the real device?

Tryll

Thanks for confirming.

The actual code is quite a bit more involved, obviously. The issue is that I need to retain the selected device for later use, and it seemed like a good and logical way to hold it around. This way, the rest of my code is only concerned with talking to the temporary device, and doesn't need logic to determine which device it should be talking to.

The project compiles OK, but since the keywork DEV was not colorizing, it had me wondering.

KennyProgram

interesting use...but fair enough!

mpullin

Yes.

Tryll wrote:

Can I place previously defined devices into more temporary variables?

I have done this before in my code, it works swell.

BUTTON_EVENT[TouchPanels,TP_BTNS_Tivo_Page]{ // Tivo Controls Page
    PUSH:{
	STACK_VAR DEV TivoX
	TivoX = Tivos[SESSION[GET_LAST(TouchPanels)].Tivo]
	switch(BUTTON.INPUT.CHANNEL){
	    case 5: // info
		PULSE[TivoX,52]
	    case 32: // exit
		PULSE[TivoX,51]
... etc

After all, all a DEV is is a representation of a Device, Port, and System, e.g. dv_TIVO1 = 5001:9:0 You can even write functions that take DEVs as parameters if you wish (although I haven't tried writing functions that return DEVS -- but I can't think of a situation that would require that)

Tryll

Yes, exactly the same general concept I'm using. My code is a bit more rudimentary, since I haven't yet discovered all the efficiencies in netlinx that I know some of you guys use. I'm relying more on adapting techniques I use in other languages, rather than whatever it is that works great in netlinx.

This sort of technique is more like storing a reference to an instance or object which is done all the time in OOP languages, of course. I know it probably isn't the best way, but it is helping me solve some issues, so it's a good one for today!

DHawthorne

I do that kind of thing all the time. For example, I have a generic IR handler, that mostly just sends out IR pulse for devices as needed. But every now and then, you have one device doing two purposes ... for example, a VCR used as a tuner. If you want your code to distinguish between it being used as a VCR or just for the tuner, you can create a virtual for one or both uses, then your command handler can send IR from the same port by assigning the real device to a variable based on a lookup table. Or, if the real device is RS-232, you can trap that out as well, without changing any of the main code framework that essentially says "PLAY device <whatever>." The handler looks it up and does what is needed.