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.
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.
I'm hitting a snag as I try to read back an array which has been written to a text file. Here's the relevant part of the code:
printf("Unable to open file.\n");
This is generating an error: [Warning] comparison between pointer and integer.
Though it runs, it is revealing that the break code which checks for a comma is not functioning as the compiler warns. Why is it claiming this is a pointer? Why is it saying anything about an integer when I've deliberately cast k as a character?
Thanks for any input. ------
Update: The problem was solved by: (a) changing the double quotes to single quotes (apostrophes) and (b) switching
below the assignment. In order to match the file derived string with one defined in code I also had to modify it:
as there is something foreign added in the file transfer process. Thanks, and if there is a mark as solved button I couldn't find it
Thanks Richard, I'm going to try to track down the errors in this code first and then experiment with this tokenizer. At this point I'm trying to get a really granular understanding of C which even means reinventing the wheel at times, just for my own edification
Using interrupts is something you do when your program needs to interact with hardware components that trigger these interrupts. Software can trigger only one type of interrupt, and that is by setting a timer. Your problem is not timed, it is controlled by demand, so setting a timer does not fit that problem. using a timer in this situation is like telling a home owner that instead of reacting to the door bell, he should rather check the door every 5 minutes.
I suggest you fire up your preferred search engine and search for the keywords "master slave pattern". This should provide you with lots of interesting links.
The master slave pattern is extensively used for organizing the parallelization of complex tasks. Each slave works (potentially) on its own thread, allowing it to work in parallel with its coworkers. That means telling a slave to work requires sending a message to a different thread or process. Since inter-process communication is rather slow, you should prefer the former.
In most cases it is not necessary for the slaves to live beyond the scope of their tasks. Therefore, the easiest way is to create a new thread for each slave, whenever you need one. The problem you describe assumes a fixed number of slaves however, implying that these slaves' livetimes are not linked to the tasks they work on.
In that case you need a messaging system that allows the supervisor to inform the slaves if and when they are needed, and the slaves to inform the master after they're done. The windows messaging system - as suggested above - should work well for that purpose.
The disadvantage of messages is that the master needs to keep track which of his slaves are busy. Also he'll need to queue the tasks if all slaves are busy, until one becomes available.
Since you need the ability to queue your tasks anyway, a better solution would be to just push your tasks there, always, and let your slaves pick up work items from there whenever they're idle. That way the master doesn't need to know if or who is available for work. He wouldn't even need to be informed every time a slave is done with his work item; instead, the queue could notify him when it is empty, i. e. the entire workload completed.
The only reason not to do that would be if your slaves are specialized to different tasks, but not able to decide for themselves which these are. (e. g. this may happen when the data associated with the tasks come in different formats that the slaves cannot interpret)