Re: One resource file per CDialog or VSS solution

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.
joe

On Thu, 28 Aug 2008 23:42:07 +0200, "Serge Wautier" <serge@xxxxxxxxxxxxxxxxxx> wrote:

Tom, with no offense intented, this doesn't look very realistic to me. When
you either build or maintain a big project, there will always be times where
someone needs to touch some part of the program and someone else needs to
touch another part, both involving a dialog, menu item, whatever...

Enabling the 'Multiple checkouts' option in VSS is IMO mostly required in
this exact scenario: modification of resources.

Back to the OP issue: I believe though that clashing dialog items ids are
not an issue as long as they don't belong to the same dialog. Which means
people must not modify the same dialog simultaneously (Tom in this scenario,
I agree with you).

Another possible clash is if both programmers create a dialog
simultaneously, risking of using the same dialog id. This happens less
often. But it does happen sometimes.
The first part of the solution to this problem is to **checkin resources as
soon as possible** in order to decrease the probability of a clash.
The second part consists in paying attention to the merge of the resources:
The 3-pane merging editor of VSS makes it easy to fix such collisions at
check-in/merge time.

The only part (IMHO) where avoiding collisions is harder is the string
table: Everybody just pours new strings in there by automatically
incrementing a shared index. Bad!
There again, there is an easy solution: Allocate a string id range to each
programmer. e.g.: Ekaris gets strings block 1000-1999, Joe gets 2000-2999
and Tom gets 3000-3999.
That way, you're sure you don't step on each other toes. Actually, we even
had an unused string with the programmer name at the beginning of each block
to make it easier to identiy a block.

I used this scheme in a 4 people team for years and it never failed on us.

My 2 cents,

Serge.
http://www.apptranslator.com - Localization tool for your MFC applications



"Tom Serface" <tom.nospam@xxxxxxxxxxxxx> wrote in message
news:491BD983-6374-4983-8DD7-C5D97A6A4E15@xxxxxxxxxxxxxxxx
You could do this by designating a range of resources that could be used
in each file, or better yet, just have one person changing the interface
at a time. It can work out well if only one person edits a particular
resource, but eventually there will be duplication of effort. My opinion:
In a well thought out project all of the UI can be done by one person at a
time. You can set up VSS to not allow others to check out a file that is
use by someone else. That kind of forces the issue.

Tom

"Erakis" <Erakis@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1DA8B0A2-F4AA-4478-B3CE-F4DA311DA98B@xxxxxxxxxxxxxxxx
Hi

Is there any way that each Dialog has their own resource file ?

I need that because I'm working on a big project having many dialog.
Actually we are 4 programmers building interfaces. To share code we are
using Visual Source Safe. The only problem is that we can't works on
interface design at same time because of Resource ID conflict !

Is someone having a solution ?

Best regards,
Martin

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: One resource file per CDialog or VSS solution
    ... Tom: We have about 200 dialogs and a very short delay to produce this big ... Another possible clash is if both programmers create a dialog ... The first part of the solution to this problem is to **checkin resources as ... there is an easy solution: Allocate a string id range to each ...
    (microsoft.public.vc.mfc)
  • Re: Confused about gcnew and object lifetime
    ... It's a different story when those programmers later go to an unmanaged environment, ... Being sloppy there means scarce system resources may remain locked indefinitely. ... In fact, in ..NET you can't deallocate memory, only the system can, but you still MUST deallocate resources. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: hour rate for a contract Mumps programmer
    ... organizations where I've bid $50/hour for remote contracts that I know ... where the customer will never have the resources ... M programmers are an even harder to find resource, ... I've never had to work for an hourly rate. ...
    (comp.lang.mumps)
  • Re: Server Control Deployment and Client Scripts?
    ... for these resources when they render the HTML tags. ... public string HandlerName ... private void ShowEmbeddedResources(HttpContext context) ... private void ExtractEmbeddedResource ...
    (microsoft.public.dotnet.framework.aspnet.buildingcontrols)
  • Re: OOP and memory management
    ... >> The are more resources that a single program must manage ... >> new programmers just means that they never get any experience ... >> all memory allocated must be deallocated. ... Read above where I said that the language ...
    (comp.programming)
Quantcast