Which is why I didn’t offer an alternative approach.
But you asked
I politely suggest you re-read the thread, especially the order of posts. I was very specific regarding what I sought. If Expire couldn’t do the job then I would explore using a Timer. I never asked you for an “alternative approach”. Yet, without knowing about my project’s requirements, you offered an unsolicited one (along with a paragraph about your “pet peeve”).
If I were to write a DP and I ran into a limitation with the Expire binding clearing the buffer, I’d look for, or at least consider and probably document a second option that didn’t require clearing the buffer at all.
Except I need to clear the buffer upon timeout. Second option was via a timer.
Clearing the buffer after a certain amount of time isn’t a requirement. It is a solution. The requirement is to process keypad events. Clearing the buffer after 20s is one approach among many to achieve that.
You provided the answer to my ‘empty string’ question, and I thank you once again for that, yet you continue to steal defeat from the jaws of victory. Clearing the buffer upon timeout is a requirement of this keypad’s design. Can’t make it any plainer that that. Having said that, I doubt it’ll dissuade you from telling me it’s not.
It’s based on the work of others in this thread: Basic UI - kepad. The primary difference is it does not transmit each keypress individually to the alarm system but collects them in a buffer to form the passcode. It processes the passcode only after the user presses the Submit key (a checkmark symbol) and then flushes the buffer (you could easily modify it so it automatically processes a 4 or 6 digit passcode). The Cancel key (an “X”) flushes the buffer immediately. If the user fails to enter and submit the passcode within a predefined time period, the buffer is automatically flushed.
You should know that the appearance and behavior of the keypad is not identical for iOS and Android clients. On Android, the last key you tap remains highlighted. Tapping it again retains the highlighting (but gives one the impression the key may not have been tapped). In a browser, there’s a slight flicker when you click the same key twice. In iOS, the last key also remains highlighted but if you tap it again the highlighting disappears. It’s a bit puzzling to the user but that’s the way it works.
If you were tasked to create a Design Pattern for flushing a string buffer, would your first choice be to empty it (zero-length string) or stick in a NULL or @ or some other flag to indicate the buffer needs to be emptied by a separate operation?
If I were asked to write such a DP, I would include exploring approaches that do not require clearing the buffer but accomplishes the same thing. I just don’t see why this is a problem for you. That is what I would do. It’s not an attack on you. It is not an attack on your use of Expire binding or Timers.
You asked what I would do.
I answered.
Should I have ignored the question? If so why ask it?
You’re doing it again here; shooting first, aiming last. Maybe you should ignore some questions.
As for my “direct question”, you’ve conveniently stripped it of its important context. It was in response to your comment that checking for purge flags was an acceptable way to flush a string buffer. For this purpose, it’s a lame workaround and that’s being polite.
Most bizarre of all is your continued persistence that I should consider “exploring approaches that do not require clearing the buffer but accomplishes the same thing”. Yes, erase the received string without erasing it. I’ll get right on that.
