• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2454
  • Last Modified:


   I need to write an MFC Dialog that communicates with a delphi program. The delphi program is the master which will call up this MFC dialog and communicate with it via windows messages. The delphi program and the MFC dialog must run in parallel.

I wrote the MFC Dialog as an MFC regular DLL. The dialog is created at the initinstance of the winApp in the MFC DLL.
However, the MFC Dialog does not seem to have its own message queue becoz it is not refreshed. What is the correct way to do this?


3 Solutions
Is it a modal or modeless dialog box? Modal dialog requires a valid parent window to be modal. Check out

How to Create a Modal Dialog from Within a USRDLL
pcssecureAuthor Commented:
Modeless. Modal is not applicable because if the Dialog is modal, the master delphi program will not be able to continue until the user clicks on the OK button.
What do you mean by "it is not refreshed"? Do you send some 'refreshing' messages to the dialog and it doesn't react?
Train for your Pen Testing Engineer Certification

Enroll today in this bundle of courses to gain experience in the logistics of pen testing, Linux fundamentals, vulnerability assessments, detecting live systems, and more! This series, valued at $3,000, is free for Premium members, Team Accounts, and Qualified Experts.

pcssecureAuthor Commented:
Let me rephrase the question.

I need to do some number crunching in a win32 console program and update a dialog as the number crunching progresses. Also, I want to write the modeless CDialog as a MFC regular DLL. How can I achieve this?

Do I need to create a separate thread for the message pump of the MFC DLL?
As it is now, when I add a message pump (while loop) to the winApp class, it seem to be taking up all the processing time and I am not able to return to the number crunching program to do my data processing.

How do I make the MFC DLL's message pump run on a separate thread?

Please advise.

>Do I need to create a separate thread for the message pump of the MFC DLL?
Have your own class derived from CWinThread and have a class derived from CFrameWnd. Associate your CFramewnd derived class with your modelless dialog. And in the initinstance of CWinThread derived class call show dialog. Add required message handlers to your CWinThread derived class.
Please refer to the following links for more info

>Do I need to create a separate thread for the message pump of the MFC DLL?

No. Why do you think it is a message pump problem? What exactly is the problem? Please respond to nonubik's question.
pcssecureAuthor Commented:
Thanks for all the help.

Lakshman: Do I still need to do all that if I am already wusing CWinApp? As far as i know, CWinApp is derived from CWinThread.

ChenSu: I think (though I am not sure) it is a message pump problem because i read from MSDN that for a modeless dialog in a MFC regular DLL, the message pump is owned by the application calling it.

The paragraph below is from MSDN TN011.
"Note that the CWinApp::Run mechanism doesn't apply to a DLL, since the application owns the main message pump. If your DLL brings up modeless dialogs or has a main frame window of its own, your application's main message pump must call a DLL-exported routine that calls CWinApp::PreTranslateMessage."

In my case, the win32 console program calling the MFC Dialog in the regular DLL does not have any message pump. What do I do?

Now I understand what you are doing. I answered a similar question.


Check out

ConGui: Sample for Console I/O with GUI I/O

"The ConGui sample demonstrates how a standard console application can take advantage of some of the graphical capabilities of Windows NT.

Caution   This sample application illustrates a method by which a console application can utilize some (but not all) of the graphical user interface (GUI) capabilities of the Win32 API. It was not the original design intention of the Console layer of Windows NT to allow it to interact in this manner with the graphical API, and because of this, problems can occur if you try to accomplish too much. Therefore, exercise restraint in using the graphical Win32 API in your console application. If your needs go beyond the simple methods illustrated here, consider designing your application as a full GUI application."
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now