Prev: CTooltipCtrl on disabled control question
Next: Drawing on DC
From: Ajay Kalra on 16 Nov 2006 17:06
Whats the setup for your app? Are you using this in a Regular DLL? What sort
of App is it? Why not simply use a Dialog/SDI/MDI based app? Regardless, if
you dont need a window why do you even have a CWinApp?

--
Ajay Kalra [MVP - VC++]
ajaykalra(a)yahoo.com


"Herby" <prmarjoram(a)gmail.com> wrote in message
news:1163670767.243341.237750(a)h54g2000cwb.googlegroups.com...

> I have an MFC application hosting a COM component.
> It has not got a user interface and so has no window classes.
>
> I get the following error message when attempting to run it:
>
> Warning: m_pMainWnd is NULL in CWinApp::Run - quitting application.
>
>
> Is there a way round this or must i have a dummy window?
>
> What is the best and most efficient way to cure this problem?
>
> Thanks.
>


From: Herby on 17 Nov 2006 05:40
Guys that all seems to work now.
But later on when it attempts to de-serialize a file I have a problem
with the following:

AFX_MODULE_STATE* pModuleState = AfxGetModuleState();

The members of pModuleState are all not set!

Why would this be?
I assume its something to do with the handcrafted main window
initialisation ?

From: Herby on 17 Nov 2006 10:54

Ajay Kalra wrote:
> Whats the setup for your app? Are you using this in a Regular DLL? What sort
> of App is it? Why not simply use a Dialog/SDI/MDI based app? Regardless, if
> you dont need a window why do you even have a CWinApp?
>
> --
> Ajay Kalra [MVP - VC++]
> ajaykalra(a)yahoo.com
>

What are the alternatives?

Because the App is housing a COM component when the client requires it
to run out of process.
The same component is housed within a DLL too.
The COM class derives directly from CCmdTarget.

So its just a house for the component. The actual business logic is
all written in MFC and uses MFC serialisation etc.

Anyway i have got somewhere with the problem. A typical method of my
COM class looks like the following:

LONG COMCalculator::OpenOleFile(LPCTSTR strOleFilePath)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());

bool result = mCalc.OpenOleFile(strOleFilePath);
if( result == true )
return S_OK;
return S_FALSE;
}


If i comment out AFX_MANAGE_STATE(AfxGetStaticModuleState()). then it
works fine.

My DLL version still works fine with this commented out too - although
more testing required.


I think the problem is linked to my exe app dummy window - because does
not load any resources ?

As this same code is used within a DLL too - do you think it is safe to
not make this call?
Again the DLL has no UI and no resources etc...

From: Ajay Kalra on 17 Nov 2006 11:00
> If i comment out AFX_MANAGE_STATE(AfxGetStaticModuleState()). then it
> works fine.

It appears that this is a Regular DLL. You should use AFX_MANAGE_STATE
in your methods if you are using resources (or accessing state) defined
in your own module. I dont know what OpenOleFile does so I cant comment
about it. Perhaps you are using the wrong state (you may need app state
instead). If you are not using Regular DLL, you should not be using
this macro anyway.

---
Ajay

From: Herby on 17 Nov 2006 16:08

Ajay Kalra wrote:
> > If i comment out AFX_MANAGE_STATE(AfxGetStaticModuleState()). then it
> > works fine.
>
> It appears that this is a Regular DLL. You should use AFX_MANAGE_STATE
> in your methods if you are using resources (or accessing state) defined
> in your own module. I dont know what OpenOleFile does so I cant comment
> about it. Perhaps you are using the wrong state (you may need app state
> instead). If you are not using Regular DLL, you should not be using
> this macro anyway.
>
> ---
> Ajay

Thanks Ajay.

What exactly do you mean by regular DLL?

I got the examples of how to add OLE automation to an MFC app off a
tutorial.

http://www.codeproject.com/com/mfc_autom.asp

Its examples included the above without an explanation.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: CTooltipCtrl on disabled control question
Next: Drawing on DC