Re: One resource file per CDialog or VSS solution
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:pqeeb4153s409pr3k6jriuoihtbj6go2tk@4ax.com...
Since IMO a dialog should never, ever access any state which it is not
explicitly given
via member variables, a dialog never needs to see any variables of the
application.
Therefore, if you put one dialog per DLL, you get the advantage that
fine-grained checkout
means that if you are working on dialog A, you check out the files for
dialog A, and don't
conflict with anyone working on dialog B. And you don't end up checking
out the
.rc/resource.h file and then having unlimited ability to manipulate any
dialog within the
project, in potential conflict with others.
Wouldn't putting each dialog in a separate DLL unduly burdan the caller?
Seems it would have to manually load each DLL, call AfxSetResourceHandle(),
then call DoModal(). That's a lot to ask every time a dialog is shown.
It also seems there would be some source code that needs to #include
multiple resource.h files (since it needs to manipulate multiple dialogs),
and that would cause errors if some common symbol like IDC_RADIO1 were
defined in more than one of the header files.
Also, many companies localize apps by creating one more DLL per language.
If each dialog were in a separate DLL, that would quickly bring to an
unmanageable number the resource DLL's needed. For these reasons, I don't
think it's feasible to put one dialog per DLL.
I find the easiest way for multiple programmers to edit resources is just to
have a policy that if there is a collision of resource id's, just do a
manual renumber so that all the id's in resource.h are consecutive. I do
that by hand since I'm a fast typist, but there are also utilities that can
do that.
-- David