Conference 7.286::visualc

    
    We have divided up our project into several functional
    areas. Each area is a separate project that builds a
    static library. Each area project contains it's own
    resource files ( <blar>.rc and resource.h ).
    There are several lines at the bottom of the resource.h
    files that control the numbers allocated by the developers
    studio. Each area project uses a different number range.
     
    To pull the whole thing together we have a main executable
    project that links in all the static libs. The resource
    file in this project includes all the other resource files
    from the area projects. This can be done by right clicking
    on the top level branch of the resource tree and selecting
    "Resource Includes". We have lines such as:
    
    	#include "..\Common\Common.rc"
    
    in the "Compile-Time Directives" section.
    
    The following is an extract from a document that describes our
    development environment - it may help in seting up the resource.h
    files so that the developers studio uses separate number ranges.
    
    =================================================================
    
    When a project is first created it needs to be allocated a unique range
    of resource IDs so that different projects do not clash over the same
    ID. To do this the resource.h file for the project needs to be edited
    and the following #define statements need to be modified: 
    
    #define _APS_NEXT_RESOURCE_VALUE	1001
    #define _APS_NEXT_COMMAND_VALUE	41001 ( 40000 + base of number range )
    #define _APS_NEXT_CONTROL_VALUE	1001
    #define _APS_NEXT_SYMED_VALUE	1001
    
    The #defines above show how the values were initially set up in the
    Common project - range 1001-1500. Once dialogs and other resources
    are added to the project some of these values will be incremented.
    There is no guarantee that the numbers will not grow and overlap with
    the next projects allocation - we just have to watch out to make sure
    it doesnt happen.
    
    WARNING: If you cut and paste dialogs etc. from another project the
    resource IDs will be set up as they were in the source project. This is
    probably not what you want and the numbers will have to be hand edited
    to fall in line with the projects allocated number range. The four
    _APS_NEXT__VALUE #defines will also need adjusting.
    
    Also for each project a unique naming convention is used so that the
    identifier names do not clash, this is generally a 2 or 3 letter
    abbreviation for the project which should be used for each name created
    for that project.
    
    ==============================================================
    
    Richard.
    

I previously worked on a project called NPCLM where we
developed extensions for the Microsoft product SMS. SMS
has an extension mechanism called the OEM DLL, where you
develop SMS UI extensions & related functionality as an
OEM DLL which is registered during SMS setup and then called
by the main SMS EXE. We ran into similar problems to those
mentioned in .0, with the added complication that we had
no control over the resource IDs used by the SMS main
EXE's resource DLL or by other OEM DLLs, so therefore could
no rely on dividing up the range of resource IDs between
our components.

The solution we adopted was to divide the NPCLM project
into several components, with each component having its
own resource file. Each component was built as a DLL -
the main SMS OEM DLL contained just the UI extensions,
and other 'helper' DLLs provided services such the ability
to read and write SMS objects to the SMS database. Each 
developer had the responsibility for 'switching in' her
own resource handle whenever she wanted to access resources
in her own resource file, while saving the previously-set 
resource handle. Then, when she was finished, she was responsible 
for putting back the previously-set resource handle.

e.g. before using any resources you'd do something like:

	HINSTANCE hOldResources = AfxGetResourceHandle() ; 
	AfxSetResourceHandle(GetDllHandle()) ;

(GetDllHandle() is just a fn. in the DLL which returns a HINSTANCE 
hDLL which is assigned in the DLL's InitLibrary() )

and then, when finished, you'd do something like:

	// Put back the standard SMS resource handle
	AfxSetResourceHandle(hOldResources) ; 

I can't say this was completely trouble-free - developers had to 
ensure that every return path from a resource-using fn. put back
the previously-set resource handle - but it worked reasonably
smoothly. It might be useful if, like us, you can't control
the resource IDs used by other components of the complete 
application.  

    
    	Thanks for that. I have been out so I only just got to this.
    	Yes, there are some natural lines drawn across our project
    	already, so dividing it up looks easy.
    
    	So we would have 4 makefiles, one main and 3 subprojects?
    	Then I insert the subprojects into the main project?
    
    	Sounds neat.
    
    Cheers,
    Paul

    
    >>       So we would have 4 makefiles, one main and 3 subprojects?
    
    Yes.
    
    >>       Then I insert the subprojects into the main project?
    
    When a I said subprojects I didn't mean the Microsoft subproject stuff.
    We didn't find that they solved the resource/makefile accessability
    problems. Maybe they do now - we started the project some time ago.
    
    Our subprojects are, as far as the development studio is concerned,
    separate projects.
    
    The main project simply links against the static libs produced by the
    subprojects. This is done by including the .lib files in the main
    project.
    
    Some of this is difficult to describe, if you want to see how it
    works in practice I could give you a demo.
    I'm in Reading, Digital Park 2 @ F/H9.
    
    Richard.
    
    

Re: .3

We also didn't use Visual C++ sub-projects, and we used
nmake external makefiles rather than Visual C++ internal
makefiles - this was mainly to allow us use the same makefiles
on Intel and Alpha, although we had a small number of modules
that we also needed to build on various UNIXes (obviously,
these didn't include the modules using Windows resource
files.)

I'm in ILO (Galway, Ireland) so its probably not that
convenient for a demo :-)

    	To add to this note as to how to stop resource.h serialising
    	your development....
    
    	Visual SourceSafe 5.0 (runs with VC4.2 as well) has a very nice
    	Visual Merge facility to handle multiple checkouts which seems
    	to solve the serial development problem. We moved to multiple
    	projects as suggested, but still had a lot of contention.
    
    Cheers,
    Paul