Re: ? Segregating a Dialog's Code (Particularly Resources)

It's not the perfect solution for every situation, but here is the scenario
that I have seen repeatedly.

I typically put all of the common code in a single Dll, and include that in
the projects that need access to the common code. Now, not all of the
application need every single dialog/class that is in the dll, but as a
whole they use everything in the dll (I would say each app uses at least 33%
of the dll). If I was to put every class/dialog in a separate dll, I would
end up with the problem you described. With my solution you will end up
with one slightly bulky dll which gets used by all the exes.

Now the problem with my solution is that if one control, or class in the dll
needs to get updated, then all the exe will have to be recompiled, where if
each control was in a separate dll, only the ones using that particular
control would have to get recompiled, but realistically how often does that
happen? And would it be really that bad to recompile and redistribute all
the exes instead just a subset of the exes.

And as far as static or dynamically linking goes, I don't think it will make
any difference in this situation, the point is that you are linking with the
codejock library, which has all of its controls either in a dll or a lib
file. I'm sure you have a reason for linking statically, but liking
dynamically only means that you will have to ship their dll with your app,
and that you won't have to manually include their rc file in your project,
as it comes with the dll. (note that none of the codejock rc files have ICON
resource types).

AliR.

"Tom Serface" <tom@nospam.camaswood.com> wrote in message
news:178EE7FD-799F-4A25-89A1-B57C0B6505FE@microsoft.com...