Runtime created button arrays as parameters

ajish.rajuajish.raju chief evangelist of favantePosts: 185
I am able to create runtime-created button arrays. But not able to pass them as parameters in module like UI module.

Do I need to do the function for creating the button arrays in the module itself.

Comments

  • viningvining X Member Posts: 4,348
    ajish.raju wrote: »
    I am able to create runtime-created button arrays. But not able to pass them as parameters in module like UI module.

    Do I need to do the function for creating the button arrays in the module itself.
    If your button array isn't populated when compiled or during startup prior to the event table being built you'll need to somehow trigger a rebuild event inside the module once the array is populated or modified.
  • jdonachiue@shaw.ca[email protected] Junior Member Posts: 57
    The Integer array is passed as a reference to the module.
    I have not done this but I would think the button array is "filled in" after the events are created,
    so I would think that you would need to recreate the events at run time in the module;
    i.e. call rebuild_events(); in the Module DEFINE_START like:
    DEFINE_START
    {
    wait WT_1000_MSEC
    {
    rebuild_events();
    }
    }
  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,157
    One thing to keep in mind about rebuild events is that it doesnt just rebuild the events in the module, it rebuilds the entire program's events. This was not how it was documented when they first rolled R_E out. But after encountering really long reboots and long hang times I asked tech support who confirmed that it is rebuilding everything. So, if you happen to encounter B_E more than once in a program you'll be rebuilding everything how ever many times it encounters it.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    ajish.raju wrote: »
    I am able to create runtime-created button arrays. But not able to pass them as parameters in module like UI module.

    Netlinx isn't a dynamic system, so trying to do anything at runtime is usually not worth it. You can usually design around this limitation in most cases. I can't think of any reason I would ever need to create button arrays at runtime. Why do you feel the need to do that?
    Paul
  • ajish.rajuajish.raju chief evangelist of favante Posts: 185
    I used integer button arrays and then use get_last as to switch button events. Some use button.input.channel and list only the channel codes in the tp. Others use 0 as a catch all and then use button.input.channel. I though runtime created button array is better since I don't ve check the tp for the button used and also I don't ve to do the tedious part of writing button arrays with 255 or more integers or constants listed for devices.

    I use snapi constants for comm modules but for ui modules, is it better to use g4api constants. Since we can use 4000 channel codes per tp port, is there a standard for which device to use which channel codes.
  • jdonachiue@shaw.ca[email protected] Junior Member Posts: 57
    Thank you Eric Medley.

    I was not aware of that.
    I thought that the module is running in its own address space and therefore would requires an r_e of its own.
    I did not test this - just assumed... DOH!!!
    I will now have remove a line of code from a few modules...

    Thanks again.
  • viningvining X Member Posts: 4,348
    Also be aware that doing a R_E during runtime can take anywhere from 15-45 seconds from my experience and during that time no events will trigger, no button pushes, etc. Your UI's affectively become useless during that period so beware that when you call it any time other then a after short delay after startup that the customers will loose control. Calling it during startup you expect no control but if called for some dynamic reason during runtime the user won't be expecting it.
  • jdonachiue@shaw.ca[email protected] Junior Member Posts: 57
    Thanks vining.

    At this point in time I have not had any reason to r_e other than on reboot.
  • ajish.rajuajish.raju chief evangelist of favante Posts: 185
    DEFINE_FUNCTION fTP_BUTTON_ARRAY (INTEGER BUTT[],INTEGER BASE_BUTT)
    // used to create button_event arrays at runtime by specifying a starting channel and array size
    //
    // example usage:
    //
    // DEFINE_CONSTANT
    // btnVOL_UP = 1 // channel of first VOL_UP button
    // btnVOL_UP_MAX = 16 // 16 buttons total
    //
    // DEFINE_VARIABLE
    // volatile integer btVOL_UP[btnVOL_UP_MAX]

    // DEFINE_START
    // {
    // fnMAKE_BUTTON_ARRAY(btVOL_UP,btnVOL_UP)
    // rebuild_event()
    // }

    {
    STACK_VAR INTEGER Y
    FOR (Y=0;Y<MAX_LENGTH_ARRAY(BUTT);Y++)
    BUTT[Y+1]=BASE_BUTT+Y

    SET_LENGTH_ARRAY (BUTT,MAX_LENGTH_ARRAY(BUTT))
    }

    This is the function that i am using to create the button arrays.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    I don't know what this function accomplishes. It seems to me you are trying to overcomplicate things by using a solution for which there is no problem.

    SET_LENGTH_ARRAY (BUTT,MAX_LENGTH_ARRAY(BUTT))

    This line won't do anything. If Netlinx knew the correct max_length_array, then you wouldn't need to set it. Its like asking "Tell me the length of this array so I can set it to that value".
    Paul
  • viningvining X Member Posts: 4,348
    There's actually a difference between the lenght of an array and the max length of an array. When you defined an array with a specified length that sets the max length of the array but since it wasn't initialized with a values its working length is 0. If you then populate the array its working length will still be 0 until you actually use set length array to the size you want as long as it is less to or equal to the max length assigned when defined. Setting to the max length just means you want the working length to be the same as the defined max length.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    vining wrote: »
    When you defined an array with a specified length that sets the max length of the array but since it wasn't initialized with a values its working length is 0.

    If you declare an array with a constant, then that's its effective and maximum length. You don't need to initialize it. iBtns[cnMaxBts] has an effective and max length of cnMaxBtns.
    Paul
  • viningvining X Member Posts: 4,348
    a_riot42 wrote: »
    If you declare an array with a constant, then that's its effective and maximum length. You don't need to initialize it. iBtns[cnMaxBts] has an effective and max length of cnMaxBtns.
    Paul

    Nope, its working length is 0 and if you do a length_array on it, it will return 0. If you populate it with values and then do a rebuild_event on it nothing will happen since it has no working length.

    If you drop that var array into debug and right click the length and uncheck total length you will see a length of 0, its working length. If you check total length you will see its defined max length.

    You can use it with out a set working length if you want as long as you don't run functions on it like length_array or rebuild_event().
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    I haven't run into that issue. I initialize all arrays in either define_constant, define_variable, or define_start, so I'll take your word for it. I don't see the point of creating arrays of button numbers at runtime, so my suggestion was to avoid trying to do so. Accessing uninitialized arrays is problematic, since their contents can be undefined, so initializing them in the above locations prevents the problem from occurring since they will have a working length with valid values before the program starts. Using rebuild_event isn't a good solution as many have found, since it locks the processor up. Each to his own though, just my opinion.
    Paul
  • viningvining X Member Posts: 4,348
    a_riot42 wrote: »
    I haven't run into that issue. I initialize all arrays in either define_constant, define_variable, or define_start, so I'll take your word for it. I don't see the point of creating arrays of button numbers at runtime, so my suggestion was to avoid trying to do so. Accessing uninitialized arrays is problematic, since their contents can be undefined, so initializing them in the above locations prevents the problem from occurring since they will have a working length with valid values before the program starts. Using rebuild_event isn't a good solution as many have found, since it locks the processor up. Each to his own though, just my opinion.
    Paul

    If you initialize (populate with values) a var array anywhere other than define_variable it will not have length unless you use set_length_array somewhere. It will only have the max length that it was defined with. You can still use the array, read from or write to elements of the array but it still doesn't have a working length as returned from the length_array function.

    I agree that for most situations defining var arrays used with event handlers should be initialized when defined and quite frankly there's no real need for button arrays at all if channel numbers match index positions, for that just use 0, catch all, since it uses less resources and catches everything.
Sign In or Register to comment.