Re: One resource file per CDialog or VSS solution

Wow ! Exactly what I need as response Serge :)
Very detailled and appreciated. I like the id range idea.

Tom : We have about 200 dialogs and a very short delay to produce this big
project and. Also the major work goes on presentation (UI). Beleive me 4
programmers building interface insn't to much. But I'm agree with you that
two programmer cannot works at same time on same dialog...

Thanks to all of you
Best regards,

"Serge Wautier" 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



.

Relevant Pages

  • Re: One resource file per CDialog or VSS solution
    ... via member variables, a dialog never needs to see any variables of the application. ... 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 ... Actually we are 4 programmers building interfaces. ...
    (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: 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)
  • Re: can project autoassign?
    ... > time I adjust anything I have to manually juggle a bunch of assignments to ... >> Andy Barnhart wrote: ... group rather than resources as individuals. ... For example, let's say you have 5 programmers, 3 of them are ...
    (microsoft.public.project)
Loading