Click here to get back home

Does DialogBox block on a smartphone?
 Home | NewsGroups | Search | About
Login Password
Register Now!
 microsoft.public.smartphone.developer    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
Does DialogBox block on a smartphone? Joe 09-25-2007
Posted by Joe on September 25, 2007, 10:54 am
Please log in for more thread options
 Hi,

I'm a bit confused here.

I have a dialog based, fullscreen app, with no message loop.

Several threads are kicked off which poll the internet for data.

Now I want them to continue polling and presenting the main dialog with the
data to work on.

This is working fine.
I then decided I wanted to present a dialog for the user to complete - while
the other stuff carries on.

I *thought* DialogBox blocked other processing, so I created a modeless
dialog to present to the user, with createdialog.

If I look at the output window in the debugger I see debugging messages
showing that the main dialog is still processing data whilst the modeless
dialog is up. Great it worked and I was happy.

I was experimenting with the default Messagebox (modal) in this dialog,
which I also thought would block the main processing. Guess what, it didn't.
The threads are still being instigated and the data processed by the main
dialog. It's as if I kicked off another thread for the messagebox.

I then decided to create the dialog with DialogBox instead of createdialog
and guess what, that doesn't block either.

I'm totally confused now.

How come the main dialog is still receiving messages whilst this other
dialog is being displayed via DialogBox?

I thought the currently displayed dialog "blocked" the other dialogs
processing loops.

Clearly they don't.

If I set a breakpoint in the debugger after the DialogBox statement it
doesn't hit that untill the dialogbox is closed, yet the main dialog
continues processing!!!

How come?

Would someone explain what the situation is re multiple full screen dialogs.

Thanks.













Posted by Norman Diamond on September 25, 2007, 8:48 pm
Please log in for more thread options
 DialogBox is documented as disabling the parent window. Disabling is
documented as blocking keyboard and mouse input, but not blocking other
kinds of Windows Messages.

In my experience on Pocket PCs, disabling also disables WM_CLOSE. I don't
know how many other undocumented misbehaviours occur.

If you're using MFC then ignore all of the above. An MFC pseudo-modal
dialog box isn't modal.


> Hi,
>
> I'm a bit confused here.
>
> I have a dialog based, fullscreen app, with no message loop.
>
> Several threads are kicked off which poll the internet for data.
>
> Now I want them to continue polling and presenting the main dialog with
> the
> data to work on.
>
> This is working fine.
> I then decided I wanted to present a dialog for the user to complete -
> while
> the other stuff carries on.
>
> I *thought* DialogBox blocked other processing, so I created a modeless
> dialog to present to the user, with createdialog.
>
> If I look at the output window in the debugger I see debugging messages
> showing that the main dialog is still processing data whilst the modeless
> dialog is up. Great it worked and I was happy.
>
> I was experimenting with the default Messagebox (modal) in this dialog,
> which I also thought would block the main processing. Guess what, it
> didn't.
> The threads are still being instigated and the data processed by the main
> dialog. It's as if I kicked off another thread for the messagebox.
>
> I then decided to create the dialog with DialogBox instead of createdialog
> and guess what, that doesn't block either.
>
> I'm totally confused now.
>
> How come the main dialog is still receiving messages whilst this other
> dialog is being displayed via DialogBox?
>
> I thought the currently displayed dialog "blocked" the other dialogs
> processing loops.
>
> Clearly they don't.
>
> If I set a breakpoint in the debugger after the DialogBox statement it
> doesn't hit that untill the dialogbox is closed, yet the main dialog
> continues processing!!!
>
> How come?
>
> Would someone explain what the situation is re multiple full screen
> dialogs.
>
> Thanks.
>
>
>
>
>
>
>
>
>
>
>
>


Posted by Joe on September 26, 2007, 10:51 am
Please log in for more thread options
----- Original Message -----
Newsgroups: microsoft.public.smartphone.developer
Sent: Wednesday, September 26, 2007 1:48 AM
Subject: Re: Does DialogBox block on a smartphone?


> DialogBox is documented as disabling the parent window. Disabling is
> documented as blocking keyboard and mouse input, but not blocking other
> kinds of Windows Messages.


Right. Thats my misunderstanding.


> In my experience on Pocket PCs, disabling also disables WM_CLOSE. I don't
> know how many other undocumented misbehaviours occur.
>
> If you're using MFC then ignore all of the above. An MFC pseudo-modal
> dialog box isn't modal.
>


No, just win32.

Thanks for your help.



Posted by Scott Seligman on September 26, 2007, 9:34 am
Please log in for more thread options
>I have a dialog based, fullscreen app, with no message loop.

You have a message loop. A window without a message loop is rather
useless. You obviously didn't write the message loop, but it's still
there.

>I was experimenting with the default Messagebox (modal) in this dialog,
>which I also thought would block the main processing. Guess what, it
>didn't. The threads are still being instigated and the data processed
>by the main dialog. It's as if I kicked off another thread for the
>messagebox.

This is as it should be. First off, threads have nothing to do with
message queues. Even if you did block your message queue, threads are
still going to do their thing.

Secondly, calling DialogBox will still create a message loop for you.
It's just disabling the parent dialog to create modality, so all other
messages are still being processed. Think of the situation on a desktop,
if the parent window didn't at least process WM_PAINT while it's child
was visible, what would the user experience be like?

>If I set a breakpoint in the debugger after the DialogBox statement it
>doesn't hit that untill the dialogbox is closed, yet the main dialog
>continues processing!!!

Somewhere inside of the call to DialogBox is a message loop. This loop
calls DispatchMessage, which in turn can call your main dialog's window
procedure to handle messages destined for that window.

--
--------- Scott Seligman <scott at <firstname> and michelle dot net> ---------
I don't need romance, Zak Kebron told her confidently. "I have
goldfish."
-- Star Trek: New Frontier: Fire On High by Peter David

Posted by Joe on September 26, 2007, 10:49 am
Please log in for more thread options

>>I have a dialog based, fullscreen app, with no message loop.
>
> You have a message loop. A window without a message loop is rather
> useless. You obviously didn't write the message loop, but it's still
> there.

Sorry, I meant an *explicit* message loop as in
while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
>>I was experimenting with the default Messagebox (modal) in this dialog,
>>which I also thought would block the main processing. Guess what, it
>>didn't. The threads are still being instigated and the data processed
>>by the main dialog. It's as if I kicked off another thread for the
>>messagebox.
>
> This is as it should be. First off, threads have nothing to do with
> message queues. Even if you did block your message queue, threads are
> still going to do their thing.

But if Dialogbox blocked the main thread they wouldn't get processed by it.
Which is what I thought DialogBox did.


> Secondly, calling DialogBox will still create a message loop for you.
> It's just disabling the parent dialog to create modality, so all other
> messages are still being processed. Think of the situation on a desktop,
> if the parent window didn't at least process WM_PAINT while it's child
> was visible, what would the user experience be like?
>
>>If I set a breakpoint in the debugger after the DialogBox statement it
>>doesn't hit that untill the dialogbox is closed, yet the main dialog
>>continues processing!!!
>
> Somewhere inside of the call to DialogBox is a message loop. This loop
> calls DispatchMessage, which in turn can call your main dialog's window
> procedure to handle messages destined for that window.
>

Ah, yes I see.

Thanks





Similar ThreadsPosted
DialogBox in Smartphone July 5, 2005, 10:59 pm
DialogBox on Windows Mobile 5 Smartphone BUG??? June 1, 2006, 1:59 pm
Call Block April 28, 2008, 8:51 am
Block or Edit Notifications January 15, 2007, 12:52 pm
read & write to registry on smartphone, pocket pc works smartphone doesn't July 7, 2005, 4:34 pm
No WM5 Smartphone Project even after installing WM5 Smartphone SDK November 18, 2006, 12:23 pm
Smartphone to Smartphone networking June 20, 2005, 11:47 pm
FTP AP in smartphone June 8, 2005, 8:03 pm
Smartphone SDK October 27, 2005, 4:52 pm
MFC for Smartphone December 5, 2005, 9:39 am

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap