Roll your own Hopper in 200 lines of code – sample included!

To increase Hopper awareness and help prove how simple Hopper really is, I have developed a bare-bones sample that embodies the essence of Hopper. My main motivation for sharing this tool is to provide a simplified, Hopper-like tool for our general Windows CE customers and figured the HoppeRx readers might also be interested in Hopper “under the hood”.


To make the topic easier to understand and to enable a framework upon which you can customize, I abstracted many details that will be left to reader to complete. The code snippet will build and run as-is, but you will quickly see that more sophistication will be needed for a mature tool capable of increasing device stability.


There are several meta-level abstractions intentionally left in the code to provide clarity in what the tool is actually doing.


  1. Input Section: Define your inputs. Does your device allow keystrokes? Screen taps? You want to include all possible inputs in this key structure – this is the superset of all possible inputs the tool will send to your device. If you are developing a headless device for example, you would replace the VK_ codes used in the sample to whatever will be sent to your device.

  2. Logging Section: Currently the sample simply outputs to standard debug out, but could easily be change to log to a file, storage card, display, etc. It is left to the user to determine the best way store important logging information while the tool runs. As your tool matures (and your device becomes more stable) you will likely want a way to optimize logging since each message printed will affect the timing of the device.

  3. GetNextInput Section: Logic defined here will determine the next input sent to your device. I have introduced a system of “weight” which allows you to include inputs that should be called less often than other keys. What weight any particular input should carry is left up to you and will likely be tuned when you can start observing runs.

  4. DoAction Section: Perform the input selected in the previous step. The sample contains simple keyboard events but can be easily customized to send screen taps, network packets or whatever your device needs.

  5. Thread Section: The sample spins up a simple thread that controls execution and should contain validation code such as logic to detect device hangs and other stabilization issues. It would be beneficial to add additional threads that monitor device health and possibly watch for certain events that may halt execution, but this is left for you to complete and customize.

You might be asking: what possible good could come from having another Hopper-like tool during development? Isn’t one Hopper tool enough? The answer will depend on exactly what you are faced with – if you device is passing all your stabilization metrics then your answer is easy, but for the rest of us …



Comments (8)

  1. Klein says:

    Does Hopper support touch-panel? or only support key press?

  2. shende says:

    Hopper supports touch-panel when it detects the device is a PPC platform.

    The Sample included in this entry is very simplified and only presses keys. The point is the code included is easily modified to do *whatever* your device supports. Simply remove the keypress logic and replace with your input method. Did I answer your question?

  3. Klein says:

    Thanks for your reply!

    I’m so about how Hopper simulate the pen event. If the click on screen is randomly, is it possible that Hopper clicks about 3 hours but never click on something can response to the click?

  4. shende says:

    Hopper is designed to click on the start menu very frequently (every couple of minutes) in hopes of changing the foreground application. The scenario you mention is increadibly unlikely.