Subject: Re: Non-modal dialogs. They work!
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Thu May 11 2000 - 10:36:52 CDT
On Thu, 11 May 2000, Mike Nordell wrote:
>
> Do you really think we're gonna have that many dialogs open at the same
> time that it's worth a hash-map? :-)
> I think a simple list with id, ptr pairs would do nicely. But it's a good
> idea to base it on the dialog id.
The main reason I like the hashtable is because ut_hashtable class does
everything I want. I don't have to worry about house keeping after
deleting id's from the table etc. It's simple to code, is unlikely to go
wrong and is not performance penalty. (Yes I'm lazy, isn't that one of the
requirements of a good programmer)
>
> With this kind of new approach, maybe it's better to redesign a bit to
> let all non-modal dialogs have protected or private constructors, and
> only allow them to be created from a factory. In that case, this new
> dialog-creation-factory and override its public virtual createDialog
> method. It could then check its internal map if the dialog exists and in
> that case activate it, or else call the factory class' protected function
> _createDialog to create it. This class of course have to be owned by
> XAP_App (singleton).
>
Ah the wisdom of a C++ god:-) 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 :-)
As it stands I think I can get the code into "insert_Symbol" to implement
the dialog-activation-if-possible-else-creation within a couple of days.
Actually the code is pretty simple. Just some calls to remeber the id and
widget pointer after the dialog is created, the code to activate the
dialog if it is already running. (We have this already elsewhere in abi).
And the code to remove the id and pointer from the hashtable upon
termination.
After that I'll see if I can work out a way to generalize it all into a
runModeless class - unless you'd like to do it :-)
In any case someone will have redo the other platform front end. Did you
think your job was over Thomas?
> Just an idea that struck me.
>
> While at it, should we have two dialog baseclasses, one that is modal and
> one that is non-modal, or should we have one baseclass that supports both
> modal and non-modal dialogs?
>
For simplicity I would go for two seperate classes with a lot of code cut
and pasted into the runModeless. If someone else does the work and can
think of a clever way to have modal and nonmodal derived from a common
class. That is beyonf me at this stage in my C++ career.
Cheers
Martin
This archive was generated by hypermail 2b25 : Thu May 11 2000 - 10:37:12 CDT