That does help. Will give it a shot.
Thanks
On 6/27/05, Robin Pellatt <pellatt@mirocs.com> wrote:
> Here's a suggestion which may give you a good compromise:
>
> The first thing you need to arrange is to make sure that you totally separate
> all your logic from your form code. So let's say you have an OnButton1Click()
> event handler, then you just delegate this straight down to another class that
> knows nothing about the GUI. In this way, you minimise the amount of code
> affected by the next step.
>
> So, you have your main trunk, and you create the bugfixing branch. You now have
> two versions of the form, which can't be merged. OK, there doesn't seem to be a
> better solution, so we'll just have to accept that for the actual forms
> themselves, you'll need to add any bugfixes to both branches manually. However,
> due to what we did before, this should be a minimal amount of work, as I guess
> the form itself shouldn't change too much just for bugfixes.
>
> Any logic changes are totally separate from the forms now, and can be merged
> with SVN in the usual way.
>
> I have a similar setup with Borland C++ Builder, and although I haven't actually
> tried this on any branches, I guess it should work OK. It really depends how
> much your actual GUI changes for the bugfixes.
>
> BTW - your delegate class should know nothing about the form: I have a sort of
> triangle of classes created from the classic 'dependency inversion':
>
> Form1 - inherits and implements interface Form1View, also creates a
> Form1Presenter which is the delegate class, and passes itself to the presenter
> as a Form1View class.
>
> Form1View - provides simple access methods for setting stuff on the GUI, which
> are all pure virtual, and none of which have any GUI knowledge in, e.g. just
> SetProgressValue(int val) or something like that.
>
> Form1Presenter - implements the actual logic behind the events it gets from
> Form1, and updates the form via the view class.
>
>
> I don't know VB so I don't know if you could do the same, but I hope that helps
> somewhat,
>
>
> Robin.
>
>
> BTW - you'd be better off over on the Subversion list with this, it's not really
> a Tortoise question.
>
>
> John Browne wrote:
> > Depending on what controls you have on the form, they are necessary.
> > Not every form will require them. However, some forms will have
> > controls that save their "settings" in these frx files. The control
> > will have an offset value for it's settings in the frm file. This
> > tells VB where to look for that control's settings in the frx file.
> > It seems to me that MS could have done the same thing with a
> > text-based file (ini, xml, etc), encoding anything that needed to
> > actually be binary. But hey, what do I know... :-)
> >
> >
> > On 6/27/05, SteveKing <steveking@gmx.ch> wrote:
> >
> >>John Browne wrote:
> >>
> >>
> >>>So, without branching/merging what I'm gathering is, you guys would
> >>>assign *forms* to specific people, and let them be the only ones to
> >>>manage those forms. They would have to manually keep separate copies
> >>>of the forms based on whether or not they are working on a bugfix for
> >>>a current release, or adding new functionality for the next release.
> >>>
> >>>If I go with this, would there be a better way to setup the repository
> >>>layout other than the standard "/branches", "/tags", and "/trunk"
> >>>directories? There would be no branching/merging, so should there be
> >>>directories for each developer maybe? "/dev1", "/dev2", etc?
> >>
> >>I'm not sure, but are the frx files really necessary? I always thought
> >>you could compile a VB6 program even without those. AFAIK, those files
> >>are just auto-generated by the form designer for internal use (i.e. it
> >>keeps the guidance grid, lines, ... but not the actual form).
> >>
> >>I may be wrong though...
> >>
> >>Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jun 27 20:27:21 2005