Well, as the old thread seems to have disappeared to that great bit-bucket in the sky, let me re-iterate what problems I discovered while using the hardware library. Keep in mind that these problems were discovered with the hardware object and hardkey object enabled.
In B4PPC, when a user presses a key in a textbox, the textbox_keypress event is fired. In VB, 3 events are fired. They are: textbox_keydown, textbox_keypress, and textbox_keyup. In VB, certain keys - for example, the cursor keys - are not acted on in the keypress event. I believe that this is because they have a default action "hardwired" by the OS. To trap and act on these keys, you use the keydown event.
With respect to Pocket Load, I checked for the up/down cursor keys and wrote code to handle them, in the keydown event. If these keys were pressed, the focus moved to the next/previous control on the form. Because I didn't SPECIFICALLY check for, and code for, left/right cursor key presses, the default action remained enabled and is carried out. In the keypress event, I checked for and coded for the Enter key (key code 13). This includes the keypad Enter key, the center cursor key, and presumably the SIP Enter key (I didn't specifically test the SIP keypad). BTW Erel, in my testing, both the center cursor key and the keypad Enter key returned keycode 13. There must be a way to differentiate (much like the left shift key vs the right shift key) or else Excel wouldn't act differently when the different keys are pressed! (We talked about this once before, you'll recall!)
My menu also behaved correctly in the VB version. In other words, when opening the menu, you would use the cursor keys to navigate it - all without additional code. I didn't finish the VB version - so I wasn't able to test it under real conditions. My thinking, based on the results of my testing, is that because these 'special keys' are acted upon on a per control basis (textbox_keydown) instead of modally (hardkey_hardkeypressed event), there should be no unexpected occurrences while your app is running - whether in the foreground or background!
It seems to me that Erel has created a "Visual Basic" for the PPC that, unlike Visual Basic, can be used by the developer to create apps for the device ON the device! :sign0188:
Visual Basic exposes intrinsic Windows controls with their events, methods, and properties to the developer so the developer can create an app. Not ALL of those events, methods, and properties are exposed to the developer (at least in older versions of VB). Some have to be accessed through API's. My assumption (I know that's dangerous
) is that Erel had to compromise between all of the available events, methods, and properties and program size in order to make this viable on the PPC. HOPEFULLY, this will be a matter of removing some of the events dealt with by the hardware library and adding those events (like a keydown event) to individual controls. This will remove the modal nature of these 'special key' presses, restore the "hardwired" default actions of these 'special keys', and should eliminate the unexpected (and unacceptable) occurrences with the current hardware library.
Maybe this can be done in time for version 5? (insert Praying Smiley here)
While this may sound a bit harsh, I think that overall Erel has done a wonderful job with Basic4PPC!:sign0188: (Much better than I could do!) If he can fix this (what I consider a very serious) bug it will be just about PERFECT!
- My keypad Enter key becomes a pseudo hardkey. My practice, when writing an app, is to trap the Enter key press in a textbox to signify that the user is done entering information. I then do things like format the text and move the focus to the next control, etc. With this problem, instead of trapping the Enter Key in the textbox_keypress event, I have to trap it in the hardkey_hardkeypressed event and using the hardware_keypress method send a substitute character (sending keycode 13 back to the textbox fires the hardkey_keypressed event again, resulting in an endless loop - as Erel pointed out to me) back to the textbox to signify that the user is done with that textbox. On the whole, this doesn't seem like a big problem. Consider this. My Pocket Load app was designed for a square screen device like my Treo 700wx. Those of you that have a rectangular screen may find it easier to enter information using the SIP. Pressing the SIPs' Enter key will do nothing. Why? Because I'm not testing for the Enter key anymore. Obviously, I could test for either the character returned by the hardware_keypress method or the Enter key, but that is, in my opinion, a little redundant - seeing as all the Enter keys should act the same.
- Modality of the hardkey_hardkeypressed event. I believe it was harleym who pointed out that as long as his app was running - even in the background - pressing a hardkey caused his app to "steal" control. When I tried my Pocket Load app for real, I ended up with a device that was locked up. This required a soft-reset and, of course, I lost all the information I had just entered. Subsequent testing showed similar results to harleym's, as long as my app was running, it tried to handle the hardkey presses. When my app couldn't handle the hardkey presses, it erred out and closed and then normal device operations resumed. This, in my opinion, is the most serious bug! This requires the developer to anticipate any event that COULD require the use of the hardkeys, while his app was running, and code a response into his app - even if the event occurred outside of his app!
- This problem is related to #2. The default action of the left/right cursor keys, in a textbox, is to move the cursor left and right within the confines of the textbox. In my app, if I make a mistake when entering info into a textbox, this default action is disabled by the hardkey_hardkeypress event. Obviously, this could be coded into the event. I have over 40 textboxes in my app. Some multi-line and all of varying width. I wouldn't know where to start writing a routine to handle that! :sign0082:
- Again, related to #2. I have a menu in my app. The default action when a menu is opened is that the cursor keys are used to navigate the menu. Once again, because of the modality of the hardkey_hardkeypressed event, this default action is disabled. WORSE YET, I can't figure out a way to put code in to HANDLE this action!!! For example, in my app, if txtRPM has the focus and the menu button is pressed, the menu appears but the focus doesn't leave the textbox! Pressing the up/down cursor keys at this point just leaves the menu open and shifts the focus from the current textbox to the next or previous control on the form!
In B4PPC, when a user presses a key in a textbox, the textbox_keypress event is fired. In VB, 3 events are fired. They are: textbox_keydown, textbox_keypress, and textbox_keyup. In VB, certain keys - for example, the cursor keys - are not acted on in the keypress event. I believe that this is because they have a default action "hardwired" by the OS. To trap and act on these keys, you use the keydown event.
With respect to Pocket Load, I checked for the up/down cursor keys and wrote code to handle them, in the keydown event. If these keys were pressed, the focus moved to the next/previous control on the form. Because I didn't SPECIFICALLY check for, and code for, left/right cursor key presses, the default action remained enabled and is carried out. In the keypress event, I checked for and coded for the Enter key (key code 13). This includes the keypad Enter key, the center cursor key, and presumably the SIP Enter key (I didn't specifically test the SIP keypad). BTW Erel, in my testing, both the center cursor key and the keypad Enter key returned keycode 13. There must be a way to differentiate (much like the left shift key vs the right shift key) or else Excel wouldn't act differently when the different keys are pressed! (We talked about this once before, you'll recall!)
My menu also behaved correctly in the VB version. In other words, when opening the menu, you would use the cursor keys to navigate it - all without additional code. I didn't finish the VB version - so I wasn't able to test it under real conditions. My thinking, based on the results of my testing, is that because these 'special keys' are acted upon on a per control basis (textbox_keydown) instead of modally (hardkey_hardkeypressed event), there should be no unexpected occurrences while your app is running - whether in the foreground or background!
It seems to me that Erel has created a "Visual Basic" for the PPC that, unlike Visual Basic, can be used by the developer to create apps for the device ON the device! :sign0188:
Visual Basic exposes intrinsic Windows controls with their events, methods, and properties to the developer so the developer can create an app. Not ALL of those events, methods, and properties are exposed to the developer (at least in older versions of VB). Some have to be accessed through API's. My assumption (I know that's dangerous
) is that Erel had to compromise between all of the available events, methods, and properties and program size in order to make this viable on the PPC. HOPEFULLY, this will be a matter of removing some of the events dealt with by the hardware library and adding those events (like a keydown event) to individual controls. This will remove the modal nature of these 'special key' presses, restore the "hardwired" default actions of these 'special keys', and should eliminate the unexpected (and unacceptable) occurrences with the current hardware library. Maybe this can be done in time for version 5? (insert Praying Smiley here)
While this may sound a bit harsh, I think that overall Erel has done a wonderful job with Basic4PPC!:sign0188: (Much better than I could do!) If he can fix this (what I consider a very serious) bug it will be just about PERFECT!
