How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command

[Jsather]

Apologies for such a lengthy post. I can’t wish away the details.

The Wait(-1) is an extremely convenient method of waiting for and reading touch pad activities and/or key presses. A command such as this is a large part of the “face” of the HP’ for programmers and users and must be extremely robust and well documented to enable programmers to deal with the huge variety of touches, drags, swipes, presses, bounces, pinches, drag velocities, etc. that may be encountered. The first rule is that the user might do anything and anything he does that the hardware allows is legitimate.

The bad news is that the Wait(-1) command, is not very robust but prone to freezing the calculator in a state that can only be retrieved by the “paper clip or On plus Symb” reset or worse. By worse, I mean that, in exploring the Wait(-1) freeze up I have managed to put my HP’ in a state where I could not edit programs, even after the paper clip reset. I only managed to revive the calculator by restoring a backup I had made using the connectivity kit. Let us all praise HP for the Backup / Restore capability and use it often.

More bad news is that HP has not completely documented the Wait(-1) command and has modified the undocumented features of the command in the 6030 firmware release without informing the community. The changes are in the handling of fast swipes of the finger across the touchpad. We cannot pretend these gestures will not occur and Wait(-1) will not detect them. If we ignore them, our code will not function. Shame on HP for not documenting them and trying to slip a change unnoticed in such a fundamental command.

The good news is that owner / operators are shedding a light on these shortcomings. My expectation is for a positive response from HP because they want these freeze-ups gone, more even than we.

You can observe the operation of Wait(-1) using a short and simple program called WaitLab that I’ve attached here and posted in the HP Prime software forum, http://www.hpmuseum.org/forum/thread-1545.html . The program simply prints the results of Wait(-1) in a continuous loop with a built in pause in the loop of Dly seconds. This simulates functional code that checks for user input and takes Dly seconds to process, then loops back and checks again. Every time Wait(-1) returns a list from the touchpad or a real number key press, the Mouse command is issued and the results are printed left to right: Wait(-1) result, time in milliseconds since the last result, Mouse result, velocity of drag in pixels per second if the result is a drag (code 1). Pressing the Esc key exits the program.

The purpose of writing this code was to explore the Wait(-1) and Mouse commands so I could learn how to program HP’ touchpad inputs. Obviously, HP documentation was lacking. When my real world code began freezing up, I used WaitLab to try and duplicate the freeze ups and eventually homed in on the specifics. I was ready to post that result when 6030 was released. I checked and found the specific freeze up had not been repaired, but my program was no longer functioning well due to changes in the way Wait(-1) responded to fast swipes. My priority was to get a handle on those changes and repair my code which I have partially done. Of course, that would have been a lot less time consuming if there had been documentation. Grrrr! Anyway, people are posting information about freeze-ups now, and I wanted to make my contribution; so I’m posting what I think I know.

Before using WaitLab, use the Connectivity Kit to backup your virtual and real calculator. You can lose your data and programs using 6030 Wait(-1).

Run WaitLab with any small delay (.01-.1 sec) to familiarize yourself with Wait(-1). Compare touches, long touches, drags, swipes, pinches, stretches, key presses, and touches in the button area at the bottom. You will see that those button area touches get special treatment, a nice feature (again undocumented) that your code should take into account.

On my computer, I can reliably freeze up the EMU (the virtual calculator) in either firmware rev 5447 or 6031 as follows: Run WaitLab with Dly = .1. Perform a long touch (1 second) to observe the normal sequence ({0,x,y}, {7,x,y},{2},{3,x,y} in 5447, {0,x,y}, {7,x,y},{2} in 6031 … didn’t you know?). Now press and hold a computer arrow key to activate the computer’s keyboard auto repeat function, then release the arrow key after a second or so. You will know you are ready to freeze the EMU if, after you released the arrow key, key presses continue to be indicated on the EMU display for a second or so. The EMU is now prepared to freeze up if you perform a long touch. This is true even you perform some short touches first which will respond normally. Go ahead and try some short touches which should work normally. Then place the cursor over the EMU display, press and hold your computer mouse left button for at least a second. Your EMU will then freeze up. A call will be made to Wait(-1) which places the EMU in an endless loop somewhere, control never to be returned unless you close the EMU and restart it.

This was the nature of the occasional freeze ups I encountered in a program of mine, only in the EMU, not the actual calculator. I eventually was able to isolate the problem to long touches after leaning on the arrow keys. You may not see the freeze ups on your computer because the auto repeat setups are different. I have mine set up for fast repeats after a short delay. But knowing the situation is related to key press buffering getting ahead of Wait(-1) calls, followed by long touches, we can create the freeze up situation by increasing Dly in WaitLab.

To reliably freeze up your HP’ or EMU, run WaitLab with Dly = .5, simulating half a second of processing between Wait(-1) returns. Press (or EMU click) any key on the calculator rapidly about 16 times. You should get the indication of keyboard buffering generating returns for a while every half second after you stop pressing the key. The calculator is now set up for the long touch to Wait(-1) that never returns, even if you perform some intervening short touches and drags.

After you’ve frozen up your calculator, you won’t be able to do anything with it unless until you perform a paper clip reset or press On and Symb at the same time, equivalent as far as I know. Do this so you can follow me on the changes to swipe handling by Wait(-1). I probably needn’t add that ideally, paper clip resets should never be required. Calculators are not supposed to freeze up under any circumstances.

After restarting your calculator, run WaitLab with a delay of .11. As opposed to dragging, swipe your finger fast to see the result of a detected swipe. If the calculator happens to freeze up, just restart it again. Assuming your firmware rev is 6030, you will know the swipe was detected because the calculator will continue to generate Wait(-1) returns for about a second after you finished the swipe. I’m not sure what triggers the swipe detection. It might be a velocity in the neighborhood of 700 pixels per second. I’m going to refer to the 1 second string of Wait(-1) returns as AutoDrags (short for auto repeat drags). Unique features of the AutoDrag returns are pixel coordinates off the screen (x,y<0, x>319, y>239) and the absence of a terminating {2} return. A nice feature is that AutoDrag returns are terminated if the user touches the screen, but a weak feature is that the programmer has no way to take charge and terminate them. It’s out of the programmer’s hands (unless there is a secret method I haven’t detected).

AutoDrag is a feature of firmware release 6030. There was swipe detection in 5447, but it consisted of a single x-coord return of 65535, followed by a terminating {2} return. The program needed to look at two returns prior to the 65535 return to get the direction of the swipe. There was a possibility of incoherent swipe detection, quick swipes without two preceding swipes, but that is all history now. My own code used IF x-coord > 319 to determine that Wait(-1) detected a swipe. No question as to why my code was on life support once I loaded 6030 considering the magnitude of the change in swipe detection from 5447 to 6030.

Please indulge me a moment while I complain to HP in a sanctimonious, self-superior manner. There are right ways and wrong ways to make a change like this. You could have left Wait(-1) alone and backward compatible and added Wait(-2) with AutoDrag as a new feature. Instead you skulk around in sneaky ways thinking you can modify code without telling anyone, just because you failed in your documentation mission in the first place. All the world doesn’t have scroll fever. Your AutoDrag takes control of Wait(-1) programming completely and leaves the programmer out of the loop, unable to accomplish his purpose. It would be a nice option but is an overbearing mandate. You’ve obviously never heard of Sather’s litmus test (which I’m making up as I write): If it’s not worth the effort to make it backward compatible to existing code, a change may well not be worth doing. Ditto for those stupid spaces you added behind the commas in lists printed via Textout_p. It’s a small screen. Don’t waste space. Bleah!

Alright now … Let us use AutoDrag to freeze up the HP’. Use the program editor to edit WaitLab and remark out the line “MS:=B->R(MOUSE());” so the call to Mouse no longer occurs after the Wait(-1) call. Now run WaitLab, again with Dly of .11 and do some fast swipes to activate AutoDrag. TaDaaa! Frosty the Snow Man … but if you let it sit there, it still seems to time out every minute and return a -1, even though it is otherwise frozen. The program I’m reviving is freezing up fairly often. I’ll try adding some Mouse calls after the Wait(-1) calls and post whether that or anything else is a viable workaround.

A parting note to the HP development team. Look, a lot of us have been around the block and can read between the lines. I probably wouldn’t have done any better in your shoes. You’ve created an amazing and unique product, and we are many behind you in hoping for its ultimate refinement and success. It’s all on your backs to make the right noise and the right changes. I hope this information is helpful in eliminating all the freeze ups people have been complaining about in other informative posts. Hang in there, and lots of love from the community.

Jfs.