ComboBoxes and lack of documentation

Gah damnit.

I'd like this Dolphin thing more if there was any sense of documentation
around the place.

Trying to get a simple ($**&#( combo box to work and theres pain and
suffering all around.

My model object has a serviceDomain and serviceDomainChoices variables.  
serviceDomain is a text string, serviceDomainChoices is a ListModel on:
OrderedCollection of text strings.

When the model is initialized, serviceDomain is read from the registry,
and serviceDomainChoices is populated from a hardcoded list of domains.

My shell includes

createComponents
  ...
  serviceDomains := self add: ChoicePresenter new name: 'serviceDomains'

model:
  ...
  serviceDomains model: (self model aspectValue: #serviceDomain).
  serviceDomains choices: self model serviceDomains.


Which results in the following:

2:58:59 PM, Monday, October 04, 2004: 'Not found: etxt.co.nz'
ComboBox(Object)>>errorNotFound:
[] in ComboBox(BasicListAbstract)>>selection:
[] in ComboBox(BasicListAbstract)>>selection:ifAbsent:
ListModel(SequenceableCollection)>>indexOf:ifAbsent:
ListModel(SequenceableCollection)>>keyAtEqualValue:ifAbsent:
EqualitySearchPolicy>>keyAtValue:in:ifAbsent:
ListModel>>keyAtValue:ifAbsent:
ComboBox(BasicListAbstract)>>handleFromObject:ifAbsent:
ComboBox(BasicListAbstract)>>selection:ifAbsent:
ComboBox(BasicListAbstract)>>selection:
ComboBox(BasicListAbstract)>>selectionOrNil:
ChoicePresenter>>updateChoice
ChoicePresenter>>view:
[] in SMSComposerSettingsShell(Presenter)>>attachSubPresenterViews:
OrderedCollection>>do:
SMSComposerSettingsShell(Presenter)>>attachSubPresenterViews:
.......

Bah - serviceDomains -does- include the item 'etxt.co.nz' as I can
inspect it and see it right there, what gives?  If I comment out the
call to #choices in #model everythings fine ( sans any choices in the
combobox that is ).

Arrrrg.

It sure would be nice having some documentation, theres the "education
center" for Dolphin 4, which hardly has anything of use ( when it comes
to the MVC components ), and no documentation for Dolphin 5 - will
Dolphin 6 actually have documentation?

On Mon, 04 Oct 2004 15:03:18 +1300, Mark Derricutt <[hidden email]>  
wrote:

>
> Bah - serviceDomains -does- include the item 'etxt.co.nz' as I can  
> inspect it and see it right there, what gives?  If I comment out the  
> call to #choices in #model everythings fine ( sans any choices in the  
> combobox that is ).

If you look at the last 2 lines of the stack trace that I have truncated,  
you can see that its using a EqualitySearchPolicy, so  
ListModel>>on:searchPolicy: should help.

--
Regards
HweeBoon
MotionObj

On Mon, 04 Oct 2004 10:54:40 +0800, Yar Hwee Boon <[hidden email]>  
wrote:

Realised something was wrong, and came back to look again. Ignore my  
comment about the stack. But using ListModel>>on:searchPolicy: does solve  
the problem. Also, if you look at ChoicePresenter>>initialize, you can see  
that it actually already wraps the #choices: argument into a ListModel  
(equality), so you do not need to actually wrap your list with a ListModel  
yourself (unless you also need to use it say, in a ListPresenter). Hope  
that didn't confused you :)


--
Regards
HweeBoon
MotionObj

Yar Hwee Boon wrote:

> Realised something was wrong, and came back to look again. Ignore my  
> comment about the stack. But using ListModel>>on:searchPolicy: does
> solve  the problem. Also, if you look at ChoicePresenter>>initialize,
> you can see  that it actually already wraps the #choices: argument
> into a ListModel  (equality), so you do not need to actually wrap your
> list with a ListModel  yourself (unless you also need to use it say,
> in a ListPresenter). Hope  that didn't confused you :)

That sounds like great consistency ;-)

I got around it with:

  serviceDomains := ListModel on: OrderedCollection new searchPolicy:
SearchPolicy equality.

which I found mentioned at
http://www.mindspring.com/~lsumberg/Dolphin/PersonalMoney/Part2.htm.

Mark Derricutt wrote:

> Gah damnit.
>
> I'd like this Dolphin thing more if there was any sense of documentation
> around the place.

Did you read the class comment for ChoicePresenter ?  That makes it fairly
clear that the #choices should be a Collection, rather than needing to be a
ListModel.  Since you are (unnecessarily) using an extra ListModel, the comment
for that class is worth reading too -- admittedly it's a bit elliptic, but it
/does/ mention the search policy and what that means.


> Which results in the following:
>
> 2:58:59 PM, Monday, October 04, 2004: 'Not found: etxt.co.nz'

Ah, you are from the future, that explains it ;-)   And if it was really 3 AM,
then that also explains why you didn't just debug:

> ListModel>>keyAtValue:ifAbsent:

which would have shown you the problem -- difficult to think straight when you
should be asleep, though.


> It sure would be nice having some documentation, theres the "education
> center" for Dolphin 4, which hardly has anything of use ( when it comes
> to the MVC components ), and no documentation for Dolphin 5 - will
> Dolphin 6 actually have documentation?

Andy has posted the odd link to bits of the D6 documentation, so I am
hopeful...

    -- chris

Chris Uppal wrote:

>Did you read the class comment for ChoicePresenter ?  That makes it fairly
>clear that the #choices should be a Collection, rather than needing to be a
>ListModel.  Since you are (unnecessarily) using an extra ListModel, the comment
>  
>
To be honest no I didn't.  I always forget they're there, mostly cause
there hidden away from view when I'm not used to seeing them, stuck away
in that extra tab isn't very memorable when you end up with lots of
windows around the place.

And yes, having looked at the comments it clearly shows using #choices,
yet that would appear to be demonstrating using ChoicePresenter in a
standalone/popup dialog fashion, not as a control on a view - which
isn't tied to the model directly via #choices.

As for the extra ListModel.  I believe I only started ( or had ) that in
my code cause that's what was shown in some tutorial code I found, which
I recall an earlier post in here regarding a different issue I had being
told was deprecated and no longer used ( and the cause of my then problem ).

Now my problem appears to be that my model objects mutator isn't being
called with the newly selected value for some reason.  i.e. show the
view with options a, b, and c.  b is from the model, select c, close the
view and watch my mutator being with b as a paramater, not c as
expected.  Mmmmm.

>Ah, you are from the future, that explains it ;-)   And if it was really 3 AM,
>then that also explains why you didn't just debug:
>  
>
Well I'm definitely in the future ( GMT+1300 ), but it wasn't 3am, 3pm
actually, but a lack of coffee and fustration didn't help...

>>which would have shown you the problem -- difficult to think straight when you
>>should be asleep, though.
>>    
>>
May have shown the problem, but unless you understood it - wouldn't lend
you to a solution...

>>to the MVC components ), and no documentation for Dolphin 5 - will
>>Dolphin 6 actually have documentation?
>>    
>>
>Andy has posted the odd link to bits of the D6 documentation, so I am
>hopeful...
>  
>
Heres hoping....  Hopefully my fustrations will go away soon....

And to think...  I find Java/Swing alot LESS fustrating than this...

On Mon, 04 Oct 2004 20:34:13 +1300, Mark Derricutt <[hidden email]>  
wrote:

Wow, honestly I find that's amazing.

--
Regards
HweeBoon
MotionObj

Mark Derricutt wrote:

[Re: class comments]
> [...]  I always forget they're there, mostly cause
> there hidden away from view when I'm not used to seeing them, stuck away
> in that extra tab isn't very memorable when you end up with lots of
> windows around the place.

Yes, I have suggested several times that the class browser should default to
showing the class comment (which is useful) rather than the class definition
expression (which is not).


> And yes, having looked at the comments it clearly shows using #choices,
> yet that would appear to be demonstrating using ChoicePresenter in a
> standalone/popup dialog fashion, not as a control on a view - which
> isn't tied to the model directly via #choices.

One of the things that may not be obvious is that if you #show[*] a presenter
class that is not a "Shell", then the system automatically creates a Shell to
hold it.  That is very convenient in testing out components because you don't
have to create your own test containers for everything.  That means that the
ChoicePresenter is working in the same way in a "normal" application --
embedded in a window -- as it would if driven from a workspace.   That's very
handy.

I /hope/ that the new documentation will make that clear, since I remember
clearly that it was one of the most confusing things about learning the Dolphin
GUI framework.  Not helped, of course, by the use of the word "Shell" -- which
is a term I had never seen before.


> Now my problem appears to be that my model objects mutator isn't being
> called with the newly selected value for some reason.  i.e. show the
> view with options a, b, and c.  b is from the model, select c, close the
> view and watch my mutator being with b as a paramater, not c as
> expected.  Mmmmm.

Odd.  I tried a quick test app which used the same sort of code as in your
earlier post, and it seems to work fine for me.

Or rather, there is one issue: you change the ChoicePresenter's #model and
#choices in two steps.  There's a potential problem if the new model's
#serviceDomain isn't a member of the old model's list of #serviceDomains.  I
hacked around that by doing the equivalent of:

        serviceDomains
            model: nil asValue;
            choices: self model serviceDomains;
            model: (self model aspectValue: #serviceDomain).

But what it really needs, I think, is for the ChoicePresenter API to be
extended to allow you to set both at once.  That's really for OA, but in the
interim, this seems to work

===================
ChoicePresenter>>model: aValueModel choices: aSequenceableCollection
    self noEventsDo:
        [choicesModel list: aSequenceableCollection.
        super model: aValueModel].
    self updateChoice.
===================

However, that's not the problem that you are currently seeing.  Can you create
a reproducible example ?  One thing to check is that you are remembering to do
the super-sends in methods like #onViewOpened, and so on, missing them out can
often have "subtle" effects like this.

    -- chris

Mark,

> Trying to get a simple ($**&#( combo box to work and theres pain and
> suffering all around.

Choice presenters are one of the more potentially frustrating GUI
elements.  I suspect that much of your trouble is addressed in this
thread, but there is one thing that might eventually bother you: the
need to set choices and value in one operation.  I have placed some (use
at your own risk) code below.



> It sure would be nice having some documentation, theres the "education
> center" for Dolphin 4, which hardly has anything of use ( when it comes
> to the MVC components ), and no documentation for Dolphin 5 - will
> Dolphin 6 actually have documentation?

This is tough, because you have grounds to complain.  But how much does
OA have to write in order to "have documentation"?  How many people
would actually read it?  IMHO, a lot of learning Smalltalk is in fact
unlearning bad habits learned elsewhere.

Unfortunately, GUI programming (and external interfacing in general) is
not nearly as forgiving as most Smalltalk work.  A GUI is also the first
thing people want to create - admit it :)  That is in part because it
provides visual feedback, in part because in C*, "you have to have a
program in order to start debugging", and in part to see whether this
Smalltalk thing can produce real software.

Beginners would be much better off if they could accept that the GUI
will indeed work, and instead start with some unit testing of their
domain classes.  However, that would require a lot of trust (and we have
not yet had an opportunity to earn it from a newbie), and further
requires an understanding of Smalltalk's incremental development and
that the debugger is our friend[*].  The more experience the newbie has
with "mainstream" languages, the harder that sell will be.  It gets
worse, because once one starts to realize that a "program" isn't
necessary, then the fears about ever deploying an exe surface.

[*] one time the debugger is not your friend is when you see it during
presenter/view construction.  I generally get ready to do a test, save
the image, and then exit w/o saving if anything goes wrong.

Have a good one,

Bill

======================================

!ChoicePresenter methodsFor!

choices:aSequenceableCollection value:anObject nilChoice:newNilChoice
        "Set both the choices and the value of the receiver.  This allows for the
        case in which the intended new value is not a member of the current
choices.
        Note that the new value and new nil choice (if not nil) must be included in
        the new choices collection."

        "The new nil choice and value must be in the new choices collection;
blow up early if either is not"
        ( Array with:newNilChoice with:anObject ) do:[ :each |
                each notNil ifTrue:[
                        ( ListModel
                                "4.01
                                with:aSequenceableCollection
                                searchPolicy:self viewModel searchPolicy"
                                on:aSequenceableCollection
                                searchPolicy:self viewModel searchPolicy
                        ) keyAtValue:each
                ].
        ].

        "Are the new choices different from what we have already?"
        self viewModel list = aSequenceableCollection ifFalse:[
                "We have to change, but, but value might already be a valid choice"
                self viewModel
                        keyAtValue:anObject
                        ifAbsent:[
                                "The new intended value is not a valid choice in the current choices;
                                need a temporary bogus value"
                                self nilChoice:nil.
                                self value:nil.
                        ].

                "Set the nil choice, the new choices"
                nilChoice := newNilChoice.
                self choices:aSequenceableCollection.
        ].
       
        "Finally set the new value"
        self value:anObject.

        "8-00 having problems with niled value leaving previous value visible,
at least when
        using drop-down combo box."
        self view invalidate; update.


! !
!ChoicePresenter categoriesFor:
#choices:value:nilChoice:!accessing!public! !
!ChoicePresenter methodsFor!

choices:aSequenceableCollection value:anObject
        "Set both the choices and the value of the receiver.  This allows for the
        case in which the intended new value is not a member of the current
choices.
        Note that the new value and (preserved) nil choice (if not nil) must be
included in
        the new choices collection.  Keeps the same comparison policy."

        ^self choices:aSequenceableCollection value:anObject nilChoice:nilChoice
! !
!ChoicePresenter categoriesFor: #choices:value:!accessing!public! !




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

Chris Uppal wrote:

>Odd.  I tried a quick test app which used the same sort of code as in your
>earlier post, and it seems to work fine for me.
>  
>
Just a quick reply here for now.  I just made up a simple test
model/view to try and reproduce this last problem I was having but
couldn't, it worked as expected.  Grr. so tracing back the difference I
found the following:

MyModel>>addServiceDomain: aServiceDomain
    ^self serviceDomains add: aServiceDomain

In my initialise I was calling this simple helper routine to populate
the serviceDomains list, and whilst the list was being populated, was
causing the oddness I was seeing.

serviceDomains := OrderedCollection new.
.....
addServiceDomain: 'etxt.co.nz'.

When I got rid of this and just used;

serviceDomains := OrderedCollection new.
serviceDomains add: 'etxt.co.nz'.

Everything seemed to work fine.

Odd.

"Mark Derricutt" <[hidden email]> wrote in message
news:cjsebo$[hidden email]...
I can never accept oddities, especially ones like that. If you'd like to
post some more of your code then we can tell you what the difference is and
thus hopefully help your understanding.

Regards

Blair