Those are not exceptions, they are linker messages, telling you that you have some missing library references. The first two are references to the MSXML[^] library. If you do not have it installed then you need to download it using the foregoing link. The remaining three suggest that you don't have a WinMain()[^] function in your code. However, it may well be that the code is incomplete, and you should check with the person who wrote it.
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
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.
Last Visit: 31-Dec-99 18:00 Last Update: 31-Aug-15 11:15