Re: Internatinalization and multiple language support without resource DLLs

From:

"Tom Serface" <tom@nospam.camaswood.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Thu, 22 Jan 2009 12:17:27 -0800

Message-ID:

<#jFRf8MfJHA.5840@TK2MSFTNGP05.phx.gbl>

You are correct, of course, that it requires a certain amount of discipline.
I try to not use GetDlgItem(), but the problem would be as evident with
control variables as well. When a resource is missing (especially if it's
in the resource.h file since it's in another place) then there are problems
like you describe here.

I appreciate what they did in .NET where if the resource is missing from the
assigned language it just defaults to the default language for any resource.
That is really nice and something they could implement in MFC pretty easily
by checking to see if the initial return from FindResource was NULL.

You're right... there are always issues...

Tom

"Colin Peters" <cpeters@coldmail.com> wrote in message
news:4978b756$1_2@news.bluewin.ch...

The problem with resource dlls with dialogs in them is that if you update
your exe with a new edit field then you have to also have a new resource
dll for the target language at runtime.

Otherwise code like this will fail:
CEdit* pEdit = (CEdit*)GetDlgItem(IDC_NEW_CONTROL);
pEdit->Blabla();

Hands up those people who religeously check the returned pointer for NULL,
always, everywhere. Oh, not many hands there.

The DDX_Control function does something similar in the background. Point
being, that you've got runtime dependencies between discretely
distributable files.