From: Vertilka on
TNX for the answer, I used your advice as follow and it works:

#include "stdafx.h"
#include "TestGUI.h"

DWORD WINAPI ModelessThreadFunc(LPVOID)
{
TestGUI gui;
gui.Create(TestGUI::IDD);
gui.ShowWindow(SW_SHOW);

HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE, L"CloseModelessDialog");

MSG msg;
while(WaitForSingleObject(hEvent, 0) != WAIT_OBJECT_0)
{
while(::GetMessage(&msg, NULL, 0, 0))
{
::TranslateMessage(&msg);
::DispatchMessage(&msg);
}
}

// event cleanup
CloseHandle(hEvent);

return 0;
}

void main()
{
// initialize MFC
AfxWinInit(GetModuleHandle(NULL), NULL, GetCommandLine(), SW_SHOW);

// create thread for the modeless dialog
CreateThread(NULL, 0, ModelessThreadFunc, NULL, 0, NULL);

// wait for the modeless dialog to close itself
HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE, L"CloseModelessDialog");
while(WaitForSingleObject(hEvent, 0) != WAIT_OBJECT_0)
{
// do other job
}

// event cleanup
CloseHandle(hEvent);
}

From: Hector Santos on
Very Cool, thanks for the feedback.

--
HLS

Vertilka wrote:

> TNX for the answer, I used your advice as follow and it works:
>
> #include "stdafx.h"
> #include "TestGUI.h"
>
> DWORD WINAPI ModelessThreadFunc(LPVOID)
> {
> TestGUI gui;
> gui.Create(TestGUI::IDD);
> gui.ShowWindow(SW_SHOW);
>
> HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE, L"CloseModelessDialog");
>
> MSG msg;
> while(WaitForSingleObject(hEvent, 0) != WAIT_OBJECT_0)
> {
> while(::GetMessage(&msg, NULL, 0, 0))
> {
> ::TranslateMessage(&msg);
> ::DispatchMessage(&msg);
> }
> }
>
> // event cleanup
> CloseHandle(hEvent);
>
> return 0;
> }
>
> void main()
> {
> // initialize MFC
> AfxWinInit(GetModuleHandle(NULL), NULL, GetCommandLine(), SW_SHOW);
>
> // create thread for the modeless dialog
> CreateThread(NULL, 0, ModelessThreadFunc, NULL, 0, NULL);
>
> // wait for the modeless dialog to close itself
> HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE, L"CloseModelessDialog");
> while(WaitForSingleObject(hEvent, 0) != WAIT_OBJECT_0)
> {
> // do other job
> }
>
> // event cleanup
> CloseHandle(hEvent);
> }
>

From: Joseph M. Newcomer on
So why not build a dialog-based app, and eliminate the need for a console app?

It won't make any difference, because Windows is not a real-time system, and if it gives
the illusion of being so, that's just good luck, nothing more. A Windows app vs. a
console app will not change anything.
joe

On Sun, 28 Mar 2010 01:11:03 -0700, Vertilka <Vertilka(a)discussions.microsoft.com> wrote:

>
>Well,
>This is a realtime software, it works againt an hardware.
>There is a special mode where you can debug the hardware. a GUI is a good
>way to interact with the user, in contrary to using a command line.
>Developing the GUI is easy with .NET but the marsheling is a quite an
>overhead, thats why i tried MFC.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Doug Harrison [MVP] on
On Sat, 27 Mar 2010 20:54:01 -0400, Hector Santos
<sant9442(a)nospam.gmail.com> wrote:

>So in the LOOP I provided, it will change to to this:
>
> hExitEvent = CreateEvent(0, TRUE, FALSE, 0);
> SetConsoleCtrlHandler((PHANDLER_ROUTINE)&ConsoleHandler,TRUE);
>
> _cprint("* Press ESC to exit\n");
> while (WaitForSingleObject(hExitEvent,100) != WAIT_OBJECT_0) {
> if (_kbhit() && _getch() == 27) break;
> MSG msg;
> while (::PeekMessage(&msg,NULL,0,0,PM_REMOVE)){
> ::TranslateMessage(&msg);
> ::DispatchMessage(&msg);
> }
> }
>
>Now you don't need the Sleep(75) because call to:
>
> WaitForSingleObject(hExitEvent,100)
>
>is the most *efficient* form of synchronization and waiting for events
>to occur in Windows!

That pauses your thread by 100 msec each time around the loop when the
event isn't signaled, which is almost all the time. You can avoid polling
altogether by using MsgWaitForMultipleObjects. For an example, see my web
page:

http://members.cox.net/doug_web/threads.htm#Q6

Also, I'd look for WM_KEYDOWN instead of using _kbhit. Consider what
happens if ESC comes in between _kbhit and PeekMessage.

--
Doug Harrison
Visual C++ MVP
From: Hector Santos on

Yes, that is pretty high. I pulled pieces of code for the
illustration from multiple sources. I'm sure the OP or anyone doing
this would adjust it. And yes if you are going to with for multiple
events to be signaled, using a multi object wait function is ideal.

--
HLS


Doug Harrison [MVP] wrote:

> On Sat, 27 Mar 2010 20:54:01 -0400, Hector Santos
> <sant9442(a)nospam.gmail.com> wrote:
>
>> So in the LOOP I provided, it will change to to this:
>>
>> hExitEvent = CreateEvent(0, TRUE, FALSE, 0);
>> SetConsoleCtrlHandler((PHANDLER_ROUTINE)&ConsoleHandler,TRUE);
>>
>> _cprint("* Press ESC to exit\n");
>> while (WaitForSingleObject(hExitEvent,100) != WAIT_OBJECT_0) {
>> if (_kbhit() && _getch() == 27) break;
>> MSG msg;
>> while (::PeekMessage(&msg,NULL,0,0,PM_REMOVE)){
>> ::TranslateMessage(&msg);
>> ::DispatchMessage(&msg);
>> }
>> }
>>
>> Now you don't need the Sleep(75) because call to:
>>
>> WaitForSingleObject(hExitEvent,100)
>>
>> is the most *efficient* form of synchronization and waiting for events
>> to occur in Windows!
>
> That pauses your thread by 100 msec each time around the loop when the
> event isn't signaled, which is almost all the time. You can avoid polling
> altogether by using MsgWaitForMultipleObjects. For an example, see my web
> page:
>
> http://members.cox.net/doug_web/threads.htm#Q6
>
> Also, I'd look for WM_KEYDOWN instead of using _kbhit. Consider what
> happens if ESC comes in between _kbhit and PeekMessage.