How to create eventhandlers when using dialog resources from dll

[hmc]

Hi,

I like to have multiple dll's that contain dialog resources for each language i am going to use.

Suppose i have a dll that contains IDD_DLG_VOYATTRIB.

In my app i set the resource handle to this dialog and create a dialog called CDlgVoyageAttributes with this resource idd, like this:

HMODULE hDll = theApp.GetResourceDLLHandle();
ASSERT(hDll != NULL);

if(hDll != NULL)
{
	// Save current resource handle
	HINSTANCE hResourceHandle = AfxGetResourceHandle();	
		
	// Use dll resources
	AfxSetResourceHandle(hDll);

	// Create dialog with resource id from dll
	CDlgVoyageAttributes dlg(IDD_DLG_VOYATTRIB, this);
	dlg.DoModal();

	// Restore resource handle
	AfxSetResourceHandle(hResourceHandle);
}

I am wondering how to create event handlers for the dialog buttons in the CDlgVoyageAttributes class. How can i do that????

[raghupathys]

Not sure I understand your question.

Your already using MFC. So in your CDlgVoyageAttributes ( Which I assume is derived from CDialog) class edit the message macros, and add message handlers (with the appropriate control ids - so you will need to include the resource header from your resource DLL.), and accordingly implement them.

[Igor Vartanov]

I like to have multiple dll's that contain dialog resources for each language i am going to use.

Irrespectively of resource language use the same control ids. In this case your code would do for any language-specific resource.

I thought it's obvious thing...

[hmc]

Well, what it is not clear to me is: Does the messagehandlers of the dialog know that the control IDs they are linked to must be found in the resource dll.

[Igor Vartanov]

Well, what it is not clear to me is: Does the messagehandlers of the dialog know that the control IDs they are linked to must be found in the resource dll.

Please keep in mind the control ids are just numbers. They are kept (talking about MFC) inside message map records (in-memory at runtime and in-code in binary file) and must not to be found anywhere else. If resource has control ids different from ones used in code, the result will be at-runtime code malfunctioning.

Resume: resource ids must be identical to correspondent ids used in code. This identity guarantees proper code-resource interoperation. Which way this identity is achieved is up to programmer.

[hmc]

To prevent collision of ids between dll and app, i use SetResourceHandle() function to switch between resource handle of dll and app, but does this also work for the eventhandlers linked to a resourceid?

[Igor Vartanov]

To prevent collision of ids between dll and app, i use SetResourceHandle() function to switch between resource handle of dll and app, but does this also work for the eventhandlers linked to a resourceid?

Resource id is linked with message/event handlers in no way. Handlers deal with message and control ids, not with resource ids.

[hmc]

That's what i meant, sorry. Handlers are linked to control ids.

Suppose control ids in app and resource dll are the same. To prevent problems i use the SetResourceHandler() function just before displaying the dialog.
My question is do the eventhandlers in the dialog know that they are linked to controlIDs in the resource dll?

[Igor Vartanov]

My question is do the eventhandlers in the dialog know that they are linked to controlIDs in the resource dll?

Why do they have to? The control ids are compiled into the code - and thus the code either works or doesn't. But it can't know something. "To know" is a programmer's burden.

I think you're think of message handlers as a magic of some kind, which "knows" somehow about "controls" and "resources". It might drive you far away from real-world programming.

The code knows nothing. It's just a sequence of instructions. Some part of it creates window object, let's say - dialog, and in this case this part must have resource id and module instance to access proper dialog template resource. But after dialog was created it doesnt matter what resource was used. Now the thing is really matters becomes the dialog procedure, which uses dialog's message map. Message map has a set of records which are tied to some control ids. In case controls with those ids are not present in dialog, the handlers are just stay idle, 'cause the messages coming from/to controls never matches to those ids compiled into the code.

If you want to use the dialog handlers you have to supply proper resource having corresponding control ids. And any resource which have this correspondence will do for this code, it doesn't matter which one dll (or exe) module contains it, or which id is assigned to this resource.