The program was initially developed with PocketPC and then in Fivewin and via RDP. It is still in use today in the same way.
Since I always held it in my left hand while programming, it was completely designed for left-handed users, which turned out to be fortunate, as most waiters/waitresses carry the trays in their right hand and can start taking orders right away.
How I implemented the program quickly back then
The application could be developed so quickly because I deliberately avoided using classic Windows controls (buttons, text boxes, list boxes). Instead, I designed the interface entirely with bitmaps and text output via Windows standard functions (e.g., GDI functions such as TextOut and BitBlt).
User actions were detected by querying the mouse or touch coordinates (click point) and matching them with the positions of the “virtual buttons.”
Advantages of this method
Minimal system load: No overhead from managing dozens of controls.
Simple event logic: Only simple area checks (e.g., if (x >= btn.left && x <= btn.right)), no complex message processing (WM_PAINT, WM_COMMAND).
High speed: Extremely fast event handler, ideal for latency-critical applications.
Fixed resolution: Optimized for a fixed layout without a complex layout engine.
I still use this principle today – for example, in the POS system and wireless terminals. Operation is via RDP with a dedicated “remoter” in kiosk mode: access is fully locked down except for the input window. Fonts and image sizes can be adjusted via a scaling function. The first resolution we optimized for was 240 × 320 pixels (classic HP iPAQ models).
Even on the small HTC LEO (HD2) – the first Windows Mobile smartphone with a capacitive multi-touch display – the concept worked perfectly. Here, we also integrated swipe gestures:
Left → Right: Complete the order
Swipe on virtual button: Switch between product lists
Since I always held it in my left hand while programming, it was completely designed for left-handed users, which turned out to be fortunate, as most waiters/waitresses carry the trays in their right hand and can start taking orders right away.
How I implemented the program quickly back then
The application could be developed so quickly because I deliberately avoided using classic Windows controls (buttons, text boxes, list boxes). Instead, I designed the interface entirely with bitmaps and text output via Windows standard functions (e.g., GDI functions such as TextOut and BitBlt).
User actions were detected by querying the mouse or touch coordinates (click point) and matching them with the positions of the “virtual buttons.”
Advantages of this method
Minimal system load: No overhead from managing dozens of controls.
Simple event logic: Only simple area checks (e.g., if (x >= btn.left && x <= btn.right)), no complex message processing (WM_PAINT, WM_COMMAND).
High speed: Extremely fast event handler, ideal for latency-critical applications.
Fixed resolution: Optimized for a fixed layout without a complex layout engine.
I still use this principle today – for example, in the POS system and wireless terminals. Operation is via RDP with a dedicated “remoter” in kiosk mode: access is fully locked down except for the input window. Fonts and image sizes can be adjusted via a scaling function. The first resolution we optimized for was 240 × 320 pixels (classic HP iPAQ models).
Even on the small HTC LEO (HD2) – the first Windows Mobile smartphone with a capacitive multi-touch display – the concept worked perfectly. Here, we also integrated swipe gestures:
Left → Right: Complete the order
Swipe on virtual button: Switch between product lists