Keeping a desired size might be as simple as adding a
surrounding container, but hopefully Gary can provide a #preferredExtent or
something, that when notNil fixes the size of a window w/o the need to "waste a
widget." It took a little while to get it right, but Dolphin has long done
a nice job of that - no great surprise really. As a grateful friend, not
only does the current situation force the user to chase the buttons between
panes, it also looks like we don't know how to fix the size (which
coincidentally is the case, however temporary it might be<g>).
Having views that _can_ size themselves is great; we should not need
to rely on it when building for end users.
I have not had much time for
GUIs in Pharo, but I already miss MVP. Gary is probably the best person to
comment on whether your data manipulation methods are redundant or belong at a
more abstract level. I think it has to be one or the other, as getting
data into and out of controls is not specific to wizards. If you have done
it well, we should probably spread it around; if there are better ways to do the
job, we should note that and you should eventually/gradually move toward the
better approach. Repeating myself a little, I really like value
models and adapters for matching domain objects to controls.
Thanks
for doing this!
Bill
Hi,
Thanks for your comments.
I have changed the default buttons to 'Next >>' and '<<
Back'.
I have not yet find how to fix the same size to all panes. For the moment
I'm using a 'PluggableDialogWindow' that I open in a StandardWindow
(StandardWindow new openModal: dialogWindow). Doing this, the pane is
automatically resize according the elements of the dialogWindow.
But indeed, it would maybe be more usefull for the user to click the
next buttons one after the others without moving the moose according the resized
pane.
WizardPart is not so specific to the wizard hierarchy:
-> There is the two methods 'outputValue' and 'retrieveInputRequired'
that make the link with a cooresponding wizard pane , but they are abstract
methods. Therefore, you can retrieve the inputs in the way you want and make
what you want with the output.
-> The other link is a kind of control for enabling the next button of
the wizard pane. By default, it's an instance variable set to true, so you can
not take care of that.
A lot of subclasses of WizardPart I made don't retrieve any input and don't
care about the next button. You can create instances and directly have the morph
contents (with the method 'contents').
I agree for the LastPane. For example, in the addition, soustraction, ...
wizard example, a LastPane could have been the selection of the last
element of the operation, and after that we could have a pane that simply
display the result (without any control). However, the first pane diplayed in a
wizard will allways look like a FirstWizardPane (or maybe a customized version
of it).
2009/11/23 Schwab,Wilhelm K
<bschwab@anest.ufl.edu>
If I understand you, that's not a good idea: the last pane
in the sequence is not necessarily the last step in the wizard. I have
examples in Dolphin that branch depending on user's choices along the way, and
sometimes it reaches a close with additional panes remaining in the list, but
those are for "the road not taken."
Bill