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.