Serial data + DialogBox

Page 2 - Seeking answers? Join the Tom's Guide community: where nearly two million members share solutions and discuss the latest tech.
G

Guest

Guest
Archived from groups: microsoft.public.pocketpc,microsoft.public.pocketpc.developer,microsoft.public.windowsce.app.development,microsoft.public.windowsce.embedded (More info?)

Doug,

Yes, my MessageBox will be visable until I hit OK! But when I have several
messages boxes sequentially in my thread code I only see on messagebox!

-Frank



"Doug Forster" <doug_ZAPTHIS_AT_ZAPTHIS_TONIQ_DOT_CO_DOT_NZ> wrote in
message news:%23WxJjrM0EHA.1260@TK2MSFTNGP12.phx.gbl...
> Hi Frank,
>
> For a start I think you have some basic misunderstandings about the
> difference between modal and modeless dialogs. The MessageBox call is
modal
> and has its own message loop and does not exit until the user clicks OK or
> escape. You should study the docs on the subject.
>
> You need to show us some of the actual code in the while(1) loop
>
> I notice you are also posting the public.pocketpc group. IMO this is
> somewhat off topic for that group
>
> Cheers
>
> Doug Forster
>
> "Frank Vicious" <dontspame@lame.com> wrote in message
> news:O2UFiRM0EHA.1260@TK2MSFTNGP12.phx.gbl...
> >> "Bruce Eitman (eMVP)" <beitmannospam@NOSPAM_applieddata.NOSPAM_net>
wrote
> > in message
> >>
> >> You are going to have to show us some code for that thread.
> >
> > Bruce!
> >
> > I put the thread creation in the WM_INITDIALOG case for my DialogBox.
> > Once
> > this dialogbox is setup I want to have a thread created, reading serial
> > data, and updating the text fields of this dialogbox. I've taken out
> > parts
> > of the code to simplify this post. Thanks for any info!
> >
> > // Global Variables:
> > HINSTANCE g_hInst; // The current instance
> > HWND g_hwndCB; // The command bar handle
> > HWND global_handle;
> > HANDLE serial_threadHDL; // Handle to the serial thread.
> >
> > int WINAPI WinMain( HINSTANCE hInstance,
> > HINSTANCE hPrevInstance,
> > LPTSTR lpCmdLine,
> > int nCmdShow)
> > {
> >
> > if (!InitInstance (hInstance, nCmdShow))
> > {
> > return FALSE;
> > }
> >
> > // Key combos
> > hAccelTable = LoadAccelerators(hInstance, (LPCTSTR)IDC_BAREBONES4);
> >
> > // Main message loop:
> > while (GetMessage(&msg, NULL, 0, 0))
> > {
> > if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
> > {
> > TranslateMessage(&msg);
> > DispatchMessage(&msg);
> > }
> > }
> >
> > return msg.wParam;
> > }
> >
> > ATOM MyRegisterClass(HINSTANCE hInstance, LPTSTR szWindowClass)
> > {
> > WNDCLASS wc;
> >
> > wc.style = CS_HREDRAW | CS_VREDRAW;
> > wc.lpfnWndProc = (WNDPROC) WndProc;
> > wc.cbClsExtra = 0;
> > wc.cbWndExtra = 0;
> > wc.hInstance = hInstance;
> > wc.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_BAREBONES4));
> > wc.hCursor = 0;
> > wc.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH);
> > wc.lpszMenuName = 0;
> > wc.lpszClassName = szWindowClass;
> >
> > return RegisterClass(&wc);
> > }
> >
> > //
> > // FUNCTION: InitInstance(HANDLE, int)
> > //
> > // PURPOSE: Saves instance handle and creates main window
> > //
> > // COMMENTS:
> > //
> > // In this function, we save the instance handle in a global variable
> > and
> > // create and display the main program window.
> > //
> > BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
> > {
> > HWND hWnd = NULL;
> > TCHAR szTitle[MAX_LOADSTRING]; // The title bar text
> > TCHAR szWindowClass[MAX_LOADSTRING]; // The window class name
> >
> > g_hInst = hInstance; // Store instance handle in our global variable
> > // Initialize global strings
> > LoadString(hInstance, IDC_BAREBONES4, szWindowClass, MAX_LOADSTRING);
> > LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
> >
> > //If it is already running, then focus on the window
> > hWnd = FindWindow(szWindowClass, szTitle);
> > if (hWnd)
> > {
> > // set focus to foremost child window
> > // The "| 0x01" is used to bring any owned windows to the foreground
and
> > // activate them.
> > SetForegroundWindow((HWND)((ULONG) hWnd | 0x00000001));
> > return 0;
> > }
> >
> > MyRegisterClass(hInstance, szWindowClass);
> >
> > RECT rect;
> > GetClientRect(hWnd, &rect);
> >
> > hWnd = CreateWindow(szWindowClass, szTitle, WS_VISIBLE,
> > CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL,
> > hInstance, NULL);
> >
> > global_handle = hWnd;
> >
> > if (!hWnd)
> > {
> > return FALSE;
> > }
> > //When the main window is created using CW_USEDEFAULT the height of the
> > menubar (if one
> > // is created is not taken into account). So we resize the window after
> > creating it
> > // if a menubar is present
> > {
> > RECT rc;
> > GetWindowRect(hWnd, &rc);
> > rc.bottom -= MENU_HEIGHT;
> > if (g_hwndCB)
> > MoveWindow(hWnd, rc.left, rc.top, rc.right, rc.bottom, FALSE);
> > }
> >
> >
> > ShowWindow(hWnd, nCmdShow);
> > UpdateWindow(hWnd);
> >
> > return TRUE;
> > }
> >
> > LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM
> > lParam)
> > {
> > HDC hdc;
> > int wmId, wmEvent;
> > PAINTSTRUCT ps;
> > TCHAR szHello[MAX_LOADSTRING];
> >
> > switch (message)
> > {
> > case WM_COMMAND:
> > wmId = LOWORD(wParam);
> > wmEvent = HIWORD(wParam);
> >
> > // Parse the menu selections:
> > switch (wmId)
> > {
> > case IDM_HELP_ABOUT:
> >
> > // Once the "ABOUT" field is clicked on in the menu then the
id_sample
> > DialogBox will show up -- calling with Sample()
> > // Create the thread in the Sample CALL BACK routine.
> > DialogBox(g_hInst, (LPCTSTR)id_sample, hWnd, (DLGPROC)Sample);
> >
> > break;
> >
> >
> > case IDOK:
> > SendMessage(hWnd, WM_ACTIVATE, MAKEWPARAM(WA_INACTIVE, 0),
> > (LPARAM)hWnd);
> > SendMessage (hWnd, WM_CLOSE, 0, 0);
> > break;
> > default:
> > return DefWindowProc(hWnd, message, wParam, lParam);
> > }
> > break;
> >
> >
> > case WM_CREATE:
> > g_hwndCB = CreateRpCommandBar(hWnd);
> > // Initialize the shell activate info structure
> > memset (&s_sai, 0, sizeof (s_sai));
> > s_sai.cbSize = sizeof (s_sai);
> > break;
> > case WM_PAINT:
> > RECT rt;
> > hdc = BeginPaint(hWnd, &ps);
> > GetClientRect(hWnd, &rt);
> > LoadString(g_hInst, IDS_HELLO, szHello, MAX_LOADSTRING);
> >
> >
> > DrawText(hdc, szHello, _tcslen(szHello), &rt,
> > DT_SINGLELINE | DT_VCENTER | DT_CENTER);
> > EndPaint(hWnd, &ps);
> > break;
> > case WM_DESTROY:
> > CommandBar_Destroy(g_hwndCB);
> > PostQuitMessage(0);
> > break;
> > case WM_ACTIVATE:
> > // Notify shell of our activate message
> > SHHandleWMActivate(hWnd, wParam, lParam, &s_sai, FALSE);
> > break;
> > case WM_SETTINGCHANGE:
> > SHHandleWMSettingChange(hWnd, wParam, lParam, &s_sai);
> > break;
> > default:
> > return DefWindowProc(hWnd, message, wParam, lParam);
> > }
> > return 0;
> > }
> >
> > HWND CreateRpCommandBar(HWND hwnd)
> > {
> > SHMENUBARINFO mbi;
> >
> > memset(&mbi, 0, sizeof(SHMENUBARINFO));
> > mbi.cbSize = sizeof(SHMENUBARINFO);
> > mbi.hwndParent = hwnd;
> > mbi.nToolBarId = IDM_MENU;
> > mbi.hInstRes = g_hInst;
> > mbi.nBmpId = 0;
> > mbi.cBmpImages = 0;
> >
> > if (!SHCreateMenuBar(&mbi))
> > return NULL;
> >
> > return mbi.hwndMB;
> >
> >
> >
> > }
> >
> > // This is the callback fun citon for my dialogbox. I want to create a
> > thread that will read in serial data and update
> > // the dialogbox!
> >
> > LRESULT CALLBACK Sample(HWND hDlg, UINT message, WPARAM wParam, LPARAM
> > lParam)
> > {
> > SHINITDLGINFO shidi;
> >
> > switch (message)
> > {
> >
> > case WM_INITDIALOG:
> >
> > // Create a Done button and size it.
> > shidi.dwMask = SHIDIM_FLAGS;
> > shidi.dwFlags = SHIDIF_DONEBUTTON | SHIDIF_SIPDOWN |
> > SHIDIF_SIZEDLGFULLSCREEN;
> > shidi.hDlg = hDlg;
> > SHInitDialog(&shidi);
> >
> > // start thread when dialog is first created! Should I be doing it
> > here?
> > // I would like ti have it under WM_COMMAND under the IDOK case but
it
> > didn't seem to be
> > // working properly there
> >
> > serial_threadHDL=
> > CreateThread(NULL,NULL,sample_action,lpParam1,0,lpThreadId);
> >
> > return TRUE;
> >
> > case WM_COMMAND:
> > if (LOWORD(wParam) == IDOK)
> > {
> > return TRUE;
> > }
> >
> > break;
> > }
> > return FALSE;
> > }
> >
> >
> > DWORD sample_action(LPVOID lpParameter)
> > {
> > static int countie = 0;
> >
> >
> > // All I see is this message! I would expect to eventually to see the
> > next
> > message! I never seem to jump into the while() loop!
> >
> > wsprintf(Message,L"Thread for serial data should have started
> > here!",szPortNamie, sizebaby);
> > MessageBox(NULL,Message,L"Triage Wireless",MB_OK);
> >
> > wsprintf(Message,L" hahahahah Thread for serial data should have
started
> > here!",szPortNamie, sizebaby);
> > MessageBox(NULL,Message,L"Triage Wireless",MB_OK);
> >
> >
> >
> >
> > while (1)
> > {
> > // Continuously reading in serial data updating the dialog
> > box
> > and displaying MessageBoxes
> >
> >
> > }
> >
> >
> >
> > }
> >
> >
> >
> >
> >
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.pocketpc,microsoft.public.pocketpc.developer,microsoft.public.windowsce.app.development,microsoft.public.windowsce.embedded (More info?)

I have not read Petzold. My own experience as well as the many other
authors that I have read tell me that an *infinite* loop with no blocking
calls is a bad thing for a couple of reasons.

1. These loops starve the UI threads. The UI thread still runs and gets
quantum, but it will become less responsive.
2. On battery powered devices the battery is drained much quicker.

On a very short lived loop, that is not a problem, but Frank is developing
an infinite loop that has the potential of running for many hours, days,
weeks, months...

My only reason for telling Frank about this is that once he gets his thread
to the point that it enters the while loop, I think that he will be
surprised by the degradation of his UI and will come back to ask about that.
Once he gets his serial code in the loop, then it will probably not be a
problem.

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

Do have an opinion on the effectiveness of Microsoft Windows Mobile and
Embedded newsgroups? Let us know!
https://www.windowsembeddedeval.com/community/newsgroups

"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message
news:SoedncJkLISKxT_cRVn-tw@nildram.net...
> "Bruce Eitman (eMVP)" <beitmannospam@NOSPAM_applieddata.NOSPAM_net> wrote
in
> message news:%23z32o8M0EHA.3452@TK2MSFTNGP14.phx.gbl...
> >
> > Also note, if you ever get to that while loop, your system will become
> > pretty useless since it will constantly run. You should at least put a
> > Sleep() in it.
>
> Really? Many classic Petzold examples use while loops with no sleeps,
> depending on the OS to do the timeslicing...
>
> Steve
> http://www.fivetrees.com
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.pocketpc,microsoft.public.pocketpc.developer,microsoft.public.windowsce.app.development,microsoft.public.windowsce.embedded (More info?)

Paul,

I took out all the MessageBoxes in my thread code and everything works
perfectly! I don't fully understand why the messagebox was causing
problems. My understanding is that:

- Message Box pops up in thread code waiting to hit the OK button. (If I
hit the okay or not still a context switch back to the main thread)

- Context switch back to main thread.

- Context switch back to the worker thread displaying the Message box.
(Either a new MessageBox if I hit okay or the old one if I didn't)

What am I misssing here? :)

-Frank


"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message news:O6T4o0W0EHA.1924@TK2MSFTNGP10.phx.gbl...
> But you are not in the UI thread there. I would not do anything which is
> intended to affect the UI from a thread other than the UI thread; it's bad
> practice. Use the debug message macro or function that I mentioned
instead.
>
> Paul T.
>
> "Frank Vicious" <dontspame@lame.com> wrote in message
> news:eN8J9dO0EHA.3120@TK2MSFTNGP12.phx.gbl...
> > "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
> > wrote
> > ...
> >> Basically, at that point, it's waiting for a window to be created to
> >> display your output and, since that thread has no UI processing
(doesn't
> >> call GetNextEvent(), that window will never be created). Your thread
> > should
> >> *not* do anything that directly requires UI operations...
> >>
> >
> > Paul, thanks for the post. You are saying that when I am calling
> > MessageBox() it is waiting for a window to be created to display the
> > output?
> > The thing is that I do see the first MessageBox in my thread pop up.
> > MessageBox is Modal and does not require a parent window. Correct?
> >
> > If I have in my thread code:
> >
> > while (1)
> > {
> > MessageBox(Blah);
> > }
> >
> > I would expect that each context switch back to this thread would
display
> > another message box.
> >
> > Should I be calling WaitForSingleObject() immediately after I call
> > CreateThread()? .
> >
> > Thanks!
> >
> > -Frankie
> >
> >
> >
> >
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.pocketpc,microsoft.public.pocketpc.developer,microsoft.public.windowsce.app.development,microsoft.public.windowsce.embedded (More info?)

Thanks for the help everyone! The threads are rocking! :)

-Frank
 
G

Guest

Guest
Archived from groups: microsoft.public.pocketpc,microsoft.public.pocketpc.developer,microsoft.public.windowsce.app.development,microsoft.public.windowsce.embedded (More info?)

Is there any chance that the second message box is under the main app?

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

Do have an opinion on the effectiveness of Microsoft Windows Mobile and
Embedded newsgroups? Let us know!
https://www.windowsembeddedeval.com/community/newsgroups

"Frank Vicious" <dontspame@lame.com> wrote in message
news:OgqAfjY0EHA.3744@TK2MSFTNGP10.phx.gbl...
> Paul,
>
> I took out all the MessageBoxes in my thread code and everything works
> perfectly! I don't fully understand why the messagebox was causing
> problems. My understanding is that:
>
> - Message Box pops up in thread code waiting to hit the OK button. (If I
> hit the okay or not still a context switch back to the main thread)
>
> - Context switch back to main thread.
>
> - Context switch back to the worker thread displaying the Message box.
> (Either a new MessageBox if I hit okay or the old one if I didn't)
>
> What am I misssing here? :)
>
> -Frank
>
>
> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
> wrote in message news:O6T4o0W0EHA.1924@TK2MSFTNGP10.phx.gbl...
> > But you are not in the UI thread there. I would not do anything which
is
> > intended to affect the UI from a thread other than the UI thread; it's
bad
> > practice. Use the debug message macro or function that I mentioned
> instead.
> >
> > Paul T.
> >
> > "Frank Vicious" <dontspame@lame.com> wrote in message
> > news:eN8J9dO0EHA.3120@TK2MSFTNGP12.phx.gbl...
> > > "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
com>
> > > wrote
> > > ...
> > >> Basically, at that point, it's waiting for a window to be created to
> > >> display your output and, since that thread has no UI processing
> (doesn't
> > >> call GetNextEvent(), that window will never be created). Your thread
> > > should
> > >> *not* do anything that directly requires UI operations...
> > >>
> > >
> > > Paul, thanks for the post. You are saying that when I am calling
> > > MessageBox() it is waiting for a window to be created to display the
> > > output?
> > > The thing is that I do see the first MessageBox in my thread pop up.
> > > MessageBox is Modal and does not require a parent window. Correct?
> > >
> > > If I have in my thread code:
> > >
> > > while (1)
> > > {
> > > MessageBox(Blah);
> > > }
> > >
> > > I would expect that each context switch back to this thread would
> display
> > > another message box.
> > >
> > > Should I be calling WaitForSingleObject() immediately after I call
> > > CreateThread()? .
> > >
> > > Thanks!
> > >
> > > -Frankie
> > >
> > >
> > >
> > >
> >
> >
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.pocketpc,microsoft.public.pocketpc.developer,microsoft.public.windowsce.app.development,microsoft.public.windowsce.embedded (More info?)

Bruce,

No I have several message boxes all grouped back-to-back in the worker
thread.

-Henk

"Bruce Eitman (eMVP)" <beitmannospam@NOSPAM_applieddata.NOSPAM_net> wrote in
message news:ucM0ZiZ0EHA.392@TK2MSFTNGP12.phx.gbl...
> Is there any chance that the second message box is under the main app?
>
> --
> Bruce Eitman (eMVP)
> Senior Engineer
> beitman AT applieddata DOT net
>
> Applied Data Systems
> www.applieddata.net
> An ISO 9001:2000 Registered Company
> Microsoft WEP Gold-level Member
>
> Do have an opinion on the effectiveness of Microsoft Windows Mobile and
> Embedded newsgroups? Let us know!
> https://www.windowsembeddedeval.com/community/newsgroups
>
> "Frank Vicious" <dontspame@lame.com> wrote in message
> news:OgqAfjY0EHA.3744@TK2MSFTNGP10.phx.gbl...
> > Paul,
> >
> > I took out all the MessageBoxes in my thread code and everything works
> > perfectly! I don't fully understand why the messagebox was causing
> > problems. My understanding is that:
> >
> > - Message Box pops up in thread code waiting to hit the OK button. (If
I
> > hit the okay or not still a context switch back to the main thread)
> >
> > - Context switch back to main thread.
> >
> > - Context switch back to the worker thread displaying the Message box.
> > (Either a new MessageBox if I hit okay or the old one if I didn't)
> >
> > What am I misssing here? :)
> >
> > -Frank
> >
> >
> > "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
> > wrote in message news:O6T4o0W0EHA.1924@TK2MSFTNGP10.phx.gbl...
> > > But you are not in the UI thread there. I would not do anything which
> is
> > > intended to affect the UI from a thread other than the UI thread; it's
> bad
> > > practice. Use the debug message macro or function that I mentioned
> > instead.
> > >
> > > Paul T.
> > >
> > > "Frank Vicious" <dontspame@lame.com> wrote in message
> > > news:eN8J9dO0EHA.3120@TK2MSFTNGP12.phx.gbl...
> > > > "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
> com>
> > > > wrote
> > > > ...
> > > >> Basically, at that point, it's waiting for a window to be created
to
> > > >> display your output and, since that thread has no UI processing
> > (doesn't
> > > >> call GetNextEvent(), that window will never be created). Your
thread
> > > > should
> > > >> *not* do anything that directly requires UI operations...
> > > >>
> > > >
> > > > Paul, thanks for the post. You are saying that when I am calling
> > > > MessageBox() it is waiting for a window to be created to display the
> > > > output?
> > > > The thing is that I do see the first MessageBox in my thread pop up.
> > > > MessageBox is Modal and does not require a parent window. Correct?
> > > >
> > > > If I have in my thread code:
> > > >
> > > > while (1)
> > > > {
> > > > MessageBox(Blah);
> > > > }
> > > >
> > > > I would expect that each context switch back to this thread would
> > display
> > > > another message box.
> > > >
> > > > Should I be calling WaitForSingleObject() immediately after I call
> > > > CreateThread()? .
> > > >
> > > > Thanks!
> > > >
> > > > -Frankie
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.pocketpc,microsoft.public.pocketpc.developer,microsoft.public.windowsce.app.development,microsoft.public.windowsce.embedded (More info?)

"Bruce Eitman (eMVP)" <beitmannospam@NOSPAM_applieddata.NOSPAM_net> wrote in
message news:eiZOcrW0EHA.3972@TK2MSFTNGP12.phx.gbl...
> I have not read Petzold. My own experience as well as the many other
> authors that I have read tell me that an *infinite* loop with no blocking
> calls is a bad thing for a couple of reasons.
>
> 1. These loops starve the UI threads. The UI thread still runs and gets
> quantum, but it will become less responsive.
> 2. On battery powered devices the battery is drained much quicker.

Yep, point taken.

My understanding (via Petzold et al) is that early versions of Windows used
co-operative multitasking, and hence were critically dependent on each
thread/task relinquishing control. In that context, your advice (to sleep)
is not just sound, but essential.

However more modern versions (from Win32, IIRC) use proper pre-emptive
multitasking, so this is less of an issue. I've seen quite a few comms
threads (including the Petzold examples) which are basically infinite loops
(exiting on program close-down) that check for comms reception, and do
something with received data, with no obvious co-operation/ceding to the OS.

FWIW, my own take on this is a bit of both: if there are no comms characters
in the buffer, I sleep. Given the low speed of serial comms, there's not too
much point in checking the buffer too frequently.

Steve
http://www.fivetrees.com
 
G

Guest

Guest
Archived from groups: microsoft.public.pocketpc,microsoft.public.pocketpc.developer,microsoft.public.windowsce.app.development,microsoft.public.windowsce.embedded (More info?)

Hi Frank,

I would say it is not only possible but likely as the dialogs are not
parented at all. Try adding the MB_TOPMOST flag.

Cheers

Doug Forster

"Frank Vicious" <dontspame@lame.com> wrote in message
news:%23Mn4kRb0EHA.1256@TK2MSFTNGP10.phx.gbl...
> Bruce,
>
> No I have several message boxes all grouped back-to-back in the worker
> thread.
>
> -Henk
>
> "Bruce Eitman (eMVP)" <beitmannospam@NOSPAM_applieddata.NOSPAM_net> wrote
> in
> message news:ucM0ZiZ0EHA.392@TK2MSFTNGP12.phx.gbl...
>> Is there any chance that the second message box is under the main app?
>>
>> --
>> Bruce Eitman (eMVP)
>> Senior Engineer
>> beitman AT applieddata DOT net
>>
>> Applied Data Systems
>> www.applieddata.net
>> An ISO 9001:2000 Registered Company
>> Microsoft WEP Gold-level Member
>>
>> Do have an opinion on the effectiveness of Microsoft Windows Mobile and
>> Embedded newsgroups? Let us know!
>> https://www.windowsembeddedeval.com/community/newsgroups
>>
>> "Frank Vicious" <dontspame@lame.com> wrote in message
>> news:OgqAfjY0EHA.3744@TK2MSFTNGP10.phx.gbl...
>> > Paul,
>> >
>> > I took out all the MessageBoxes in my thread code and everything works
>> > perfectly! I don't fully understand why the messagebox was causing
>> > problems. My understanding is that:
>> >
>> > - Message Box pops up in thread code waiting to hit the OK button.
>> > (If
> I
>> > hit the okay or not still a context switch back to the main thread)
>> >
>> > - Context switch back to main thread.
>> >
>> > - Context switch back to the worker thread displaying the Message box.
>> > (Either a new MessageBox if I hit okay or the old one if I didn't)
>> >
>> > What am I misssing here? :)
>> >
>> > -Frank
>> >
>> >
>> > "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
>> > com>
>> > wrote in message news:O6T4o0W0EHA.1924@TK2MSFTNGP10.phx.gbl...
>> > > But you are not in the UI thread there. I would not do anything
>> > > which
>> is
>> > > intended to affect the UI from a thread other than the UI thread;
>> > > it's
>> bad
>> > > practice. Use the debug message macro or function that I mentioned
>> > instead.
>> > >
>> > > Paul T.
>> > >
>> > > "Frank Vicious" <dontspame@lame.com> wrote in message
>> > > news:eN8J9dO0EHA.3120@TK2MSFTNGP12.phx.gbl...
>> > > > "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
>> com>
>> > > > wrote
>> > > > ...
>> > > >> Basically, at that point, it's waiting for a window to be created
> to
>> > > >> display your output and, since that thread has no UI processing
>> > (doesn't
>> > > >> call GetNextEvent(), that window will never be created). Your
> thread
>> > > > should
>> > > >> *not* do anything that directly requires UI operations...
>> > > >>
>> > > >
>> > > > Paul, thanks for the post. You are saying that when I am calling
>> > > > MessageBox() it is waiting for a window to be created to display
>> > > > the
>> > > > output?
>> > > > The thing is that I do see the first MessageBox in my thread pop
>> > > > up.
>> > > > MessageBox is Modal and does not require a parent window. Correct?
>> > > >
>> > > > If I have in my thread code:
>> > > >
>> > > > while (1)
>> > > > {
>> > > > MessageBox(Blah);
>> > > > }
>> > > >
>> > > > I would expect that each context switch back to this thread would
>> > display
>> > > > another message box.
>> > > >
>> > > > Should I be calling WaitForSingleObject() immediately after I call
>> > > > CreateThread()? .
>> > > >
>> > > > Thanks!
>> > > >
>> > > > -Frankie
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>