Creating a dialog that is not a subclass of Dialog

In an application, I have a number of classes that share much behaviour and
therefore are grouped in a hierarchy below a common abstract superclass,
which itself is a subclass of Presenter. They also share a view, created in
the abstract superclass. This view consists of two subviews, one that is the
same for all subclasses and one that is created dynamically by each
subclass.

One of the classes below the abstract superclass is actually a dialog, but
because of the common behaviour it seems much easier to copy some methods
from Dialog to that class, than to remove that class from the hierarchy and
put it below Dialog and then copy all the common behaviour to it, especially
since the behaviour is still in developement and therefore changes a lot.

The methods that I have copied so far are Dialog class>>showModalOn:, the
variable Dialog.ownerView and it's accessor methods, and Dialog>>showShell
and Dialog>>showModal. When trying to show the class with the copied
behaviour, I get the error message "ContainerView does not understand
#showModalTo:" which seems logical, since the view shared by all my
subclasses of course is a ContainerView. Is there a way of dynamically
changing the ContainerView into a DialogView when that subclass is shown, or
do I have to copy the view to the subclass manually and change the
ContainerView to a DialogView in the ViewComposer? Because I am still
changing the common view a lot, it would be easier to do this
programmatically.

Best regards,

Mikael Svane

Mikael,

> Is there a way of dynamically
> changing the ContainerView into a DialogView when that subclass is shown,
or
> do I have to copy the view to the subclass manually and change the
> ContainerView to a DialogView in the ViewComposer? Because I am still
> changing the common view a lot, it would be easier to do this
> programmatically.

Two things come to mind, but that's not to say there is not to say that you
can't acheive what you want.

First, you might put most of your logic in a presenter, and use a reference
view to place it in a dialog.  I have done that in a few situations, and
don't much care for it, mostly because it makes things difficult to follow,
_except_ when the presenter in question is used in multiple places, in which
case the indirection is the price one pays for reuse.

Second, you could create an emulated Dialog, which amounts to making
presenter understand #showModalTo:.  It really should not be that hard to
do - easy to say of course, since I am putting you up to it :)  If you
decide to tackle it, take a look at the Window Builder documentation that is
hopefully still available with Smalltalk Express.  Toward the back of the
manual, there is a discussion of modality.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> Second, you could create an emulated Dialog, which amounts to making
> presenter understand #showModalTo:.  It really should not be that hard to
> do - easy to say of course, since I am putting you up to it :)

OK, I like a challenge ;o)

I've been using emulated modality for a while, mainly to enforce transaction
boundaries in my ReStore product. I've wrapped the various methods up in a
package which you can find here:

http://www.solutionsoft.co.uk/widgets/modal.zip

Check the package comment for examples of how to use it. There are essentially
two parts to the package - first, emulated modality that allows any Shell
subclass to be opened modally. For good measure, I've also included an emulated
"task modal" function - not pretty, but can be useful with particularly
recalcitrant users...

The second part allows any Presenter to be opened in a modal shell, complete
with OK and Cancel buttons. I've not actually used this as much as I thought I
would (partly because I've been adding modeless-dialog support to ReStore, but
mostly I find I need more sophisticated functionality), but it can occassionally
save adding an extra Dialog subclass.

Please regard this as a work-in-progress, so use at your own risk and please let
me know of any problems.

Best regards,

John Aspinall
Solutions Software
http://www.solutionsoft.co.uk

John,

Thanks, this was exactly what I was looking for. I will let you know if I
encounter any problems.

Best regards,

Mikael Svane

John,

> OK, I like a challenge ;o)

How many wishes do I get? :)


> I've been using emulated modality for a while, mainly to enforce
transaction
> boundaries in my ReStore product. I've wrapped the various methods up in a
> package which you can find here:
>
> http://www.solutionsoft.co.uk/widgets/modal.zip

Thanks!!!


> The second part allows any Presenter to be opened in a modal shell,
complete
> with OK and Cancel buttons. I've not actually used this as much as I
thought I
> would (partly because I've been adding modeless-dialog support to ReStore,
but
> mostly I find I need more sophisticated functionality), but it can
occassionally
> save adding an extra Dialog subclass.

Dumb question: this is the purpose of SurrogateDialog, which is not really a
Dialog at all, right?  When I first started reading the code, I was
wondering whether you had indeed created a generic native dialog; it appears
you have not gone that route.


> Please regard this as a work-in-progress, so use at your own risk and
please let
> me know of any problems.

What is your license agreement?  With EditableListView, the phrase about not
being able to charge for source bothered me a bit.  Is that intended simply
as a non-compete constraint (e.g. "don't start charging for my free
goodies"), or does it taint any source code that uses it?  Put another way,
can I use your code in large projects and then sell them?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> Dumb question: this is the purpose of SurrogateDialog, which is not really a
> Dialog at all, right?

Yes, this provides the OK and Cancel buttons, hosts the chosen presenter and
provides the glue to make it work. For no particular reason I chose to make it a
subclass of Shell rather than Dialog, and use my emulated modality to drive it.

> What is your license agreement?  With EditableListView, the phrase about not
> being able to charge for source bothered me a bit.  Is that intended simply
> as a non-compete constraint (e.g. "don't start charging for my free
> goodies"), or does it taint any source code that uses it?

Most definitely the former rather than the latter.

> Put another way, can I use your code in large projects and then sell them?

Absolutely - I'd be delighted if you did!

Best regards,

John Aspinall
Solutions Software
http://www.solutionsoft.co.uk

John,

> Yes, this provides the OK and Cancel buttons, hosts the chosen presenter
and
> provides the glue to make it work. For no particular reason I chose to
make it a
> subclass of Shell rather than Dialog, and use my emulated modality to
drive it.

It sounds like a good test of the emulation.


> > Put another way, can I use your code in large projects and then sell
them?
>
> Absolutely - I'd be delighted if you did!

Great!  However, I (read the lawyers who keep me out of trouble) would be
more comfortable with the thought if you'd embed the agreement in the
package comment, and add a sentence indicating the spirit in which you
intend the restrictions.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> Great!  However, I (read the lawyers who keep me out of trouble) would be
> more comfortable with the thought if you'd embed the agreement in the
> package comment, and add a sentence indicating the spirit in which you
> intend the restrictions.

I'm a little busy at the moment, but check the downloads after the weekend -
this should be done by then.

Best regards,

John Aspinall
Solutions Software
http://www.solutionsoft.co.uk