DEVCHAN array action not passing to array members

mGaughan

I saw in an old post that turning on a devchan array would turn on all elements of the array. This seems to work when the array is initialized in the DEFINE_VARIABLE section, but not when I define the array elements in the DEFINE_START section (which I need to do):

DEFINE_VARIABLE
devchan dcTest[2]

DEFINE_START
dcTest[1]   = {tpButtons,201}
dcTest[2]   = {tpButtons,202}

DEFINE_EVENT
channel_event[vdvTest,1]
{
    on: on[dcTest]
    off: off[dcTest]
}

channel_event[vdvTest,2]
{
    on: on[dcTest[1]]
    off: off[dcTest[1]]
}

channel_event[vdvTest,3]
{
    on: on[dcTest[2]]
    off: off[dcTest[2]]
}

In this test vdvTest channels 2 & 3 turn on and off tpButtons 201 & 202, but channel 1 does not turn both on or off. Am I missing something?

KielL

Hi mGaughan, I think you may just need to issue a REBUILD_EVENT() after you set the devchans in DEFINE_START. Here's from the help file:

The NetLinx runtime supports the run-time library function REBUILD_EVENT(), which rebuilds the NetLinx event table for level, channel, button, timeline, and data events. Modifications to variables used in event declarations affect NetLinx event handling when REBUILD_EVENT() is called after the variables are modified.

• REBUILD_EVENT() works on a module-by-module basis (i.e. calling the function in one module does not affect the event table of another module).

• REBUILD_EVENT() rebuilds the event table for variables modified in the same block of code in which it resides.
  *** With no braces, a REBUILD_EVENT() in DEFINE_START rebuilds event tables that use any variable modified in DEFINE_START, above the REBUILD_EVENT() statement.**

• You can reduce the scope of the REBUILD_EVENT() by delineating a block with braces as shown at the bottom of the following example:

HARMAN_icraigie

The array dcTest[2] is empty when the event tables are built - happens before DEFINE_START is processed. Review REBUILD_EVENT() and call after the array elements are populated in DEFINE_START.

... Edit - That would fix the problem of channel_event[dcTest]. It may fix your on[dcTest} as well - personally I hate devchans and avoid them as much as possible.

mGaughan

Ah, yes, that's it! I haven't run across that one yet. Thank you for the quick answer!

A few more questions on this implementation:
1) If I have a devchan array with 4 elements and need to remove one what would be the proper (simple) way to do that? If not, is there a way to clear all contents so I can reload the array?

2) Am I correct in saying that to limit REBUILD_EVENT() if I were to { remove element then REBUILD_EVENT() } (in braces) this would update only that array?

3) I haven't done a lot of testing with it, but when I tried to use LENGTH_ARRAY with a devchan array it did not work. Can I test how many elements are currently in a devchan? The use is scanning a list of buttons which are tied to mute channels. Each buttons that matches the mute channel is added to the devchan array so that when the mute state changes that state is pushed to the devchan which will update all relevant buttons. When filling the devchan array I wanted to add the matched channel to dcMuteLink[LENGTH_ARRAY(dcMuteLink) + 1]. Right now I'm just using another index variable to keep track.

Thank again for the help!

mGaughan

Well, I celebrated a little too early. My actual use of this devchan is in a multi-dimensional array, but is not working. I took the above test code and added REBUILD_EVENT() at the end of DEFINE_START. That did work for the channel 1 event. When I change the definition of dcTest[2] to dcTest[2][2] then sending ON[dcTest[1] ] does not push through to the elements. Though ON[dcTest[1][1]] and ON[dcTest[1][2] does work.

HARMAN_icraigie

Try max_length_array() - a variable array that is not initialized has an implicit length of 0. Review the keyword help about length_array() for more detail

mGaughan

I found this other thread that has a good explanation of the length functions: https://proforums.harman.com/amx/discussion/comment/125030#Comment_125030

That helped clarify. Thanks.