Home› AMX User Forum› NetLinx Studio

Should I be stubbing out BUTON_EVENT RELEASEs?

Joe HebertJoe Hebert Posts: 2,159
in NetLinx Studio
I very rarely use the RELEASE for a BUTTON_EVENT (volume is the only one that comes to mind) and so I very rarely have a RELEASE: handler. Shouldn?t I be stubbing out the RELEASE in every BUTTTON_EVENT so Netlinx doesn?t have to make an unnecessary pass through mainline looking for it?

Do you all stub your RELEASE?

Comments

  • sethollesetholle Posts: 66
    NO release in button events

    I just never include the release statement in the button events. Does that slow the event itself down then?
    Could be critical in some systems I have hundreds of button events.
  • yuriyuri Posts: 861
    stub your release? What does that mean (im dutch :p )
    i only use the release function when i really need it (volume or camera control for instance)
  • DHawthorneDHawthorne Posts: 4,584
    stub = empty code block, as in: RELEASE : {}

    I don't bother, I don't believe it matters.
  • jjamesjjames Posts: 2,908
    I only use it when I need it like the previous posters - volume, or setting presets, or whatnot.
  • NMarkRobertsNMarkRoberts Posts: 455
    Joe Hebert wrote:
    Do you all stub your RELEASE?

    "Stub" (verb) to put in a piece of code that does nothing just to emphasise the fact that you are doing nothing.

    I support stubbing in lots of places eg switch/case defaults as a way of reminding yourself that you have or haven't thought about it. I even have a routine called DoNothing() which I sometimes use to amuse those who follow me. If anyone wants the code just let me know ;^)

    But as many have noted, releases are so rarely relevant that I don't bother.

    I do not believe that there is any performance implication either way.
  • yuriyuri Posts: 861
    offcourse, a stub... didnt know the expression "to stub something" :p
  • Spire_JeffSpire_Jeff Posts: 1,917
    yuri wrote:
    offcourse, a stub... didnt know the expression "to stub something" :p

    Not sure, when I stub my toe, it definately doesn't feel like NOTHING happened :P

    Jeff :)
  • GSLogicGSLogic Posts: 562
    Every button PUSH has a RELEASE if you enter release code or not.
  • NMarkRobertsNMarkRoberts Posts: 455
    Neologism
    yuri wrote:
    offcourse, a stub... didnt know the expression "to stub something" :p

    That's because Joe just made it up and it's such a good word everyone else ran with it!
  • Joe HebertJoe Hebert Posts: 2,159
    GSLogic wrote:
    Every button PUSH has a RELEASE if you enter release code or not.
    Exactly. That is why I think it matters and can make a difference when there is no RELEASE in a BUTTON_EVENT.

    Consider the attached picture and the following code.
    DEFINE_DEVICE

dvTP	= 10001:1:0

DEFINE_EVENT

BUTTON_EVENT[dvTP,1] {
   PUSH: {
      SEND_STRING 0, 'PUSH from Event'
   }
}

DEFINE_PROGRAM

PUSH[dvTP,1] {
   //mainline won't get called since the push is in event table.
   SEND_STRING 0, 'PUSH from mainline'   
}

RELEASE[dvTP,1] {
   //mainline will get called since the release is not in the event table.
   SEND_STRING 0, 'RELEASE from mainline'
}

    Output when button 1 is pushed and released:
    Line 1 :: PUSH from Event - 02:26:47
    Line 2 :: RELEASE from mainline - 02:26:47

    When the PUSH is triggered mainline does not get serviced since the PUSH was found in a BUTTON_EVENT. When the RELEASE is not found in the event table, Netlinx also has to run through mainline to try to find a match. So some of the event driven power that Netlinx offers is diminished to a degree when it has to double up on work by looking through the event table and mainline.

    How much of a performance implication can certainly be debated but I do believe there is one. Perhaps it?s too minuscule to matter though in most applications.
    yuri wrote:
    stub your release? What does that mean (im dutch :p )
    It?s an esoteric euphemism which only AMX programmers are privy too. Stub your release has several different meanings. One example of usage: If you are driving down the highway and an AMX programmer cuts you off in traffic you can roll down your window and yell, ?Hey buddy, go stub your release!? :D
  • yuriyuri Posts: 861
    So Joe, in a nutshell, this would mean we should be "stubbing our releases"? :p
  • Joe HebertJoe Hebert Posts: 2,159
    I?m not sure, yuri. That?s why I posed the question to the group. I?m thinking maybe we should for the reasons stated above but I may be in the minority.
  • jjamesjjames Posts: 2,908
    Joe Hebert wrote:
    If you are driving down the highway and an AMX programmer cuts you off in traffic you can roll down your window and yell, ?Hey buddy, go stub your release!? :D
    Only in Chicago; in L.A. you may give you the one-stub salute; and in my town, 99.7% of the population doesn't know what AMX is, so a stub is pretty worthless. :D

    However, in all seriousness, this is a pretty interesting topic, and probably would agree with you Joe - that even though the release is "searched" for in mainline, very little (if any) performance would be impacted. This almost falls into the same performance debate of, "should I use for-loops in mainline, or spell everything out?" I would love to hear from a Programming Master or even an AMX old-timer on this topic . . .. ;)
  • [Deleted User][Deleted User] Posts: 0
    Defeating action in the Define_Program section

    Your code can have a stub, but you cannot stub your code. ;)
    stub (stub) noun
    A routine that contains no executable code and that generally consists of comments describing what will eventually be there; used as a placeholder for a routine to be written later.

    If you don't want to have your Define_Program section processing button releases then it would be a good idea to have a RELEASE: with no code.

    This would handle all releases of a single touch screen port. 
    Define_Device
dvTP = 10001:1:0

Define_Event
Button_Event[dvTP,0]
{
  Release:
  {
    // No release code defined
  }
}
    I do not believe there would be any run time improvement only a 'main line' filter.
  • Joe HebertJoe Hebert Posts: 2,159
    One stub fits all. Good idea, Brian.
    B_Clements wrote:
    This would handle all releases of a single touch screen port. 
    Define_Device
dvTP = 10001:1:0

Define_Event
Button_Event[dvTP,0]
{
  Release:
  {
    // No release code defined
  }
}
  • jjamesjjames Posts: 2,908
    This issue seems to be resolved, however, if I were to use the stubbed [dvTP,0] button_event, would any code in my other button_events that have release code (i.e. volume releases, preset setting/recalls, etc.) execute? Or is the stubbed [dvTP,0] button_event used only in a program where you do not have any need for a release?
  • Joe HebertJoe Hebert Posts: 2,159
    jjames wrote:
    if I were to use the stubbed [dvTP,0] button_event, would any code in my other button_events that have release code (i.e. volume releases, preset setting/recalls, etc.) execute?
    Yes it would.
  • DHawthorneDHawthorne Posts: 4,584
    I think the real question here is if such stubs actually grant any benefit. I am inclined to think that if you don't put it in yourself, it's implicit, and there is no performance difference. I only stub when I want a placeholder to make my code easier to follow.
  • ericmedleyericmedley Posts: 4,177
    Okay then...
    ... to open another can of worms...

    Should we then also be stubbing HOLDs in the Button_Events?
  • travtrav Posts: 188
    HOLD me, my brain hurts.

    -trav
  • [Deleted User][Deleted User] Posts: 0
    Bad Idea
    ericmedley wrote:
    Okay then...
    ... to open another can of worms...

    Should we then also be stubbing HOLDs in the Button_Events?

    Absolutely Not!

    It would be like generating a huge stack of WAITs with no purpose.

    Don't even go there.
  • ericmedleyericmedley Posts: 4,177
    B_Clements wrote:
    Absolutely Not!

    It would be like generating a huge stack of WAITs with no purpose.

    Don't even go there.

    : ) (gotcha!)
Sign In or Register to comment.