Release Time

2»

Comments

  • frthomas
    frthomas Junior Member
    Reese Jacobs wrote:
    At this point, it might be worthwhile to take a closer look at Jeremiah's original code block to see if there is another explanation for what was happening.

    Did that and I can't find any fault there. The "queue" in the release is useless but harmless. If should be equivalent to TIMELINE_KILL(GET_LAST(nTP)). For some reason GET_LAST(nTP) is 2 twice.

    Given your test, and my experience, my conjectures were probably a bit wild, as wild it seems as the function name and standard help text :-)
    In general, I agree, GET_LAST() works as we all expect.

    In your testing, did you try to replicate the exact case, that is 2 external RELEASE occuring at the same time? That might be THE single problematic case (i.e. a bug or some side effect from the apparent stack handling).

    Fred
    · Share on FacebookShare on Twitter
  • B_Clements
    B_Clements Senior Member
    More on Get_Last
    DHawthorne wrote:
    That suggests it does not, in fact, use the device event that triggered the handler, but reads it from the stack. Since PUSH and RELEASE are for all practical intents instantaneous, it's not an issue for them. But a HOLD handler may persist through several other events.
    Absolutely correct Dave.

    Again, think of a Hold like a Wait. There is really no Event associated with the Hold even though it exists under a Button_Event. Whatever the value of Get_Last is when the code in the Hold is run, that is what you get. Potentially it could be the value of Get_Last from some other Button_Event or Channel_Event. If there is only one panel in the system, no problem.

    Most programmers will not have all the panels next to them to do this kind of test as in most cases they are installed in remote locations.
    · Share on FacebookShare on Twitter
  • Reese Jacobs
    Reese Jacobs Junior Member
    GET_LAST() - Don't Be Afraid
    Did that and I can't find any fault there. The "queue" in the release is useless but harmless. If should be equivalent to TIMELINE_KILL(GET_LAST(nTP)). For some reason GET_LAST(nTP) is 2 twice.

    Hey Fred,

    I also looked at the code and did not see anything obvious either. One note, I too was thrown off by the queueing in the RELEASE which is not necessary. I agree it is harmless in this case. In my testing, I did re-create scenarios in which multiple release events occur in succession and I tried to have them occur as quickly as possible. I know for a fact that at one point in the test, at least 4-5 RELEASE events were queued while a RELEASE handler was processing another event. I think if GET_LAST() were broken for this unique case, I would have seen it in the testing but anything is possible. I wish I had a better answer for the original problem but I am reluctant to conclude it is GET_LAST() at this point.

    Reese
    · Share on FacebookShare on Twitter
  • alexanbo
    alexanbo Junior Member
    The way I understand Get_Last to work is that each array stores a variable that represents the index of the last member of that array. This is similar to the length variable that arrays store. So Get_Last just returns the variable.

    Now it seems like in some cases, particularly Hold that the variable doesn't get updated correctly or that the variable is changed by a subsequent event before the get_last line from the previous event could fire.

    Nick in my last training class was the one who explained how get_last worked and mentioned that you can invoke get_last on arrays that aren't necesarily part of the event.
    · Share on FacebookShare on Twitter

Categories