Prev: Getting notifications working on a CStatic
Next: use "template" in C
From: Goran on 19 Jan 2010 07:43
On Jan 19, 11:25 am, w...(a)newsgroups.nospam
<weknewsgroupsnos...(a)discussions.microsoft.com> wrote:
> I have a DLL which uses MFC and is compiled with /clr (because it contains
> classes which must be callable from C#).
> That works well when being used from a C# application by calling :
> if (!AfxWinInit(::GetModuleHandle("<dllname>"), NULL, ::GetCommandLine(),
> 0)) return false;
> AfxGetApp())->InitInstance();
> so that the DLL has its own App-Object/State which is initialized by the
> above source code.
>
> But now I also want to use that DLL in a C++ MFC application which already
> has a CWinApp object; so I would like not to establish a new one for the DLL
> but use the one of the MFC application.
>
> How can I prevent the DLL having it's own App-Object/State ?

IIRC...

Normally, you don't prevent this, you work with it.What's the reason
you want to prevent this?

Normally, a regular DLL that uses MFC works fine with other such DLLs/
exes. If, in your DLL, you link to MFC dynamically, what you need to
do is to to put AFX_MANAGE_STATE(AfxGetStaticModuleState()) at each
dll boundary method. That tells MFC what "module state" is in effect,
and so while running code from a given module, that module uses it's
own module state. That's it. (A tutorial explaining MFC dlls should
explain that in more detail).

If you link statically, I __think__ you don't need to do anything.

I don't remember what should be done when you are writing an MFC
__extension__ dll, but since you're using this from managed code,
you're not doing that.

Goran.
From: wek on 19 Jan 2010 08:55
"Goran" wrote:

> On Jan 19, 11:25 am, w...(a)newsgroups.nospam
> <weknewsgroupsnos...(a)discussions.microsoft.com> wrote:
> > I have a DLL which uses MFC and is compiled with /clr (because it contains
> > classes which must be callable from C#).
> > That works well when being used from a C# application by calling :
> > if (!AfxWinInit(::GetModuleHandle("<dllname>"), NULL, ::GetCommandLine(),
> > 0)) return false;
> > AfxGetApp())->InitInstance();
> > so that the DLL has its own App-Object/State which is initialized by the
> > above source code.
> >
> > But now I also want to use that DLL in a C++ MFC application which already
> > has a CWinApp object; so I would like not to establish a new one for the DLL
> > but use the one of the MFC application.
> >
> > How can I prevent the DLL having it's own App-Object/State ?
>
> IIRC...
>
> Normally, you don't prevent this, you work with it.What's the reason
> you want to prevent this?
>
> Normally, a regular DLL that uses MFC works fine with other such DLLs/
> exes. If, in your DLL, you link to MFC dynamically, what you need to
> do is to to put AFX_MANAGE_STATE(AfxGetStaticModuleState()) at each
> dll boundary method. That tells MFC what "module state" is in effect,
> and so while running code from a given module, that module uses it's
> own module state. That's it. (A tutorial explaining MFC dlls should
> explain that in more detail).
>
> If you link statically, I __think__ you don't need to do anything.
>
> I don't remember what should be done when you are writing an MFC
> __extension__ dll, but since you're using this from managed code,
> you're not doing that.
>
> Goran.
> .
Hello Goran, thanks for your post.
The reason is that the CWinApp-derived class in the (MFC-)EXE implements a
lot of basic initialization and functionality (which is time consuming) which
I want to be available in the CWinApp/AfxGetApp() called from the DLL also;
but this is only the case if AfxGetApp() called from the DLL points to the
App-object of the EXE and not to a separate App-Object of the DLL

Werner
From: Ajay Kalra on 19 Jan 2010 09:02
On Jan 19, 5:25 am, w...(a)newsgroups.nospam
<weknewsgroupsnos...(a)discussions.microsoft.com> wrote:
> I have a DLL which uses MFC and is compiled with /clr (because it contains
> classes which must be callable from C#).
> That works well when being used from a C# application by calling :
> if (!AfxWinInit(::GetModuleHandle("<dllname>"), NULL, ::GetCommandLine(),
> 0)) return false;
> AfxGetApp())->InitInstance();
> so that the DLL has its own App-Object/State which is initialized by the
> above source code.
>
> But now I also want to use that DLL in a C++ MFC application which already
> has a CWinApp object; so I would like not to establish a new one for the DLL
> but use the one of the MFC application.
>
> How can I prevent the DLL having it's own App-Object/State ?

You cant prevent it. However you can switch states using
AFX_MANAGE_STATE macros. Also, the scenario you pointed out would be
present in a Regular MFC dll and not in a MFC Extension DLL. Any
reason to have a regular DLL as opposed to an MFC Extension DLL?

--
Ajay

From: Joseph M. Newcomer on 19 Jan 2010 11:59
See below...
On Tue, 19 Jan 2010 05:55:01 -0800, wek(a)newsgroups.nospam
<weknewsgroupsnospam(a)discussions.microsoft.com> wrote:

>"Goran" wrote:
>
>> On Jan 19, 11:25 am, w...(a)newsgroups.nospam
>> <weknewsgroupsnos...(a)discussions.microsoft.com> wrote:
>> > I have a DLL which uses MFC and is compiled with /clr (because it contains
>> > classes which must be callable from C#).
>> > That works well when being used from a C# application by calling :
>> > if (!AfxWinInit(::GetModuleHandle("<dllname>"), NULL, ::GetCommandLine(),
>> > 0)) return false;
>> > AfxGetApp())->InitInstance();
>> > so that the DLL has its own App-Object/State which is initialized by the
>> > above source code.
>> >
>> > But now I also want to use that DLL in a C++ MFC application which already
>> > has a CWinApp object; so I would like not to establish a new one for the DLL
>> > but use the one of the MFC application.
>> >
>> > How can I prevent the DLL having it's own App-Object/State ?
>>
>> IIRC...
>>
>> Normally, you don't prevent this, you work with it.What's the reason
>> you want to prevent this?
>>
>> Normally, a regular DLL that uses MFC works fine with other such DLLs/
>> exes. If, in your DLL, you link to MFC dynamically, what you need to
>> do is to to put AFX_MANAGE_STATE(AfxGetStaticModuleState()) at each
>> dll boundary method. That tells MFC what "module state" is in effect,
>> and so while running code from a given module, that module uses it's
>> own module state. That's it. (A tutorial explaining MFC dlls should
>> explain that in more detail).
>>
>> If you link statically, I __think__ you don't need to do anything.
>>
>> I don't remember what should be done when you are writing an MFC
>> __extension__ dll, but since you're using this from managed code,
>> you're not doing that.
>>
>> Goran.
>> .
>Hello Goran, thanks for your post.
>The reason is that the CWinApp-derived class in the (MFC-)EXE implements a
>lot of basic initialization and functionality (which is time consuming) which
>I want to be available in the CWinApp/AfxGetApp() called from the DLL also;
>but this is only the case if AfxGetApp() called from the DLL points to the
>App-object of the EXE and not to a separate App-Object of the DLL
>
****
This is because you think it is an "App-object" that might have something to do with the
CWinApp-derived class of your executable. As I pointed out, this confusion arises because
of the similar textual name. You are clearly thinking that the functionality of the
CWinApp class in a DLL has something to do with the CWinApp class of an executable.

What functionality executed in the DLL is "time consuming"? Can you quantize this time?
Generally, when we use the phrase "time consuming" we actually have a belief that this
consumes enough time to matter, and can usually say "This uses 200ms" or some similar
explicit statement. I saw 23 assignment statments and a few function calls, so I would
guess that it takes something under 100ns to do the initiialization I saw in the
constructor. Not what I would consider a serious consumption of time. Are you seeing
something different? If so, please explain. Note that in loading the DLL, if the disk
misses a sector because of rotational latency, this will typically add 5-10ms (5000-10000
times more delay than the initialization I saw). If it has to seek, because the DLL is
stored on a different cylinder, you lose another factor of a hundred or so. This means
that the time lost in 10,000 executions by the "overhead" you are referring to more than
likely is completely swamped by a single load of the DLL in a single execution. So I fail
to see where there is any "time consuming" overhead here. Did you single-step execute the
initialization of the CWinApp class in your DLL? Did you instrument it in any way? If
you cannot tell me the exact amount of time it "consumes", you are probably trying to
"optimize" something not even worthy of discussion.

Now, let's say I'm off by a couple orders of magnitude. For example, suppose it takes
10,000 instructions to initialize the CWinApp. 10,000 instructions. At 2 instructions
per clock cycle (not uncommon, sometimes it can be 3 or 4 with newer chips), that's 5,000
clock cylces. On a 2.8GHz machine, that's, wow, almost TWO WHOLE MICROSECONDS. A single
rotational delay miss (5-10ms) means that you can do somewhere between 2500 and 5000
initalizations in a single rotational miss. And what makes you otpimisitically think that
you would have only one rotational miss per load? Unless you have raw numbers and can
make a quantitative case, phrases like "time consuming" are meaningless noise.

Note that a single page fault costs you 20,000,000-40,000,000 CPU cycles.

So why are you overly concerned about a nonexistent problem?
joe
>Werner
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: wek on 20 Jan 2010 04:36
"Ajay Kalra" wrote:

> On Jan 19, 5:25 am, w...(a)newsgroups.nospam
> <weknewsgroupsnos...(a)discussions.microsoft.com> wrote:
> > I have a DLL which uses MFC and is compiled with /clr (because it contains
> > classes which must be callable from C#).
> > That works well when being used from a C# application by calling :
> > if (!AfxWinInit(::GetModuleHandle("<dllname>"), NULL, ::GetCommandLine(),
> > 0)) return false;
> > AfxGetApp())->InitInstance();
> > so that the DLL has its own App-Object/State which is initialized by the
> > above source code.
> >
> > But now I also want to use that DLL in a C++ MFC application which already
> > has a CWinApp object; so I would like not to establish a new one for the DLL
> > but use the one of the MFC application.
> >
> > How can I prevent the DLL having it's own App-Object/State ?
>
> You cant prevent it. However you can switch states using
> AFX_MANAGE_STATE macros. Also, the scenario you pointed out would be
> present in a Regular MFC dll and not in a MFC Extension DLL. Any
> reason to have a regular DLL as opposed to an MFC Extension DLL?
>
> --
> Ajay
>
> .
Hello Ajay, thanks for your help.
My DLL (.NET) exposes .NET classes and must be accessible from anonther .NET
DLL written in C#. My EXE is written in C++, uses MFC and is compiled with
/clr.
http://msdn.microsoft.com/en-us/library/h5f7ck28(VS.80).aspx says :
"An extension DLL can also be used by a regular DLL that is dynamically
linked to MFC.", but my C# DLL is not linked to MFC, only the EXE is.
So I think I can't use a MFC extension DLL; or am I wrong with this ?

Werner
 |  Next  |  Last
Pages: 1 2 3
Prev: Getting notifications working on a CStatic
Next: use "template" in C