Up-Arrow / Down-Arrow Keys in Combo Box

Hello
 Whether I launch either a ListPresenter or ChoicePresenter with a
Combo box view, doing an up-arrow will show the first element of the
list in a edit area, with the element hi-lighted.

But this does not appear to trigger  #selectionChanged,
#selectionChanging: or #valueChanged, respectively.

I'm writing an application that needs to detect that the presenter's
'view text' has visually changed, either by User keyboard entry or User
clicking drop down, or up-arrow / down-arrow  and immediately counts
the string size, even before the presenter has not lost focus.

I've added 'Editable Combo Box' events #cbnEditChange and
#cbnEditUpdate, per LSumberg extension 'The Personal Money Application'
and tried modification to class 'ChoiceTextPresenter' per C. Demers
work. But cannot seem to keep the presenter's 'view text' synchronized
to the ListPresenter selection or ChoicePresenter value.

So far the only way kludge I found was to use a TextPresenter which is
physically superimposed on a ListPresenter.Drop down list or
ChoicePresenter.Drop down list.

So that handler for #valueChanged events for the TextPresenter does the
counting.
and the only thing the ListPresenter or ChoicePresenter do is to 'feed'
the TextPresenter with
the user #selection or #value, respectively.

But besides being ugly, now I have two presenters physical where I
expected to have one to do the job.

Any thoughts appreciated.
ACG

acg wrote:

>  Whether I launch either a ListPresenter or ChoicePresenter with a
> Combo box view, doing an up-arrow will show the first element of the
> list in a edit area, with the element hi-lighted.
>
> But this does not appear to trigger  #selectionChanged,
> #selectionChanging: or #valueChanged, respectively.

It works OK for me, with D5 or D6.  Are you perhaps listening for events
triggered off the View instead of the Presenter ?

For instance, this workspace code writes to the Transcript as expected:

    list := ListModel on: ((1 to: 100) asArray).
    lp := ListPresenter show: 'Combo box' on: list.

    h1 := [:ev | Transcript
                        display: #selectionChanging:;
                        space;
                        display: ev;
                        cr].
    h2 := [Transcript display: #selectionChanged; cr].
    h3 := [Transcript display: #actionPerformed; cr].

    lp
        when: #selectionChanging: send: #value: to: h1;
        when: #selectionChanged send: #value to: h2;
        when: #actionPerformed send: #value to: h3.

(And something similar works for ChoicePresenter too, including #valueChanged
events.)

    -- chris

Chris Uppal wrote:
... For instance, this workspace code writes to the Transcript as
expected:
> ...
Hi  Chris,
Yes, you're right. Your code was instrumental in showing where I was
de-synching.
Now, my code is doing what I wanted it to do. It turns out I needed to
only two triggers and two handlers.

 #editUpdate, which needed  'listPresenter view text', and
 #actionPerformed, which needed 'listPresenter selectionOrNil'

Each of which I could real-time verify by showing in a static text
presenter with #value:

It turns out that handling too many event caused view updates I could
not detect until using techniques in your code.

For example, I found that #editChange, #selectionChanged, and
#selectionChanging: could all adversely effect the synching of the
presenter  'view text' or 'selection'.

I modified your blocks such as: [Transcript show: lp selectionOrNil;
cr] to
 [Transcript show: lp selectionOrNil; show: ' =?= '; show: lp view text
; show: 'via #editChange'; cr. ] to see where 'lp selectionOrNil' and
'lp view text' did and did not match up to my thinking.

As far as ChoiceTextPresenter, it also needed only two events and
handlers:

 #editUpdate needs 'presenter view text'
 #actionPerformed needs 'presenter value'

My project has cardContainers with 5 contains, for a over 30
ListPresenters in all.
My coding is now greatly simplified.

Thanks for putting in the time.
ACG