Prev: CeRapiInvoke RAPI function
Next: To detect SIM card is inserted or not in PPC
From: The PocketTV Team on 4 Sep 2008 02:47
hopefuly someone from MSFT will take note of this bug... i was able to
reproduce it with the latest emulators and with real devices, up to WM 6.1
(didn't try 6.2).

here is the scenario:

the application sometimes open a dialog window (let's call it dialog A) that
has a very standard menu bar with a menu attached to the right soft-key. the
application opens this dialog "spontanously", e.g. every 30 seconds, if the
application is in trial mode (i.e. not been purchased).

the problem occurs when the user presses the menu soft-button in the
application's main window, causing the menu to pop-up, and leaves the menu
opened i.e. does not make any selection in the menu.

in this situation, when the application pops dialog A, the menu of dialog A
does not appears when the right soft-key is pressed in dialog A.

i checked with debugger, and found no problem or error in the creation of
the menu of dialog A (SHCreateMenuBar works fine), i.e. the code appears to
work just fine, but the menu of dialog A does not appear when the soft-key
is pressed.

if dialog A is popped up when the menu of the main window is NOT opened, or
of it is popped up manually (e.g. by selecting a command in the menu of the
main window), then there is no problem, and the menu of dialog A works well.

the bug only happens if dialog A is opened by the application while the menu
of the main windows is opened. Note that this application is multithreaded,
i.e. it keeps doing things even while the menu of its main window is opened.

i was not able to find a workaround to this bug.


From: The PocketTV Team on 4 Sep 2008 03:10
i also tried to send explicitely a WM_CANCELMODE message to the main window,
but it does not appear to close its menu and it does not help.

actually this might be the real cause of the bug: normally, according to the
MSFT documentation:

"When the WM_CANCELMODE message is sent, the DefWindowProc function cancels
internal processing of standard scroll bar input, cancels internal menu
processing, and releases the mouse capture."

so when the main window receives a WM_CANCELMODE message, it should close
its menu if the menu was opened.

and by the way, i checked, the main window receives a WM_CANCELMODE when the
other dialog activates, even if i don't send one explicitely.

now, is there a way around this, i.e. is there a way to EXPLICITELY cause a
menu to close?


 | 
Pages: 1
Prev: CeRapiInvoke RAPI function
Next: To detect SIM card is inserted or not in PPC