CBN_DROPDOWN

Andy and Blair,

I am working on something that (unless you have a better suggestion) needs
to populate a drop-down combo box any time the user causes the list to drop.
First, any thoughts on whether that's safe from a re-entrance perspective?
Windows doesn't always like stuff like this =:0

The good news is that it seems simple enough.  What do you think of the code
below?

Have a good one,

Bill

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

!ComboBox methodsFor!

cbnDropDown
 "Private - A CBN_DROPDOWN has been received by our parent window."

 #wksDangerous.
 ^self presenter trigger:#cbnDropDown.
! !
!ComboBox categoriesFor: #cbnDropDown!event handling-win32!private! !



!ComboBox class methodsFor!

initialize
 "Private - Initialise the receiver's class variables.
  ComboBox initialize
 "

 #wksDangerous.

 CbnMap :=  IdentityDictionary new
   at: -1 put: #cbnErrSpace;
   at: 1 put: #cbnSelChange;
   at: 2 put: #cbnDblClk;
   at: 3 put: #cbnSetFocus;
   at: 4 put: #cbnKillFocus;

   "wks CBN_DROPDOWN 7"
   at: 7 put: #cbnDropDown;

   shrink;
   yourself.

 Modes := #(simple dropDown dropDownList)! !
!ComboBox class categoriesFor: #initialize!initializing!private! !

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

"Bill Schwab" <[hidden email]> wrote in message
news:b5tjjk$2cqqjv$[hidden email]...
> Andy and Blair,
>
> I am working on something that (unless you have a better suggestion) needs
> to populate a drop-down combo box any time the user causes the list to
drop.
> First, any thoughts on whether that's safe from a re-entrance perspective?
> Windows doesn't always like stuff like this =:0

True, but that is quite rare. The only specific examples I can think of are
related to the deletion of items inside the notification about that item
(e.g. deleting a tree view item on receiving a "label-edited", i.e. rename,
event). In this particular case I imagine that populating the drop-down list
only when it is actually about to be dropped is a fairly common usage
pattern, so it is probably that it will work. The best way to find out is to
test it, probably with SUnit.

>
> The good news is that it seems simple enough.  What do you think of the
code
> below?

Certainly you could get it working like this. Thinking about it from the
point of view of incorporating it into the MVP framework one perhaps needs
to consider which object in the triad is responsible for populating the
drop-down, and when. In effect you are triggering a view specific event
(#dropDown) off a generic presenter to which that event may not always
apply.  In fact since you are populating the view's list on each drop-down,
I presume it isn't working off one of the standard presenters? Is there a
need for a specialised presenter to handle the dynamic population of the
list, or is it really a case of implementing a "virtual" style list where
the reason you want to populate it dynamically is because of the expense of
generating/adding the items? If you were not using a drop-down list, but a
normal ListView, how would you do it? Are there any other use cases?

Regards

Blair

Blair,

> Certainly you could get it working like this. Thinking about it from the
> point of view of incorporating it into the MVP framework one perhaps needs
> to consider which object in the triad is responsible for populating the
> drop-down, and when. In effect you are triggering a view specific event
> (#dropDown) off a generic presenter to which that event may not always
> apply.  In fact since you are populating the view's list on each
drop-down,
> I presume it isn't working off one of the standard presenters?

Correct - it's a subclass of ChoicePresenter.

> Is there a
> need for a specialised presenter to handle the dynamic population of the
> list, or is it really a case of implementing a "virtual" style list where
> the reason you want to populate it dynamically is because of the expense
of
> generating/adding the items?

I haven't gotten to the expense part, and that might become prohibitive.
However, a subclass is probably the easiest approach because this is
something that needs a fair amount of context to select the correct items,
and I want it to be easy to code because a ViewGenerator subclass will churn
out many of them, and even more so because I need to tell the generator how
to write the code.  I'd much prefer any changes to be in one place that I
can simply edit/accept vs. having to edit the code that writes the code and
then regenerate lots of stuff.


> If you were not using a drop-down list, but a
> normal ListView, how would you do it? Are there any other use cases?

In that case, it would probably need to be a modal prompter, and that might
end up being the best approach.  I wanted to at least try drop downs because
they worked nicely in a similar situation.

Have a good one,

Bill

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