Home AMX User Forum NetLinx Studio

Password programming question

I made a keypad that pops up on the TP when a user tries to look at a particular source. I created an array that can only hold 4 digits. Everything works great except for a bug I have found. When the user presses the "confirm" button, if the 4 numbers are correct, the series of events happens that allows that particular source to be displayed. However, if they press the "back" key, once they go all the way around, all 4 digits will re-display. I have tried CLEAR_BUFFER and SET_LENGTH_STRING to 0 but neither work. What am I doing wrong? Something else, when the user hits "confirm", the keypad disappears and they can continue on with business. If however, they once again open the keypad, the display comes blank, the length of the array shows 0, but one press of the backspace key will being up all 4 numbers again. After that all they need to do is press "confirm" and they are in.

Comments

  • jjamesjjames Posts: 2,908
    I for one am not quite following . . . could you show us just a little bit of code? I'm assuming that the numbers are stored in a string? Could you do something like this instead of clearing the buffer?
    cPassword = ''
    
  • staticatticstaticattic Posts: 200
    This is the code that displays the keypad:
    BUTTON_EVENT[dvTP,45]
    {
       PUSH:
       {
          SEND_COMMAND dvTP,"'@PPN-KeypadPreds'"
          CLEAR_BUFFER cKeyDigits
          SEND_COMMAND dvTP,"'^TXT-1,0,',cKeyDigits"
       }
    }
    

    This is the keypad "Backspace" key:
    BUTTON_EVENT[dvTP,213]
    {
       PUSH:
       {
          TO[BUTTON.INPUT]
          SET_LENGTH_STRING(cKeyDigits,LENGTH_STRING(cKeyDigits)-1)
          SEND_COMMAND dvTP,"'^TXT-1,0,',cKeyDigits"
       }
    }
    
    

    That is the part I think I have wrong. If they input 4 digits for example, pressing the backspace key will back up one digit at a time. When they press the backspace key a fifth time, all 4 digits will re-appear and the string will again be four digits long.
  • jjamesjjames Posts: 2,908
    This is untested, but what about doing this:
    IF(LENGTH_STRING(cKeyDigits)>1)
        SET_LENGTH_STRING(cKeyDigits,LENGTH_STRING(cKeyDigits)-1)
    ELSE
        cKeyDigits = ''
    

    Also, anywhere you have CLEAR_BUFFER, substitute it with cKeyDigits = '' and see if that helps.
  • AMXJeffAMXJeff Posts: 450
    I made a keypad that pops up on the TP

    I suggest you use the built in password keypad. It does all the backspace/clear work for you. Once you get the data back from the TP, then check in your list to see if the password is good.

    "'@PKP-&lt;initial text>;<prompt text>'"
  • jjamesjjames Posts: 2,908
    AMXJeff wrote: »
    I suggest you use the built in password keypad. It does all the backspace/clear work for you. Once you get the data back from the TP, then check in your list to see if the password is good.

    "'@PKP-&lt;initial text>;<prompt text>'"

    That too works nicely. :D I was thinking the same thing, but didn't know the command for it and figured he'd want to use his keypad for whatever reason.

    Thanks for pointing that out Jeff!
  • staticatticstaticattic Posts: 200
    I was going to do that, but when I opened PI and did a search for passwords, all I saw was pop up password code examples. I don't want another pop up to open, all I want is for the system to challenge the user to verify if they are allowed to view the particular input. Your suggestion would work nicely and actually be much less coding. I wasn't sure how handle the entries though. If password 2 = the correct password, then display input 32 as compared to opening a pop up page that allowed them to select input 32. How would I do that?

    IF Password 2 = CORRECT
    {
    do this
    }

    Thanks for all the replies.
  • yuriyuri Posts: 861
    there was something with CLEAR_BUFFER.
    As far as i can remember CLEAR_BUFFER doesn't actually clear the buffer, it just sets the index back to 0 (have to open my laptop with Netlinx Studio to double check)
  • DHawthorneDHawthorne Posts: 4,584
    yuri wrote: »
    there was something with CLEAR_BUFFER.
    As far as i can remember CLEAR_BUFFER doesn't actually clear the buffer, it just sets the index back to 0 (have to open my laptop with Netlinx Studio to double check)

    It sets the length to zero; the data is still there. In these kinds of cases, I repopulate the string with nulls for the entire length, then use clear_buffer.
  • staticatticstaticattic Posts: 200
    Yes, I found today that information is correct. I had set the string to a null value and moved on to bigger and better things. While researching another issue, I came across info about CLEAR_BUFFER and learned that it in fact does not "erase" the buffer, all it does is set the index back to 0. Funny. When I needed that info yesterday, I could not find it anywhere, then today, I happened to stumble across it while looking up something else using F1. Oh well. Thanks for all of the replies. I think what was messing me up was remembering in class we were taught it was better to use CLEAR_BUFFER than to set a string to a null value. I suppose the trick is to learn all of the "proper" coding techniques, then learn when it is acceptable to "break the rules". ;)
  • DHawthorneDHawthorne Posts: 4,584
    It's taught as "better" because it's more efficient. That doesn't speak to the drawbacks of that leftover data is visible; it's assumed that it doesn't matter. When it does matter, you do it a different way :) .
Sign In or Register to comment.