Steve wrote:
> Paul Heinz said..
> >I haven't been following this thread that closely but is there a
> >reason you can't just use tests that always test against explicit mrYes?
> >
> >Seeing as clicking the [x] box returns a ModalResult of 0 (from memory),
> >it's still a distinct value different from mrYes.
>
> The result returned is mrCancel which, in this case was not one
> of the buttons and we had only tested if it was mrNo - which it
> wasn't so the code incorrectly went ahead assuming the user
> selected mrYes. Just a wee trap is all and I thought it worth
> repeating on here.
Ah, that's right - I had a look at Dialogs.pas again - it maps WM_CLOSE to
mrCancel.
I'm so used to writing confirmation dialogs (we had them in our DOS apps as
well) that
I test against mrYes without thinking about it now.
> >> We also figured it wouldn't take much to write our own MessageDlg
> >> - but again we had to slap ourselves around the head a few times
> >> repeating "Don't re-invent the wheel" until we accepted what was
> >> given to us to work with.
> >
> >IMO, that's a somewhat limiting attitude.
> >
> >We decided to reimplement our own MessageDlgHtml so that we
> >could have Profax standard glyphs and keyboard handling on the
> buttons and
> >pass in
> >which button to focus and an optional HelpTopic for our HtmlHelp.
> >
> >MessageDlg is a pretty small wheel and it's not at all hard to
> copy the code
> >and tweak it.
>
> As I said Paul, "it wouldn't take much to write our own.."
> however, I'm a great believer in using the model we have been
> given. Much though I hate the Microsoft Windows model and some of
> it's idiotics, it's what the user knows and expects.
I suppose that's where we differ philosophically. I also take the model
given as a (sometimes flawed) tool. If the tools does the job then fine,
but if it's needs tweaking and the benefit outweighs the cost, make
(or find) a better tool.
> It's also very easy to get tied up with writting lots and lots of
> nifty code that takes all our time away from writing the
> application itself. We have such a large application that all our
> time is being used up in making enhancements and additions to the
> application itself, if we even start down the road to writing our
> own standard dialogs then we may produce nicer dialogs but the
> users will suffer as we will have neglected the application
> itself to do something that it already does.
Yes, I know this argument. But balance the cost of writing the 'nifty code'
against time spent by developers fixing clobbered data, debugging strange
states, and support people talking users through avoidable ugliness.
The 'nifty code' _has_ got to pay for itself in the long run - and in my
experience, it usually does.
I guess it all depends on where you put your mental slider bar on the
'short term vs long term' payoff scale. And some management doesn't always
understand this engineering tradeoff issue - it can be a bit of a cultural
thing.
I also think it's useful to let developers scratch their 'craftmanship' itch
within reason. Happy developers who are really proud of their work are more
productive
developers in my experience.
> Besides, the idea of replacing all references to MessageDlg with
> MyMessageDlg in the amount of code we have here was a fairly
> daunting task.
Ah, IMO a global search and replace tool is essential for developing. We
use Visual SlickEdit ourselves but I'm sure other editors would suffice.
(choice of editors - now _there's_ a religious issue!)
Actually, I'm still somewhat suprised that Delphi hasn't surfaced a global
replace
since it was all their in the original BRIEF.
Sweeping through your source to replace a function (or component or property
value) with
a new value is something that just needs to be done sometime and having a
human being
do that is not a good use of developer resources - it's boring and you make
mistakes.
Now that Delphi 5 .DFMs are text - it's even easier. We wrote a simple
automated tool
to turn all the .DFMs into text, and then back again in the Delphi 4 days.
TTFN,
Paul.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
