15 мая 2023 года "Исходники.РУ" отмечают своё 23-летие!
Поздравляем всех причастных и неравнодушных с этим событием!
И огромное спасибо всем, кто был и остаётся с нами все эти годы!

Главная Форум Журнал Wiki DRKB Discuz!ML Помощь проекту


AVI resource in MFC EXT DLL?

Joseph Koral -- jkoral@ftp.com
Thursday, February 01, 1996

How can I put an AVI resource in an MFC extension DLL?

I have some CDialog-derived class exported from an MFC extension DLL.  =
That dialog has a animation control (CAnimateCtrl) in it.  I use the =
ACM_OPEN message to open the AVI file, passing it the ID of the AVI =
resource. =20

The problem is that since the dialog is created using the application's =
instance rather than the DLL's, the common control will only look in the =
application, and not my extension DLL.  (DoModal calls CreateDlgIndirect =
which uses AfxGetInstanceHandle as the first parameter).

It seems that since MFC is out of the loop on the loading of this =
resource, the only thing I can do is create the dialog using the =
instance of my extension DLL.  This works, but unfortunately I didn't =
find a public documented way of doing it, and had to use GetModuleState, =
etc.

Am I missing something here, or is there another way to do this?

- Joseph



David W. Gillett -- DGILLETT@expertedge.com
Monday, February 05, 1996

[Mini-digest: 2 responses]

> The problem is that since the dialog is created using the
> application's instance rather than the DLL's, the common control
> will only look in the application, and not my extension DLL. 
> (DoModal calls CreateDlgIndirect which uses AfxGetInstanceHandle
> as the first parameter).
>
> It seems that since MFC is out of the loop on the loading of this
> resource, the only thing I can do is create the dialog using the
> instance of my extension DLL.  This works, but unfortunately I
> didn't find a public documented way of doing it, and had to use
> GetModuleState, etc.
> 
> Am I missing something here, or is there another way to do this?


  It's possible that I've misunderstood something, but this sounds to 
me like exactly the scenario that AfxSetResourceHandle() is intended 
to, well, handle....

Dave

-----From: "Joseph M. Koral" 

I originally wrote:

> The problem is that since the dialog is created using the
> application's instance rather than the DLL's, the common control
> will only look in the application, and not my extension DLL.=20
> (DoModal calls CreateDlgIndirect which uses AfxGetInstanceHandle
> as the first parameter).
>
> It seems that since MFC is out of the loop on the loading of this
> resource, the only thing I can do is create the dialog using the
> instance of my extension DLL.  This works, but unfortunately I
> didn't find a public documented way of doing it, and had to use
> GetModuleState, etc.
>=20
> Am I missing something here, or is there another way to do this?

David Gillett replied:

>> It's possible that I've misunderstood something, but this sounds to=20
>> me like exactly the scenario that AfxSetResourceHandle() is intended=20
>> to, well, handle....


AfxSetResourceHandle is only used for resources that are loaded by MFC.  =
It's used in AfxFindResourceHandle as the first place to look for =
resources.  If not found there, it continues on through the =
CDynLinkLibrary chain.

As I stated in my original message, the ACM_OPEN message of the =
animation common control takes a resource ID and does the loading =
itself.  It obviously knows nothing about AfxSetResourceHandle.  All it =
knows is the current instance.  So if MFC gave the dialog the wrong =
instance (in this case that of the application, rather than the DLL), =
Windows will only look in the application and fail.

(Following my original post of this question to mfc-l, I read on =
CompuServe that MFC 4.1 will correct this problem by using the correct =
instance for the dialog).

- Joseph



David W. Gillett -- DGILLETT@expertedge.com
Monday, February 05, 1996

[Mini-digest: 2 responses]

> The problem is that since the dialog is created using the
> application's instance rather than the DLL's, the common control
> will only look in the application, and not my extension DLL. 
> (DoModal calls CreateDlgIndirect which uses AfxGetInstanceHandle
> as the first parameter).
>
> It seems that since MFC is out of the loop on the loading of this
> resource, the only thing I can do is create the dialog using the
> instance of my extension DLL.  This works, but unfortunately I
> didn't find a public documented way of doing it, and had to use
> GetModuleState, etc.
> 
> Am I missing something here, or is there another way to do this?


  It's possible that I've misunderstood something, but this sounds to 
me like exactly the scenario that AfxSetResourceHandle() is intended 
to, well, handle....

Dave

-----From: "Joseph M. Koral" 

I originally wrote:

> The problem is that since the dialog is created using the
> application's instance rather than the DLL's, the common control
> will only look in the application, and not my extension DLL.=20
> (DoModal calls CreateDlgIndirect which uses AfxGetInstanceHandle
> as the first parameter).
>
> It seems that since MFC is out of the loop on the loading of this
> resource, the only thing I can do is create the dialog using the
> instance of my extension DLL.  This works, but unfortunately I
> didn't find a public documented way of doing it, and had to use
> GetModuleState, etc.
>=20
> Am I missing something here, or is there another way to do this?

David Gillett replied:

>> It's possible that I've misunderstood something, but this sounds to=20
>> me like exactly the scenario that AfxSetResourceHandle() is intended=20
>> to, well, handle....


AfxSetResourceHandle is only used for resources that are loaded by MFC.  =
It's used in AfxFindResourceHandle as the first place to look for =
resources.  If not found there, it continues on through the =
CDynLinkLibrary chain.

As I stated in my original message, the ACM_OPEN message of the =
animation common control takes a resource ID and does the loading =
itself.  It obviously knows nothing about AfxSetResourceHandle.  All it =
knows is the current instance.  So if MFC gave the dialog the wrong =
instance (in this case that of the application, rather than the DLL), =
Windows will only look in the application and fail.

(Following my original post of this question to mfc-l, I read on =
CompuServe that MFC 4.1 will correct this problem by using the correct =
instance for the dialog).

- Joseph




| Вернуться в корень Архива |