OCX, AFX_MODULE_STATE, and missing runtime class information
Tom Sears -- TSears@unlimitedsolutions.com
Tuesday, January 28, 1997
Environment: NT 3.51 (SP5), VC4.1
Hello All,
I am having a very specific problem with serializing ( dynamic object
creation specifically) an application object within an OCX. I wrote a
small utility that dumps the current static module state as well as the
state of each of the current CDynLinkLibraries. This util dumps all of
the known current runtime classes and which state they are located in.
It has shown me that the DLL(an MFC extension DLL) that contains the
runtime class information that I need is getting chained into the main
application module state and not the OCX's module state. I have tried
AFX_MANAGE_STATE(_afxModuleAddrThis) and this does not fix the problem.
Just for kicks I tried AFX_MANAGE_STATE(AfxGetStaticModuleState() ) and
the problem still exists. I even tried adding a global static object of
my class type within the OCX to force the linker to link this class in
and the runtime class information and corresponding DLL still gets
chained into the application's module state and not the OCXs. I know
that the object itself is declared and implemented correctly because I
serialize() and deserialize without problems. It is just the OCX that
seems to give me trouble.
I have a machine with VC 4.2 installed and I am going to try that this
afternoon, but I am starting to run out of ideas here. If cannot fix
this problem, I guess that I will convert the OCX back to a DLL.
Hopefully, someone out there in 'MFC land' can point me in the right
direction.
Thanks
Tom Sears
tsears@unlimitedsolutions.com
Stuart Downing -- sdowning@fame.com
Thursday, January 30, 1997
[Mini-digest: 3 responses]
If you want to use your extension DLL from a _USRDLL
client, as is the case with an OLE control module,
you need to have an initialization function in the
extension DLL that allocates an appropriate
CDynLinkLibrary object. The function is called in
the _USRDLL during its initialization (OnInitInstance,
in the case of a COleControlModule).
This causes the extension DLL to be linked into the
extension DLL chain for the _USRDLL.
This is discussed in KB article Article ID: Q154126.
----------
From: Tom Sears[SMTP:TSears@unlimitedsolutions.com]
Sent: Tuesday, January 28, 1997 11:56 AM
To: 'mfc-l@netcom.com'
Subject: OCX, AFX_MODULE_STATE, and missing runtime class information
Environment: NT 3.51 (SP5), VC4.1
Hello All,
I am having a very specific problem with serializing ( dynamic object
creation specifically) an application object within an OCX. I wrote a
small utility that dumps the current static module state as well as the
state of each of the current CDynLinkLibraries. This util dumps all of
the known current runtime classes and which state they are located in.
It has shown me that the DLL(an MFC extension DLL) that contains the
runtime class information that I need is getting chained into the main
application module state and not the OCX's module state. I have tried
AFX_MANAGE_STATE(_afxModuleAddrThis) and this does not fix the problem.
Just for kicks I tried AFX_MANAGE_STATE(AfxGetStaticModuleState() ) and
the problem still exists. I even tried adding a global static object of
my class type within the OCX to force the linker to link this class in
and the runtime class information and corresponding DLL still gets
chained into the application's module state and not the OCXs. I know
that the object itself is declared and implemented correctly because I
serialize() and deserialize without problems. It is just the OCX that
seems to give me trouble.
I have a machine with VC 4.2 installed and I am going to try that this
afternoon, but I am starting to run out of ideas here. If cannot fix
this problem, I guess that I will convert the OCX back to a DLL.
Hopefully, someone out there in 'MFC land' can point me in the right
direction.
Thanks
Tom Sears
tsears@unlimitedsolutions.com
-----From: hou@tfn.com (Bing Hou)
It is not quite clear to me what you are after.
Anyway, a MFC extension DLL doesn't switch its module state, it thinks that
it's always presented in the application. An OCX on the other hand does
switch module state. The state it switches to is a snapshot it remembers
when it's first created. Therefore the DLL, no matter what relationship it
has with the OCX, will have no idea that the OCX is secretively keeping a
module state for its own use.
OLE has well defined mechanism to serialize an OCX. May be your problem
stems from this area?
Bing Hou
hou@tfn.com
------------------------------------------------------------------------
The shortest distance between two points is always under construction.
- Noelie Alito
______________________________ Reply Separator _________________________________
Subject: OCX, AFX_MODULE_STATE, and missing runtime class information
Author: Tom Sears at Internet
Date: 1/28/97 11:56 AM
Environment: NT 3.51 (SP5), VC4.1
Hello All,
I am having a very specific problem with serializing ( dynamic object
creation specifically) an application object within an OCX. I wrote a
small utility that dumps the current static module state as well as the
state of each of the current CDynLinkLibraries. This util dumps all of
the known current runtime classes and which state they are located in.
It has shown me that the DLL(an MFC extension DLL) that contains the
runtime class information that I need is getting chained into the main
application module state and not the OCX's module state. I have tried
AFX_MANAGE_STATE(_afxModuleAddrThis) and this does not fix the problem.
Just for kicks I tried AFX_MANAGE_STATE(AfxGetStaticModuleState() ) and
the problem still exists. I even tried adding a global static object of
my class type within the OCX to force the linker to link this class in
and the runtime class information and corresponding DLL still gets
chained into the application's module state and not the OCXs. I know
that the object itself is declared and implemented correctly because I
serialize() and deserialize without problems. It is just the OCX that
seems to give me trouble.
I have a machine with VC 4.2 installed and I am going to try that this
afternoon, but I am starting to run out of ideas here. If cannot fix
this problem, I guess that I will convert the OCX back to a DLL.
Hopefully, someone out there in 'MFC land' can point me in the right
direction.
Thanks
Tom Sears
tsears@unlimitedsolutions.com
-----From: Kostya Sebov
> Environment: NT 3.51 (SP5), VC4.1
>
> Hello All,
>
> I am having a very specific problem with serializing ( dynamic object
> creation specifically) an application object within an OCX. I wrote a
> small utility that dumps the current static module state as well as the
> state of each of the current CDynLinkLibraries. This util dumps all of
> the known current runtime classes and which state they are located in.
> It has shown me that the DLL(an MFC extension DLL) that contains the
> runtime class information that I need is getting chained into the main
> application module state and not the OCX's module state. I have tried
> AFX_MANAGE_STATE(_afxModuleAddrThis) and this does not fix the problem.
> Just for kicks I tried AFX_MANAGE_STATE(AfxGetStaticModuleState() ) and
> the problem still exists. I even tried adding a global static object of
> my class type within the OCX to force the linker to link this class in
> and the runtime class information and corresponding DLL still gets
> chained into the application's module state and not the OCXs. I know
> that the object itself is declared and implemented correctly because I
> serialize() and deserialize without problems. It is just the OCX that
> seems to give me trouble.
>
> I have a machine with VC 4.2 installed and I am going to try that this
> afternoon, but I am starting to run out of ideas here. If cannot fix
> this problem, I guess that I will convert the OCX back to a DLL.
> Hopefully, someone out there in 'MFC land' can point me in the right
> direction.
>
> Thanks
>
> Tom Sears
> tsears@unlimitedsolutions.com
>
Since the OCX is merely a regular DLL the following excerpt from the VC's
books online directly allpies to your case.
IMO, this very important notice is burried too deep inside the documentation
so it's not surprising that you didn't find it. In my case I did it only
because I knew almost precisely where to search after a having walked a couple
of hours through the MFC code maze.
Visual C++ Books
MFC 4.2
Dynamic Link Libraries (DLLs)
DLLs: Building and using an Extension DLL
[...]
If you are going to use your Extension DLL from one or more Regular DLLs,
you must export an initialization function that creates a CDynLinkLibrary
object. That function needs to be called from each of the Regular DLLs that
uses the Extension DLL. An appropriate place to call this initialization
function is in the InitInstance member function of your CWinApp-derived
object before using any of the Extension DLL's exported classes or functions.
[...]
Hope this'll help!
---
Kostya Sebov.
----------------------------------------------------------------------------
Tel: (38 044) 266-6387 | Fax: (38 044) 266-6195 | E-mail: sebov@is.kiev.ua
| Вернуться в корень Архива
|