Determining source of a button press from a combined Device
Jeff
Posts: 374
OK, So I'm about to ask a question that has a really easy answer and a really hard answer. I already know the easy answer and am hoping the hard one exists.
I'm working on a system with a few other programmers. They create tons of virtual devices and combine their touchpanels with these virtual devices. So for example, dvTP1, dvTP2, dvTP3, and dvTP4 are all combined to the virtual device vdvTP. This means that when I do button.input.device on a vdvTP button event, all I get is 33001, never 10001 or 10002, etc.
The easy solution is to use device arrays. However, for reasons that aren't worth getting into, I've lost that fight, and we'll be using these virtual device combines. Is there any way to get the individual device from this situation? button.sourcedev appears to only generate 0:1:0, because the Master is actually generating the button push.
I suspect the answer is no, you can't do this, but I thought I'd present it to the masses for review first.
J
I'm working on a system with a few other programmers. They create tons of virtual devices and combine their touchpanels with these virtual devices. So for example, dvTP1, dvTP2, dvTP3, and dvTP4 are all combined to the virtual device vdvTP. This means that when I do button.input.device on a vdvTP button event, all I get is 33001, never 10001 or 10002, etc.
The easy solution is to use device arrays. However, for reasons that aren't worth getting into, I've lost that fight, and we'll be using these virtual device combines. Is there any way to get the individual device from this situation? button.sourcedev appears to only generate 0:1:0, because the Master is actually generating the button push.
I suspect the answer is no, you can't do this, but I thought I'd present it to the masses for review first.
J
0
Comments
Anyway, hopefully you get your answer, but may I suggest that you give device arrays another go? If you need help with setting them up or anything, by all means ask questions, either publicly or privately. We're here to help.
Nope.
BUTTON_EVENT[dPanelArray,0] { PUSH: { nThePanelItCameFrom=GET_LAST(dPanelArray) //Integer value telling you which sequential panel made the event TO [BUTTON.INPUT] //Feedback of the button press on one panel TO [dPanelArray,BUTTON.INPUT.CHANNEL] //Feedback to all the panels on the push from any panel } }Stop hard combining panels. You're pissing up a rope.
Are these other programmers from a retirement home?
The only exception is DATA_EVENT[].. ONLINE and OFFLINE, which can be get for each device in the combine list individually.
I agree with mpullin...
Why do they hand you a fixed deck, and then ask you to win? The programmer must be able to use all the tools in his arsenal and push past insanity.
So I guess the answer is "no", but I'd fight them to the death on this one.
There are others??
and they don't use the forums??
~ um.. what I meant to say is...~
I say put those programmers on the forum and let us talk to them.
We all fuss and argue of the minutia of programming choice and flavor, but using Combine_devices is clearly way outside that circle. It is clearly a poor choice on almost any count.
Here's the whole deal. I work for a company with several programmers. The powers that be have decided that having us all work from a standard is beneficial because then when programmers leave, other programmers can pick up where they left off. Also, this is helpful from a device module standpoint. We have our own module standard, and any programmer can pick up any module that we wrote and put it into a program with little to no trouble. Its legitimately is convenient, and much faster than programming the way I've had to do some other places. OTOH, it means we all have to agree on a programming style, which is beginning to drive me crazy.
Both of the other programmers I'm working with don't like doing button feedback in define program or a timeline (i.e., [dvTP,1]=myVariable). They'd rather do it all manually, (i.e., in the projector string handler put on[dvTP,1] when the projector power turns on). You can do all of this manually, and it does make stepping through code while debugging much nicer, but it means that if a panel drops offline, that its feedback is all wacky. Of course, you could update all of the feedback in the online event, but thats deemed too much work (and I agree, it is).
The way they've made this work is to do device combines. combine_devices (vdvTP, dvTP1, dvTP2, dvTP3, dvTP4), etc. This means that if any of the touchpanels drop offline, when they come back, their status updates. This only works for buttons, as far as I can tell, not variable text.
I'm coming in here as the new guy, the other two programmers have been doing this for ages. They're willing to talk to me about changes, but they both appear to not be interested in changing their programming style to avoid this problem. I personally just put the device feedback in a timeline or a function, and that means its only one line to comment out when its time to debug, and its pretty simple. I don't see myself winning this fight.
We've got another meeting coming up to discuss potential changes to the standard, and I have a few ideas, but I'm going nuts here. They've literally made it so that you can't pop a keyboard up on an individual panel as a response to something that panel did without popping it up on all panels. They've talked about making some bandaids to find me a workaround so that I can do that, but I really feel like I'm trying to fight the symptoms when I really know what the problem is in the first place and they won't let me fix it.
So yea, thats where I am, and why I've lost the battle against device combines.
On another note, I"ve only done some VERY basic testing on this, so it could be something simple or I could be doing it wrong, but I'm having trouble with VarText sent to device arrays. if vdvTP is combined with dvTP1, dvTP2, dvTP3, and dvTP4, and I send varText to vdvTP, it shows up on all of the touchpanels. if vdvTP is a device array of those same 4 touchpanels, and I send varText to it, it doesn't show up on them all. Any idea why this is? I'm going to have a hard time convincing them to switch to device arrays if we lose this kind of functionality.
J
If you have an array
DEV dvTPs[] = {dvTP1,dvTP2,dvTP3,dvTP4}
Then a SEND_COMMAND sent to the array like
SEND_COMMAND dvTPs, "'^BMF-442,1&2,%Plovely.png'"
will send the same command to every panel in the array, it's a built in perk of NetLinx rewarding the use of device arrays.
Also, think of future programmers. If the objective behind agreeing on a style is to make it easier to replace programmers where the old programmers left off, you should practice style that is embraced by AMX and the NetLinx programming community. Otherwise it will be a deterrent to experienced AMX programmers who will want to join your company in the future, as why would they want to be placed in a job where they are forced to break their current style and adopt bad habits?
non_volatile dev vdvTP[]={dvTP1,dvTP2,dvTP3,dvTP4}
and I later do
send_command vdvTP,"'@TXT',1,'Bam!'"
Bam! doesn't show up on VarText 1. Or at least, the last time I tried it I don't remember it working, but then I got busy and never finished troubleshooting, so for all I know its one of two things.
1. Does the older @TXT not work with array's correctly, and I have to do ^TXT?
2. I could've just made a stupid typo
What you're telling me is that this should work if I do it right, I should be able to send text to an array and it will populate everywhere in the array, to all the panels that are online.
I'm going to give another shot at the sell on Arrays. Its frustrating . . . . I spend more time fighting this standard than I would spend doing the damn programming from scratch right now.
J
Yes, all commands work with dev arrays...
Jeff, simply show them the power of the dev arrays & the lack of power of combining devices. I'm sure you know what you can and can't do with combine devices. And if they say it's how they've done it and won't change, then I guess you're trying to get blood from a turnip. People set in the wrong way of things because it's "easier" are usually so lazy they don't want to put any extra effort into doing it right. And on top of that, they're usually set in their ways no matter what.
Just explain to them that they are indeed wrong. Plain and simple, that the way they are doing it is . . . the wrong way. I really try not to say a person is programming the "wrong" way because there are so many different ways to program, but it sounds to me like they're putting two left shoes on their feet - you can do it and get around that way, but it's just wrong.