Hope you mean MFC. I think first yo should understand what is MFC. Because it is wast library that wraps portions of the Windows API in C++ classes. When studying we must start from it's basic. If we got a good basic knowledge then we can develop anything through a programming language. So stduy well, understand well.
All the best.
As the title says I am trying to host a .net modeless form inside an MFC dialog. I read the article Using WinForms controls in an MFC dialog[^] but I do not want to do it this was because I do not wish to compile the project that contains the MFC dialog in /clr.
So I tried a different path.
I created a /clr dll that exports a very simple function
The hosted form is a .net form without borders. So my dialog takes the handler(by calling the dll, no need to show the implementation here) and places the form in a STATIC control window.
m_pDotNetWnd = CWnd::FromHandle(getDotNetWindowHandler());
CWnd* pWndContainer = GetDlgItem(IDC_DOTNET_WND);
if(m_pDotNetWnd != NULL && pWndContainer != NULL)
m_pDotNetWnd->SetWindowPos(NULL, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOZORDER | SWP_ASYNCWINDOWPOS | SWP_FRAMECHANGED);
HWND hWndChild = m_pDotNetWnd->GetSafeHwnd();
// reset the style
DWORD style = GetWindowLong(hWndChild, GWL_STYLE);
style &= ~(WS_POPUP|WS_CAPTION); //reset the "caption" and "popup" bits
style |= WS_CHILD; //set the "child" bit
SetWindowLongPtr(hWndChild, GWL_STYLE, style); //set the new style
Everything seems to work just fine but after a while I am having a deadlock. The window freezes.
After a lot of research on the internet it seems to be a problem with the SendMessage when the child window is created from a different thread. I couldn't find any workarround though. Is there any? Can someone give me a clue?
As far as I recall from my MFC days, a Window's OnDraw() procedure will get called when the dialog closes, so this should happen automatically. Unfortunately that's the part of the code that you did not show us. You may like to add some breakpoints and use your debugger to see the flow of code when the dialog closes.
I debug the whole code by putting breakpoints in all the functions, after closing the dialog, its not going anywhere in the code, remains on the application itself.
I am attaching the code herewith. Please download and check.
I never quite placed much attention as to how threads are labeled in the debug display but... does it really matter? A UI thread is really just a label for a thread, it differs only in the extra functionality that comes from the framework around it, so does the label really make a difference? If it works fine why are you worried about the label the debugger is using?
Why are you using CStrings for your data buffers, and why are you trying to convert the file content with wcstombs()? Use the BYTE (unsigned char) type for your data buffer, and read the files in binary mode.
I already told you how to do it. Do not use CString it will not work. And do not convert the file contents, it will leave you with corrupt data. A file is just a stream of bytes and in moving it from one location to another you should process it as such.