Subject: Re: Non-modal dialogs. They work!
From: Mike Nordell (firstname.lastname@example.org)
Date: Fri May 12 2000 - 01:36:03 CDT
Martin Sevior wrote:
> The main reason I like the hashtable is because ut_hashtable class does
> everything I want.
OK, I wasn't aware of that one.
> I had actually thought that something like
> this would be the RIGHT way to do this but I'm afraid my C++ skills
> will be sorely streched (but no doubt improved) in implementing this.
> Do you want to do it? It would probabally speed things up by a week :-)
It's your idea, you go ahead. If you're uncertain of some design
decisions there's always abiword-dev to turn to.
> For simplicity I would go for two seperate classes with a lot of code
> cut and pasted into the runModeless.
That's one way. Another possibility is to subclass modalDialog and
nonModalDialog from a common baseclass that contains this common code.
Sure it will need some rewrite, but so long as the interface for the
current dialog class don't change it's just a recompile.
> If someone else does the work and can think of a clever way
> to have modal and nonmodal derived from a common class.
It's certainly possible (I've done it), but it's more a question of focus
(not View focus). You could think of a "non-modal" dialog as displaying
one behaviour (being non-modal) and a non-modal as another. On the other
hand you could think of it like "it's a dialog, I don't see any
difference between it being modal or non-modal".
For simplicity we should probably keep them apart since the non-modal
dialog class probably have "a bit" more bookeeping to do, but I still
think it wold be beneficial to have them inherit a common baseclass which
This archive was generated by hypermail 2b25 : Fri May 12 2000 - 00:36:48 CDT