Integer Array
ibryant
Posts: 13
I am trying to track source selections in specific zones
using integers for each zone and storing the analog value of the source
I am trying to group the integers together into an array and store the info like:
DEFINE VARIABLE
SOURCE_BTN = {1,2,3,4,5}
INTEGER nZONE1_SRC
INTEGER nZONE2_SRC
INTEGERnZONE3_SRC
VOLATILE DEV dvTP[]= {dvTP_1, dvTP_2, dvTP_3}
???nZONE_SRC_ARRAY???
DEFINE EVENT
BUTTON_EVENT[dvTP,SOURCE_BTN]
{
PUSH:
{
STACK_VAR nTEMP_TP
nTEMP_TP = GET_LAST(dvTP)
nZONE_SRC_ARRAY[nTEMP_TP] = GET_LAST(SOURCE_BTN)
}
}
THEN LATER I CAN REFERENCE
IF (nZONE1_SRC = 1) DO WHATEVER
my problem is im not sure how to define the integer array up in code.
how do i group the zone integers into the zone array?
maybe i cannot do this, just looking for some guidance
Thanks,
Ian
using integers for each zone and storing the analog value of the source
I am trying to group the integers together into an array and store the info like:
DEFINE VARIABLE
SOURCE_BTN = {1,2,3,4,5}
INTEGER nZONE1_SRC
INTEGER nZONE2_SRC
INTEGERnZONE3_SRC
VOLATILE DEV dvTP[]= {dvTP_1, dvTP_2, dvTP_3}
???nZONE_SRC_ARRAY???
DEFINE EVENT
BUTTON_EVENT[dvTP,SOURCE_BTN]
{
PUSH:
{
STACK_VAR nTEMP_TP
nTEMP_TP = GET_LAST(dvTP)
nZONE_SRC_ARRAY[nTEMP_TP] = GET_LAST(SOURCE_BTN)
}
}
THEN LATER I CAN REFERENCE
IF (nZONE1_SRC = 1) DO WHATEVER
my problem is im not sure how to define the integer array up in code.
how do i group the zone integers into the zone array?
maybe i cannot do this, just looking for some guidance
Thanks,
Ian
0
Comments
one little thing. This should be
volatile integer SOURCE_BTN[5]= {1,2,3,4,5}
or you can actually leave the 5 out as the complier will fill it for you
volatile integer SOURCE_BTN[]= {1,2,3,4,5}
That way if you add or change numbers you won't blow your code.
now on this you'd treat it the same way.
volatile integer nZONE_SRC_ARRAY[<HOW EVER MANY ZONES>]
So, for example 16 zones would be
volatile integer nZONE_SRC_ARRAY[16]
In the example to see the state/source of zone 3 you'd look at nZONE_SRC_ARRAY[3]
You'd need to poll or collect the status of the zoned thing ini something like a data_event. That's where you'd populate the nZONE_SRC_ARRAY[whichever zone] value.
thanks!!
Let's say you've got 16 zones, make a nMAX_ZONE constant to equal 16. This way, in the future you can copy code much easier, and just change the nMAX_ZONE constant to 8, or 24, or 33 or whatever in just one spot rather than trying to go through a bunch of code and wondering why you're having some issues.
I do this with the maximum number of panels, zones, keypads, receivers, plasmas, cable boxes, vcrs, DVDs, BluRays - you name it. That way - the "To" values for my loops and sizes of variables are already set. It helps make code more transportable.
In short - define a nMAX_ZONE constant of however many zones you have, then when you define your nZONE_SRC_ARRAY, do [nMAX_ZONE] instead of [16] (or however many there are) and you can just start copying and pasting in the future.
Just to nitpick because variable naming is a pet peeve of mine, it really should be nNUM_ZONES. My feeling is the term MAX should be used for actual maximums not totals. For instance, if the volume for a device goes to 11, then nMAX_VOL = 11 would be appropriate. However, if you have 9 touch panels, then it should be nNUM_TPs, not nMAX_TPs, which implies that there is some maximum amount of TPs that can be used in the project.
I generally don't have an array that contains the zone/src because I have an array that tells me what source a UI is controlling, and an array that tells me what zone that UI is in. It makes more sense to me to view everything from the perspective of a UI.
Paul
I would differ on this point. I tend to make the device the arbitor of reality. To me there's nothing more frustrating and embarrasing than having the touch panel say the source selection is cable but the display is showing DVD.
I create a trakcing variable that stores the current status of device. I do go ahead and change the tracking variable to what I suspect will be the new value right away. But if the change doesn't take place, then it will get set back.
Perhaps the number of my panels should be nNumPanels, keypads be nNumKeypads, so on and so forth. But as far as zones go, I would think that the maximum number of zones is defined by the number of speakers (or outputs rather) of the audio switching device, which is where I get my maximum number of zones. If I'm dealing with an 18x18 audio switcher, my maximum number of zones are 18; unless of course I have several receivers throughout the house that are not part of the switcher, then of course the number goes up.
Again, I kind of agree - but it's all nomenclature. Toe-may-toe vs. toe-mah-toe - it's still a red fruit / vegetable / berry. nMaxZones vs. nNumZones - still the amount of zones you want defined in code.
I understand that theory, but from a control and user perspective, I am less concerned with what the gear is doing, and more concerned as to what the user wants the gear to do and base everything on that. It makes more sense to me to follow what the user wants and make the gear do that than to track what the gear is doing and make the UI follow that. My last employer did things the way you are, and I understand why, since the UI reflects the state of the equipment but I much prefer to do things from a user perspective.
If the touch panel says the source selection is cable but the display is showing DVD, then I know I have a bug controlling the display. If the user chose cable, but both the UI and display show the DVD as in your scenario, you don't know where the bug is because now it could be a problem switching the display, a UI bug etc.
Paul