Proper Usage of the MFC Framework

Hi All,

This is my first post on these forums and despite working as a software engineer, I have a background in Embedded Programming so Application development is extremely new to me. I would like to know if I am approaching a project of mine properly.

My project is to create a GUI dialog that is initialized from a function call in C. The application initializing this window was developed many years ago and is compiled in C, however, I can implement my window in any way. I decided to utilize MFC to design my GUI which is essentially a CAD model creator. The host application needs to be able to open multiple instances of this window and upon saving or closing the window, have Objects returned to the code from my dialogs to be processed.

Thus far, I created a MFC application that spawns various dialogs for object creation. I am having trouble creating wrapper functions to call the InitInstance() from a testbed (a simple console application). Also I have been reading about the MFC framework and have noticed that a global CwinApp object is created, which is unacceptable in terms of this application. Also, it appears you are limited to one instance of the app object.

However as a test, during the construction of the Object, I have a debug assertion error at appcore.cpp at the line:

ASSERT(m_pszAppName != NULL);

and am unable to spawn a window.

But I suppose the most glaring question is, should I go straight to the winApi to design this GUI or am I on the right track? I'd hate to start from scratch again.

Thanks in advance

I'm a little unclear about the structure of your program.

Do you want to start off new processes of the dialog application (i.e each dialog shows up in task manager as a separate process) from the console application?

Or do you want to only create additional dialogs from the console application?

Well, the application that should call my dialogs do not support multithreading, So U suppose i just need multiple calls from the console. What would you recommend? Thanks for the reply!

I'm having trouble following your post. You don't call InitInstance yourself. What's wrong with a CWinApp object? I assuming you're referring to what they call theApp which is your running application. It doesn't make sense to have more than one. You can fire up multiple instances of your app if you like.

You can call ShellExecute or CreateProcess multiple times without the need for multi-threading.

Apparently the application calling my dialog has very specific memory requirements and I am not allowed to use any global variables. Also, I need to return data through a function call. Is there a way in which ShellExecute and CreateProcess will allow me to do this?

Seems the main point that you're really missing is that in Windows every process runs in isolated address space, and never shares its memory with other processes (well, it may do that partially after doing some special tricks, but generally doesn't, and anyway this relates to sharing data but not code/functions). This way you just cannot call or call back functions in processes launched by ShellExecute or CreateProcess.

Right. Therefore, is MFC not the solution to this project? Should I be designing my own functions using Win32 API to simply generate windows using createEX and the like? I would hate to not be able to use my MFC application that I've already made... Thanks for the replies guys

Your problem is still a little unclear to me. I don't understand the problem with globals. I don't know what you mean about wrapper functions to call InitInstance. Not sure what multi-threading has to do with it. We don't know what you're doing that's firing the ASSERT. We don't know anything about the C app you're using. Can you modify its code? If you need to get data back, perhaps you should be writing a DLL instead.

OK let me try to explain this again. In visual studio I have created an MFC application using the Application template. This file has 3 classes: the Cwinapp derived class, and 2 C dialog derived classes. As of now this app just receives input and splashes a 3D scene onto an OpenGL window but at the same time creates a file to be exported (which can be read by other CAD viewers).

As specifications given to me, my company's application must make a function call in C that 1: initializes my dialog window 2: upon closing the dialog, returns an object to the waiting application. To be honest I guess multi-threading doesn't really have anything to do with this. Also, the fact that the CWinApp has to be in global space deeply disturbed my associates, as their current application does not utilize any variables in global space (apparently it crashes their app or something).

Ideally, I need to create a DLL, however, as of now, as proof of concept, I just recompiled all the headers and source files of my application into another project. I have a main.cpp that I want to demonstrate can utilize a basic C function call to initialize the windows.

WHen i create an instance of:

CGCE_GUIApp jesus;
jesus.InitInstance();

in main, the ASSERT described above is triggered in "appcore.cpp". I've read that this is usually triggered when multiple instances of a CWinApp are created. Does this clear things up?

Seems the problem is improper testbed design rather than MFC app.

In MFC CWinApp::InitInstance is not intended to be called by your code. Period. You just must not do that.

Quote:

---

Originally Posted by kingting

OK let me try to explain this again. In visual studio I have created an MFC application using the Application template. This file has 3 classes: the Cwinapp derived class, and 2 C dialog derived classes. As of now this app just receives input and splashes a 3D scene onto an OpenGL window but at the same time creates a file to be exported (which can be read by other CAD viewers).

As specifications given to me, my company's application must make a function call in C that 1: initializes my dialog window 2: upon closing the dialog, returns an object to the waiting application. To be honest I guess multi-threading doesn't really have anything to do with this. Also, the fact that the CWinApp has to be in global space deeply disturbed my associates, as their current application does not utilize any variables in global space (apparently it crashes their app or something).

Ideally, I need to create a DLL, however, as of now, as proof of concept, I just recompiled all the headers and source files of my application into another project. I have a main.cpp that I want to demonstrate can utilize a basic C function call to initialize the windows.

WHen i create an instance of:

CGCE_GUIApp jesus;
jesus.InitInstance();

in main, the ASSERT described above is triggered in "appcore.cpp". I've read that this is usually triggered when multiple instances of a CWinApp are created. Does this clear things up?

---

A little bit. What does "returns an object to the waiting application" mean?

You don't need to create an instance of your app and you should never directly call InitInstance. The framework does that for you. Think of InitInstance as roughly analogous to main in an MFC app. It's the point in the program where you can start writing code but you don't call it yourself.

Your associates are deeply disturbed over nothing.

I guess returning is not the right word. The function call should take in a double pointer (pointing to a structure containing breps and other nurbs data necessary for the C application to perform calculations). In the end, the structure is created and the struct is allocated to that pointer.

I also don't understand the nuances of memory allocation and the problem with global variables... coming from an embedded background where memory is set in stone...

So if I am not meant to call the InitInstance(), the only way to bring up my MFC application is through createProcess() or ShellExecute()? What if I remake my application as a DLL?

Quote:

---

Originally Posted by kingting

I guess returning is not the right word. The function call should take in a double pointer (pointing to a structure containing breps and other nurbs data necessary for the C application to perform calculations). In the end, the structure is created and the struct is allocated to that pointer.

So if I am not meant to call the InitInstance(), the only way to bring up my MFC application is through createProcess() or ShellExecute()? What if I remake my application as a DLL?

---

Then you call functions directly as you would with any DLL. It sounds more like that's what you want.

If that is the case, which functions or classes would i add the __declspec(dllExport) macro to? How would I initialize and open dialogs/windows?

Thanks again for the help!

Export whatever functions you want to call. Call dialogs the same way you would in an exe.

CMyDialog dlg;
dlg.DoModal();

Would they be static functions?

I guess my question here is:
Back when my app was just an exe, the winmain function was essentially the InitInstance() and the app would run when you debugged or well... ran it. From my understanding, when the CwinApp object is declared in global space, it calls InitInstance() to begin generating the dialogs. From my understanding, myDialogInstance.DoModal() is called in InitInstance(). Therefore, would I only have to export the CwinApp class? When the DLL is utilized in my text bench, do I just create an instance of:
CmyApp myapp?

Quote:

---

Originally Posted by kingting

Would they be static functions?

I guess my question here is:
Back when my app was just an exe, the winmain function was essentially the InitInstance() and the app would run when you debugged or well... ran it. From my understanding, when the CwinApp object is declared in global space, it calls InitInstance() to begin generating the dialogs. From my understanding, myDialogInstance.DoModal() is called in InitInstance(). Therefore, would I only have to export the CwinApp class? When the DLL is utilized in my text bench, do I just create an instance of:
CmyApp myapp?

---

You're way too hung up on the CWinApp class. Ordinarily you won't have much in the way of dealing with it. You can create and display dialogs in any function you choose to. You never create an instance of your app yourself. The framework does that for you.

All you should need to export is the functions you need to call.

OK I will try this. Thanks for your help.

I am hung up on it because I don't really understand what it does haha.

How do I edit my resources (the appearance of the windows) If Im using a MFC DLL template? Also when compiling a DLL, can I have multiple header files linked to it or do I have to compile all my classes and functions into 1 header? Sorry for my noobish questions...

Quote:

---

Originally Posted by kingting

How do I edit my resources (the appearance of the windows) If Im using a MFC DLL template?

---

The same way like you do that with MFC App. Resource can be embedded into any binary, exe or dll, so its editing is supported in both project types.

Quote:

---

Also when compiling a DLL, can I have multiple header files linked to it or do I have to compile all my classes and functions into 1 header? Sorry for my noobish questions...

---

Sure you can. DLL is just another type of executable binary file. So there's no limitations of the kind.

Hi All,

Am I able to compile a MFC DLL and utilize it in a normal console application?

When I try to execute the console app, I don't have the exact error, but it tells me I must be compiling a MFC C++ application

Thanks for the help

Quote:

---

Am I able to compile a MFC DLL and utilize it in a normal console application?

---

Sure you can. DLL is a binary module able to be loaded into any Windows process.

Quote:

---

When I try to execute the console app, I don't have the exact error, but it tells me I must be compiling a MFC C++ application

---

I have to admit I do not understand what exactly you do, execute or compile.

Hi guys,

I'm giving this one last shot. I decided not to compile a DLL and simply place all source files and header files into the project directory. I got rid of anything pertaining to CwinApp and simply wrote a main method:


#include "stdafx.h"
#include "GCE_GUIDlg.h"


int main (void){

RT_Object *rto = NULL;

CGCE_GUIDlg myGUI;
myGUI.DoModal();

RT_ImportCopyObject(myGUI.rto, &rto);



return 0;
}

This is supposed to represent the C application performing a function call to attain the RT_Object

Also, being a complete noob, how do you write code neatly in a forum post?

It is compiling, however, i get this error:

First-chance exception at 0x789394ea (mfc100ud.dll) in GCE_GUI.exe: 0xC0000005: Access violation reading location 0x00000000.

Is this a lost cause? I am trying to learn the winAPI and start from scratch using this http://www.songho.ca/opengl/gl_mvc.html . I do have a deadline coming up though, and I am having trouble understanding this MVC framework. The reason for doing this is that I can code consistently with what the developers of the C Application have already done, thus guaranteeing that my app can be called from their app.

RT_ImportCopyObject(myGUI.rto, &rto);

Are you sure it wants a pointer to a pointer there?

Thanks for the reply

But yes, that is what the API dictates. I've tried adding break points when the main function starts, but the error occurs before anything even happens

Quote:

---

Originally Posted by kingting

Thanks for the reply

But yes, that is what the API dictates. I've tried adding break points when the main function starts, but the error occurs before anything even happens

---

Is your app actually crashing or is that just something you see in the output window and your app keeps running?

It continues running but essentially will not progress past
// Perform specific initializations
if (!pThread->InitInstance())
{
within winmain.cpp

Actually now that I trhink about it, that is happening because I've completrely gotten rid of my CWinApp Classes, is there anyway I can just use my own main as opposed to the winmain used when creating a MFC application?

Quote:

---

Originally Posted by kingting

Actually now that I trhink about it, that is happening because I've completrely gotten rid of my CWinApp Classes, is there anyway I can just use my own main as opposed to the winmain used when creating a MFC application?

---

winmain is for windows apps, main is for console apps. You seem to be making this a lot harder than it should be though. Hard to say how without seeing your whole project. At this point, I'd suggest getting a tutorial book on how Visual Studio and MFC work.

Oh... Is there any way I can show you guys how my project is laid out?

What type of project did you create, and seriously, stop messing with the CWinApp class. If the wizard put it there, it put it there for a reason.

Seems we cannot avoid showing some working code... :)

Thank you for the help! I just had to wrap my head around the fact that I just needed to make a dummy Cwinapp variable... However, I forgot about this thread and have essentially done the same thing as before in WinAPI which is a little easier to understand in my opinion.

Quote:

---

Originally Posted by kingting

Thank you for the help! I just had to wrap my head around the fact that I just needed to make a dummy Cwinapp variable... However, I forgot about this thread and have essentially done the same thing as before in WinAPI which is a little easier to understand in my opinion.

---

Yeah, it takes a little more to understand the OOP approach in a framework like MFC or ATL, but the benefit is you don't have to write the same code over and over everytime you create a new app.

Lot's of folks that try to use MFC don't bother to actually spend a little time to learn MFC, so it seems like they are constantly fighting with it.

Quote:

---

Originally Posted by kingting

Thank you for the help! I just had to wrap my head around the fact that I just needed to make a dummy Cwinapp variable... However, I forgot about this thread and have essentially done the same thing as before in WinAPI which is a little easier to understand in my opinion.

---

If that was your conclusion, you're doing something very wrong.