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
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.
> 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.
Chris Uppal wrote:
... For instance, this workspace code writes to the Transcript as
Yes, you're right. Your code was instrumental in showing where I was
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;
[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