[Touch Diamond, MDA Compact IV Themes and Apps] ZuinigeRijder:
Thanks fourcc for the test effort and detailed information!

3. TouchLockPro is writing the debug log all the time, so when you want to copy the log file, you should disable TouchLockPro, otherwise it can give this problem (although I did set the log file for shared read, while writing)

According to the logging, TouchLockPro is locking:

22:25:19 -855504958 SetLocked(true)

Immediately an incoming call is detected/notified:

22:25:22 755498898 NotificationCallStatusIncoming()

But it is unlocked at the same time by the light sensor:

22:25:22 -855504958 ========================UNLOCK BY LIGHT SENSOR=============================

Thereafter, the notify is handled on the main thread:

22:25:22 -855504958 NOTIFY_CALLSTATUS_INCOMING

And because you have the setting, LockWhenIncoming=1:

22:25:22 -855504958 IsConnectedCall(false)

22:25:22 -855504958 Lock(true)

But immediately unlocked by the light sensor again:

22:25:23 -855504958 ========================UNLOCK BY LIGHT SENSOR=============================

And the incoming call was stopped:

22:25:31 755498898 SetCallStatus(CALL_ENDED): 1

But you also have set: AutoLockOnPowerOn: 1

Why do you also have then the need for LockWhenIncoming=1?

Looking at the log, it looks like TouchLockPro is doing what it should.

So it looks like the light sensor is competing with your setting LockWhenIncoming=1.

0:19:05 735603834 ========================POWER_STATE_SUSPEND: SCREEN OFF==========================

0:19:49 735603834 SetOnBattery(true)

0:19:49 735603834 NotificationBatteryPower()

0:19:49 -1924371810 NOTIFY_BATTERY_POWER

0:19:49 -1924371810 Lock(true)

And for log 6:

22:23:05 -1394322754 NOTIFY_BATTERY_POWER

22:23:05 -1394322754 Lock(true)

TouchLockPro is thinking that the phone is switching from AC/USB power to battery power, and as a result it locks the phone. However, the screen is still off, so it should not LOCK the phone, because that will make it impossible to press the power button anymore for waking the phone.

So found the BUG!!

It should not LOCK in all those cases, when the screen is off :eek:

Fixed my code already locally.

9:35:19 740270042 CTAPIDevice::lineCallback()

9:35:20 -1880509090 ClockWndProc: 275

9:35:23 203398638 PBT_TRANSITION

9:35:23 740270042 LINE_DEVSPECIFIC=(104, 5, 0)

9:35:23 -1880509090 ClockWndProc(WM_TIMER): 1

9:35:23 203398638 PBT_TRANSITION POWER_STATE_PASSWORD

9:35:23 740270042 CTAPIDevice::lineCallback()

9:35:23 203398638 ==============================PBT_RESUME===============================

9:35:23 740270042 LINE_DEVSPECIFIC=(107, 20, 0)

9:35:23 -1880509090 ClockWndProc: 275

9:35:23 203398638 PBT_TRANSITION

9:35:23 -1880509090 ClockWndProc(WM_TIMER): 1

9:35:23 203398638 PBT_TRANSITION POWER_STATE_ON

9:35:23 203398638 PBT_TRANSITION POWER_STATE_BACKLIGHTON

9:35:23 203398638 PBT_TRANSITION POWER_STATE_PASSWORD

9:35:23 203398638 =========================POWER_STATE_ON============================

9:35:23 203398638 resumeSeconds POWER_STATE_ON: 380123

9:35:23 203398638 IsConnectedCall(false)

9:35:23 203398638 ==========================DisableInput()==============================

9:35:23 203398638 SetDisabledPanelAndButtons(true)

9:35:23 203398638 PowerOnRequest()

I first disable the input, before handling the power on request. So it should already be locked! I see however, 4 seconds, between the first TAPI notification and the power on notification of Windows Mobile. I do not know, if the screen is already activated in the mean time (I would not expect).

9:35:25 -1880509090 ========================UNLOCK BY LIGHT SENSOR=============================

9:35:23 -1880509090 ==================================Lock=============================(true)

Do it again.

10:34:20 -1952755434 ========================POWER_STATE_UNATTENDED: SCREEN OFF====================

10:34:20 -1952755434 PBT_TRANSITION

10:34:20 -1952755434 PBT_TRANSITION POWER_STATE_SUSPEND

10:43:52 -854623922 CTAPIDevice::lineCallback()

10:43:52 1270447706 ClockWndProc: 275

10:43:56 -1952755434 ========================POWER_STATE_SUSPEND: SCREEN OFF==========================

10:43:56 -854623922 LINE_DEVSPECIFIC=(104, 5, 0)

10:43:56 1270447706 ClockWndProc(WM_TIMER): 1

10:43:56 -1952755434 PBT_TRANSITION

10:43:56 -854623922 CTAPIDevice::lineCallback()

10:43:56 1270447706 ClockWndProc: 275

10:43:56 -1952755434 PBT_TRANSITION POWER_STATE_PASSWORD

10:43:56 -854623922 LINE_DEVSPECIFIC=(107, 8, 0)

10:43:56 1270447706 ClockWndProc(WM_TIMER): 1

10:43:56 -1952755434 ==============================PBT_RESUME===============================

10:43:56 -1952755434 PBT_TRANSITION

10:43:56 -1952755434 PBT_TRANSITION POWER_STATE_ON

10:43:56 -1952755434 PBT_TRANSITION POWER_STATE_BACKLIGHTON

10:43:56 -1952755434 PBT_TRANSITION POWER_STATE_PASSWORD

10:43:56 -1952755434 =========================POWER_STATE_ON============================

10:43:56 -1952755434 resumeSeconds POWER_STATE_ON: 384236

10:43:56 -1952755434 IsConnectedCall(false)

10:43:56 -1952755434 ==========================DisableInput()==============================

10:43:56 -1952755434 SetDisabledPanelAndButtons(true)

10:43:56 -1952755434 PowerOnRequest()

Again here, I see 4 seconds between the first CTAPIDevice::lineCallback() call and when it really locks.

This just means, that TouchLockPro does not get a chance to do something. Maybe because a high priority process is eating up the CPU :confused:

The only thing I can think from TouchLockPro perspective is giving itself a higher priority. But I think, the real problem is the other (which one?) process which eats all the CPU, before other programs can do something :mad:

12:31:40 207017594 ========================POWER_STATE_SUSPEND: SCREEN OFF==========================

12:34:53 207017594 HandlePowerNotifications()

12:34:53 756833058 ClockWndProc: 275

12:34:57 207017594 PBT_TRANSITION

12:34:57 756833058 ClockWndProc(WM_TIMER): 1

12:34:57 207017594 PBT_TRANSITION POWER_STATE_PASSWORD

12:34:57 756833058 ClockWndProc: 275

12:34:57 207017594 ==============================PBT_RESUME===============================

12:34:57 756833058 ClockWndProc(WM_TIMER): 1

12:34:57 207017594 PBT_TRANSITION

12:34:57 207017594 PBT_TRANSITION POWER_STATE_ON

12:34:57 207017594 PBT_TRANSITION POWER_STATE_BACKLIGHTON

12:34:57 207017594 PBT_TRANSITION POWER_STATE_PASSWORD

12:34:57 207017594 =========================POWER_STATE_ON============================

Again 4 seconds between

12:34:53 207017594 HandlePowerNotifications()

and

12:34:57 207017594 PBT_TRANSITION

Looks again TouchLockPro does not get CPU.

Sure it helped!

Found 1 bug.

I suspect one process eating up the CPU sometimes when starting. Which programs are running/have you installed?

Can you list the processes with a task manager?

But the only thing I can think of, is giving TouchLockPro a higher priority. But the problem lies in a misbehaviour of another program.