MFC executing thread problems - c++

I have a CDialog that allow users to navigate, listing and showing files preview in the hard disk. In some cases there might be a lot of heavy files and these cases require a lot of time, so we moved the loading operations in a separate thread.
Now, I expect that moving disk accesses in a separate thread would have let me to use the CDialog normally, but this does not happen so I can't scroll or move the window.
Am I missing something in the process? Here's the code:
void CMyDialog::LoadFiles()
{
// …
std::thread load_file(LoadingRoutine, reinterpret_cast<void *>(&data));
load_file.detach();
// same happens if I use Afx functions
// AfxBeginThread(&CMyDialog::LoadingRoutine, reinterpret_cast<void *>(&data));
// …
}

Problem partially fixed: it seems that using threads prevents the window to consume messages regularly even if it's a non-blocking call.
My workaround consisted in giving the control back to window to let it to consume messages:
// … thread stuff
for (auto nI = 0; nI < nCount; nI++)
{
// Heavy computing
nSleepStep = 5;
nSleepTime = 200;
while (nSleepTime > nSleepStep)
{
while(PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE))
{
switch( msg.message )
{
case WM_TIMER :
case WM_PAINT :
TranslateMessage( &msg );
DispatchMessage( &msg );
break;
}
}
std::this_thread::sleep_for(std::chrono::milliseconds(nSleepStep));
nSleepTime -= nSleepStep;
}
}

The correct way is to use AfxBeginThread or std::thread::detach. You will be able to use the dialog in the main UI thread normally.
Alternatively you can do this in a single thread, assuming your function can be interrupted and broken in to different parts. For example, lets say you have function that takes 3 seconds to complete:
Sleep(3000);
It can be broken in to 30 parts and simulated as
for (int i = 0; i < 30; i++)
Sleep(100);
You can update paint after each move. Note that other dialog messages must be ignored, because this is a single thread and you can only do one thing at a time. You should disable the controls to let the user know the dialog is busy. Example:
void update_paint()
{
MSG msg;
while(PeekMessage(&msg, m_hWnd, 0, 0, PM_REMOVE))
{
if(msg.message == WM_COMMAND && msg.wParam == IDCANCEL) { }//cancel reuested
if(msg.message == WM_PAINT ||
(msg.message >= WM_NCCALCSIZE && msg.message <= WM_NCACTIVATE) ||
(msg.message >= WM_NCMOUSEMOVE && msg.message <= WM_NCMBUTTONDBLCLK))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
}
void CMyDialog::single_thread()
{
MessageBox(L"start");
//disable child controls to let user know the dialog is busy
for(CWnd *p = GetWindow(GW_CHILD); p; p = p->GetWindow(GW_HWNDNEXT))
p->EnableWindow(FALSE);
for(int i = 0; i < 30; i++)
{
Sleep(100);
update_paint();
}
//enable child controls
for(CWnd *p = GetWindow(GW_CHILD); p; p = p->GetWindow(GW_HWNDNEXT))
p->EnableWindow(TRUE);
MessageBox(L"done");
}
If the function cannot be interrupted then launching a second thread is necessary.

Related

Is it safe to manually handle custom message sent from another thread

I'm trying to post message from one thread to a window in another thread via PostThreadMessage:
auto result = PostThreadMessage(mainThreadId, UserMessage::DestroyWindowRequest, 0, 0);
The MSDN says that
Messages sent by PostThreadMessage are not associated with a window. As a general rule, messages that are not associated with a window cannot be dispatched by the DispatchMessage function.
So I cann't just receive my message. Is it safe to handle a message manually in a message loop as in code below?
INT_PTR AbstractWindow::TranslateMessageLoop()
{
MSG msg{0};
BOOL gotMessage = FALSE;
static const BOOL hasError = -1;
PostMessage(windowHandle, UserMessage::MessageLoopTranslated, 0, 0);
while ((gotMessage = GetMessage(&msg, (HWND)NULL, 0, 0)) != 0 && gotMessage != hasError) {
// Here I process a message. I assume that the message is always destined for my main window,
// so I use it's handle - windowHandle.
if (!msg.hwnd && msg.message == UserMessage::DestroyWindowRequest) {
DestroyWindow(windowHandle);
}
else {
if (PreTranslateMessage(&msg) == FALSE) {
if (IsDialogMessage(windowHandle, &msg) == FALSE) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
}
}
return msg.wParam;
}
I know, MSDN suggest to use custom hooks, but it's a little bit overkill for me now.

COM+ app not continuing until some unknown condition

I have a COM+ application which I instantiate with
CoCreateInstance(CLSID_TheComponent, NULL, CLSCTX_ALL, IID_ITheComponent, &m_TheComponent);
This is followed by event initialization
CoCreateInstance(CLSID_TransientSubscription,NULL,CLSCTX_ALL,IID_ITransinetSubscription,&Trans);
...some more code that eventually registers some CLSID_Events, IID__IEvents.
I have an MFC application with following:
OnBtn1Clicked()
{
m_TheComponent->DoSomething();
}
also in the Dialog class there is
class CMFCMyDialog : public CDialogEx, _IEvents
{
...
virtual HRESULT STDMETHODCALLTYPE OnSomething(); // abstract in _IEvents
When running, after clicking Btn1 two things happen: 1.OnSomething() is fired, and 2. the COM+ does a bunch of other stuff it should do. So far so good.
The interesting thing is that 1 & 2 happen only after OnBtn1Clicked() is exited. Even if i put a sleep() after DoSomething() or if I attempt to call DoSomething() within a different thread, 1 + 2 don't happen only after OnBtn1Clicked() is cleared.
From The COM component log I see it reaches and enters it's OnSomething() call but does not exist it (and of course does not reach the client side sink) until OnBtn1Clicked() is cleared. Once cleared, the sink is reached and the COM component continues execution.
All this would not be a problem since I can wait for after the button is clicked, but I need to implement this in a console application client. When implementing in a console application I was not able to make 1 and/or 2 happen. Only after I kill the client process (!) 2 happens (the COM+ continues processing) but of course client side OnSomething() does not since the process is dead.
Any idea what happens when OnBtn1Clicked() is cleared that affects the COM+?
MyConsoleClass::MyConsoleClass()
{
new thread(&MyConsoleClass::Run, this);
}
void MyConsoleClass::Run()
{
m_ThreadId = GetCurrentThreadId();
m_IsActive = true;
MSG msg;
BOOL bRet;
while (m_IsActive)
{
if (bRet = GetMessage(&msg, NULL, 0, 0) != 0)
{
if (bRet == -1)
// error
else if (msg.message == WM_QUIT)
m_IsActive = false;
else if (msg.message == DO_SOMETHING)
DoSomething(msg.wParam);
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
}
}
void MyConsoleClass::Invoke(const actionEnum action, const void *params)
{
PostThreadMessage(m_ThreadId, action, (WPARAM)params, NULL);
}

Why application can be marked as "not responding" even if it pump messages?

Why application can be marked as "not responding" even if it pump messages?
Message loop looks like this:
bool bLoop = true;
while (bLoop)
{
int iMsgCount = 0;
MSG msg;
while ( PeekMessage(&msg, NULL, 0U, 0U, PM_REMOVE) )
{
iMsgCount++;
if(msg.message == WM_QUIT)
{
bLoop = false;
break;
{
AppPreprocessIME(msg);
TranslateMessage(&msg);
DispatchMessage(&msg);
}
Log( "Message loop (messages) %d ", iMsgCount );
Log( "ThreadId %d", GetCurrentThreadId() );
if(!bLoop)
break;
// Update/DirectX draw/etc.
}
Loop goes fine (it writes log messages), but Windows still marks it as "not responding".
Is there any other check windows do to make such decision? Or something else can lead to this behavior?
Also, window become responsive if debugger attached (started from debugger or attached during "not responding" state). I guess that debugger hooks something or alter message queue processing.

Translating WM_MOUSEWHEEL Delphi code to C++ Builder

I have these links with code:
WMMouseWheel not working in Delphi
How to disable MouseWheel if mouse is not over VirtualTreeView (TVirtualStringTree)
Translated it to C++ Builder but it doesn't work:
UPDATE: After narrowing the problem down it appears that WM_MOUSEWHEEL messages don't work over unfocused TVirtualStringTree control only, they work over other controls. When focus is on e.g. TMemo control, other TMemo control scrolls on wheel but not TVirtualStringTree control. When focus is on TVirtualStringTree it scrolls TVirtualStringTree but not other controls. So the problem is now specific to TVirtualStringTree only.
void __fastcall TForm1::ApplicationEventsMessage(tagMSG &Msg, bool &Handled)
{
TPoint Pt;
HWND Wnd;
if (Msg.message == WM_MOUSEWHEEL ||
Msg.message == WM_VSCROLL ||
Msg.message == WM_HSCROLL)
{
if (GetCursorPos(&Pt))
{
Wnd = WindowFromPoint(Pt);
// It must be a VCL control otherwise we could get access violations
if (IsWindowEnabled(Wnd) && FindControl(Wnd) != NULL)
{
Msg.hwnd = Wnd; // change the message receiver to the control under the cursor
}
}
}
}
Different version of the similar code, also doesn't work:
TPoint pnt;
TWinControl *ctrl;
if ((Msg.message == WM_MOUSEWHEEL ||
Msg.message == WM_VSCROLL ||
Msg.message == WM_HSCROLL) &&
GetCursorPos(&pnt))
{
ctrl = FindVCLWindow(pnt);
if (ctrl != NULL)
{
SendMessage(ctrl->Handle, Msg.message, Msg.wParam, Msg.lParam); // No effect
// SendMessage(ctrl->Handle, WM_VSCROLL, 1, 0); // This is the only thing that actually moves scrollbars but this is not exactly the same message like above
// Msg.hwnd = ctrl->Handle; // No effect
this->Caption=ctrl->Name; // This shows correct control name so the message IS GETTING THROUGH!
Handled = true;
}
}
It should work but it doesn't. Tried other code as well. No effect - mouse wheel does not operate on unfocused control. As you can see, I checked for all 3 variants of wheel messages, it gets correct control under the mouse, it shows that control name but the control doesn't receive wheel messages.
Any ideas what piece of the puzzle am I missing to get it to work?
As nobody offered any proper solution, I am posting my own. The solution is not perfect but at least it does what it needs to do - mouse wheel scrolls all controls under it, including the VirtualTreeView controls. The code in solution is in C++ but Delphi version is very similar (it only needs to be translated).
My current solution is to grab WM_MOUSEWHEEL events and translate them into WM_VSCROLL or WM_HSCROLL to which VirtualTreeView reacts and scrolls the content. Additionally, it needs to take into account high-precision mouse wheels which can have smaller value than WHEEL_DELTA (which is set to 120). Finally, it needs to take into account user setting for number of lines to scroll (set in Control Panel in Windows). So here goes:
Put a TApplicationEvents to a form and in the OnMessage event do this:
void __fastcall TFormMain::ApplicationEventsMessage(tagMSG &Msg, bool &Handled)
{
// Check these 3 messages because some mouse drivers may use VSCROLL instead of MOUSESWHEEL message
if (Msg.message == WM_MOUSEWHEEL || Msg.message == WM_VSCROLL || Msg.message == WM_HSCROLL)
{
TPoint pnt;
TWinControl *ctrl;
if (!GetCursorPos(&pnt)) return;
ctrl = FindVCLWindow(pnt);
if (ctrl != NULL)
{
// ToDo: implement if user needs wheel-click - then we also need KEYSTATE but for this example it is not needed
// int fwKeys = GET_KEYSTATE_WPARAM(Msg.wParam);
int zDelta = GET_WHEEL_DELTA_WPARAM(Msg.wParam),
pvParam = 3; // Windows default value
unsigned MyMsg = WM_VSCROLL;
// ToDo: extract SystemParametersInfo somewhere else so it is not extracted for each WM_MOUSEWHEEL message which may not be needed
switch (Msg.message)
{
// This will translate WM_MOUSEWHEEL into WM_VSCROLL
case WM_MOUSEWHEEL:
case WM_VSCROLL:
// Windows setting which determines how many lines to scroll - we'll send that many WM_VSCROLL or WM_HSCROLL messages
SystemParametersInfo(SPI_GETWHEELSCROLLLINES, 0, &pvParam, 0);
MyMsg = WM_VSCROLL;
break;
case WM_HSCROLL:
// Same as above but for WM_HSCROLL (horizontal wheel)
SystemParametersInfo(SPI_GETWHEELSCROLLCHARS, 0, &pvParam, 0);
MyMsg = WM_HSCROLL;
break;
}
// This calculation takes into account high-precision wheels with delta smaller than 120
// Possible TODO: Round up values smaller than 1 (e.g. 0.75 * pvParam) if pvParam is 1
int ScrollBy = ((double)zDelta / (double)WHEEL_DELTA) * pvParam;
// Send multiple messages based on how much the zDelta value was
if (zDelta > 0)
{
do
{
SendMessage(ctrl->Handle, MyMsg, SB_LINEUP, 0);
}
while (--ScrollBy > 0);
}
else
{
do
{
SendMessage(ctrl->Handle, MyMsg, SB_LINEDOWN, 0);
}
while (++ScrollBy < 0);
}
Handled = true;
}
}
}

C++/Win32 enumerate windows belonging to my process & close them

I have a Windows app that houses a web browser (Internet explorer) embedded in it. The app can be closed from another process by means of IPC. It works just fine except the situation when the embedded web browser may be displaying a pop-up dialog window (say, during saving of contents). In that case my app crashes when it tries to close from an outside request via IPC. (Internally it simply posts the WM_CLOSE message to itself.)
In light of that I thought to come up with a way to enumerate all windows that belong to my process and close them first before closing my process itself. The question is, how do you enumerate all windows belonging to my process for the purpose of closing them?
OK, I guess I got it myself. Here's if someone is interested:
#define SIZEOF(f) (sizeof(f) / sizeof(f[0]))
typedef struct _ENUM_POPUPS_INFO{
DWORD dwProcID;
HWND hThisWnd;
int nNextHWNDIndex;
HWND hFoundHWNDs[256];
}ENUM_POPUPS_INFO;
void CloseAllOpenPopups(HWND hWnd, int dwmsWait)
{
//'hWnd' = our main window handle (we won't close it)
//'dwmsWait' = maximum wait time in milliseconds, or -1 to wait for as long as needed
ENUM_POPUPS_INFO epi = {0};
BOOL bR;
int i, iIteration;
HWND hWndRoot, hWndActivePopup;
DWORD dwmsTickBegin = GetTickCount();
for(iIteration = 0;; iIteration = 1)
{
//Get our process ID
memset(&epi, 0, sizeof(epi));
epi.hThisWnd = hWnd;
epi.dwProcID = GetCurrentProcessId();
bR = EnumWindows(EnumPopupWindowsProc, (LPARAM)&epi);
//Did we get any
if(epi.nNextHWNDIndex == 0)
break;
//Wait on a second and later iteration
if(iIteration > 0)
{
if(dwmsWait != -1)
{
DWORD dwmsTick = GetTickCount();
int nmsDiff = abs((long)(dwmsTick - dwmsTickBegin));
if(nmsDiff >= dwmsWait)
{
//Timed out
break;
}
//Wait
Sleep(min(100, dwmsWait - nmsDiff));
}
else
{
//Wait
Sleep(100);
}
}
//Go through all windows found
for(i = 0; i < epi.nNextHWNDIndex; i++)
{
//Get root owner
hWndRoot = GetAncestor(epi.hFoundHWNDs[i], GA_ROOTOWNER);
if(!hWndRoot)
continue;
//Get it's active popup
hWndActivePopup = GetLastActivePopup(hWndRoot);
if(!hWndActivePopup)
continue;
//Close it
PostMessage(hWndActivePopup, WM_CLOSE, 0, 0);
}
}
}
BOOL CALLBACK EnumPopupWindowsProc(HWND hWnd, LPARAM lParam)
{
ENUM_POPUPS_INFO* pEPI = (ENUM_POPUPS_INFO*)lParam;
//Get process ID of the window
DWORD dwProcID = 0;
GetWindowThreadProcessId(hWnd, &dwProcID);
//We need this window only if it's our process
if(dwProcID == pEPI->dwProcID &&
pEPI->hThisWnd != hWnd &&
((GetWindowLongPtr(hWnd, GWL_STYLE) & (WS_VISIBLE | WS_POPUP | WS_CAPTION)) == (WS_VISIBLE | WS_POPUP | WS_CAPTION)))
{
if(pEPI->nNextHWNDIndex >= SIZEOF(pEPI->hFoundHWNDs))
{
//Stop, we're full
return FALSE;
}
//Add it
pEPI->hFoundHWNDs[pEPI->nNextHWNDIndex] = hWnd;
pEPI->nNextHWNDIndex++;
}
return TRUE;
}
When you want your process to exit, just call ExitProcess. It doesn't matter what windows might be open at the time, they all go away.