Proper Usage of the MFC Framework

[kingting]

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

[Arjay]

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?

[kingting]

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!

[GCDEF]

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.

[kingting]

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?

[Igor Vartanov]

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.

[kingting]

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

[GCDEF]

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.

[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?

[Igor Vartanov]

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

[Igor Vartanov]

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

[GCDEF]

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.

[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.

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?

[GCDEF]

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.

[kingting]

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!