Home AMX User Forum AMX Control Products

Limit ^BMF command to certain pages

Hi,

Suppose I have button with address 1 on two different pages, and I want to hide it via code on one page only. The ^BMF command (and other button commands) address all of the instances of address 1 equally.

Has anybody found a creative workaround to this? I'm hoping to avoid otherwise identical buttons with different address codes.

Thanks,
David

Comments

  • John NagyJohn Nagy Posts: 1,742
    I think your only alternative doesn't help much... COVER the one with some other button you turn on and off. You still burn a new address.
  • jjamesjjames Posts: 2,908
    Easy: use ^SHO; only one page can be displayed at a time on a panel, right?
  • ericmedleyericmedley Posts: 4,177
    Why not just pick another button number and have them both do the same thing? Then you can easily hide/disable, make one do something different, whatever? You've got up to 4000 buttons per port.
  • DHawthorneDHawthorne Posts: 4,584
    It's maligned as much as Basic's GOTO, but in cases like that I use the DO_PUSH() function and give them different addresses, unless it makes more sense for both to trigger a function of their own.
  • dnahmandnahman Posts: 28
    Thanks for the suggestions. Currently I just burn another channel number, and have multiple channel numbers perform the same action (for sanity sake I never assign just a address number to a button w/o a matching channel number). I was hoping for something elegant and compact.

    Thanks,
    david
  • You can use the same channel, and only assign an address code to the button you want to hide. The command gets sent to the address code, irrespective of the channel.
  • mpullinmpullin Posts: 949
    If you really want to do this (which could probably be avoided with better interface design), here's what you can do:

    - on page 1, make a multistate bargraph with 4 states. level code 1, channel code 1, address code 1. For states 2 and 4, put whatever graphics you want the button to have when it is visible. For states 1 and 3, make the button invisible (fill = transparent, text = transparent, etc)
    - on page 2, make a multistate bargraph with 4 states. level code 1, channel code 1, address code 1. For states 3 and 4, put whatever graphics you want the button to have when it is visible. For states 1 and 2, make the button invisible (fill = transparent, text = transparent, etc)

    You can now control which pages the buttons are visible on in code using a SEND_LEVEL dvTP, 1, n
    where n is the following:
    1: neither page has the button showing
    2: only page 1 shows the button
    3: only page 2 shows the button
    4: both pages show the button
  • dnahmandnahman Posts: 28
    Thanks for the suggestions. With everybody's confirmation that I'm not missing out on a simple and elegant way to do it, I'll just live with burning extra address codes.

    --david
  • jjamesjjames Posts: 2,908
    Hmm - after looking at the suggestions - what do you consider elegant? I'm really curious what your expectations are.

    Matt's suggestion I think is by far the simplest approach. It's one line of code, instead of "burning" an address, you use a level. With John's you use a bitmap to hide the button (sorry John, don't know if that's exactly what you were saying.) And mine uses logic that there's no reason to hide or show a button on a page that you're not even on to begin with.

    So you've got three options - what is your most perfect solution? A command that shows and hides buttons that you're not even looking at? That's much like sending DVD feedback to a panel when it's looking at the radio page. There's no reason to send unnecessary traffic to the panel when you don't have to, and this is essentially what you're doing. So if anything, your current approach to sending data to a panel is wasteful; perhaps you should reevaluate the way you do things before looking for "elegant" and "simple" approaches when it comes to hiding and showing a button.
  • Hi,

    If you could give a page (or popup) name as an extra argument to a version of ^BMF, then you would have the ability to change the attributes of a button on an instance by instance basis -- not unlike setting one instance of a button to hidden, and another with the same address & channel codes to visible from within tpDesign.

    As another example I have a source and destination routing matrix page. For some destinations, a given source may be invalid certain contexts. These change fairly frequently. Right now I have to define separate popup pages for the sources based on the selected destination and modify the touchpanel file and the axs file for each change. It would be nice to be able to set the visibility of each source & destination in a descriptive structure for each source, and either hide/show on each popup during the online event for each panel when I populate each button with its source name, etc.

    --david
  • jjamesjjames Posts: 2,908
    dnahman wrote: »
    If you could give a page (or popup) name as an extra argument to a version of ^BMF, then you would have the ability to change the attributes of a button on an instance by instance basis -- not unlike setting one instance of a button to hidden, and another with the same address & channel codes to visible from within tpDesign.

    As another example I have a source and destination routing matrix page. For some destinations, a given source may be invalid certain contexts. These change fairly frequently. Right now I have to define separate popup pages for the sources based on the selected destination and modify the touchpanel file and the axs file for each change. It would be nice to be able to set the visibility of each source & destination in a descriptive structure for each source, and either hide/show on each popup during the online event for each panel when I populate each button with its source name, etc.

    Hmm . . . perhaps Visual Architect or AMXhome would fit your needs more. I don't know if you should be meddling with TPD4 or NS3 very much, it could be dangerous.
Sign In or Register to comment.