12-06-2006, 09:48 PM
|
|
|
Join Date: 10-02-2005
|
|
Location: Norfolk
|
|
PDAPhone: PPC-6800
|
|
Carrier: Sprint PCS
|
Donate to Member
| Posts:
943 |
 |
Quote:
|
Originally Posted by haus
Just curious, am I the only one who can defeat OnLock using the start button the first time it runs (not using anything called smallmenu)? This is not meant to be a ding on jkinggrim...just curious if this program *really* works on standby as I thought it was supposed to. I just reinstalled OnLock (from page 2 of this thread) and here's what I do:
Verify that the phone is unlocked on the today screen. Press the power button to suspend the phone. Wait a couple of seconds, then press the power button again to turn the phone back on. Just before the screen comes on, hit the start button once (or a couple times if you're not sure of the timing). I always get the start menu up before the lock engages. Once the menu is up, I can choose one of the programs in there and select it, though once it starts I can't do anything else because the lock is engaged.
I only ask this because the program is supposed to lock on suspend (at least I thought so) and it appears not to be doing that, since I can get at least one button press in before the lock engages when I come out of suspend.
I'm not running .Net framework. I have VC1.6 installed on a Verizon 6700, if that makes any difference.
|
This is due to the design of the OS. When you hit the power button to turn the device off, the system sends out a notification just before the device powers down. There are simply not enough processor cycles from the time my app recieves the notification to the time the device powers down. When the device powers back on, my app must wait to recieve processor time again to actually lock. Threads with higher priority than mine are granted time first. So in that delay, you can get a key press in. So my method is not perfect, but it works much faster than the other method of starting at the 'power on' notification that most lock utilities use.
That being said, I did create another method where rather than waiting for the power off notification, my app installed a keyhook and detected immediately the moment you pushed the power key. This method had other benefits, besides the fact that it could lock before the device even turned off. I wanted to make it so that pressing and holding the power key would lock and turn the screen off. The reason that I chose not to is because win ce 5.0 imposed a systemwide limmitation of one key hook. For a while I couldnt figure out why my app worked in the emulator and not on my device. Then I found out PQZII also installed a key hook, and therefore my app couldnt. I did not want to write an app that may or may not play fair with other apps, so I abanoned that method.
About the solitaire incident  , my guess is that first you selected solitaire on the menu, then it locked, then solitaire came up. Therefore, the solitaire window had the focus, and was able to accept input. Other random problems people have with still being able to use certain buttons when locked are problems with the built in lock. My app just invokes it. This is another reason why I want to write a full lock. That way, I could deal with these problems. But see above post. I will have another crack at it though. Any help would be appreciated.
Last edited by JKingGrim : 12-06-2006 at 10:01 PM.
|
|
|
|
|