Re: [XaraXtreme-dev] wxODComboBox (was ChildWindowFromPoint and other questions)

[Alex Bligh <alex@xxxxxxxxxxx>]

Mark,

> > I presume you have a source for your dialog in XRC. If so, I suggest
> > you just put a wxComboBox in for now which will send the appropriate
> > messages - that's what I did with the text tool stuff, Phil did
> > with a similar dropdown on the fill tool which wanted bitmaps etc.
> > These will send the correct kernel messages.
> In other words change the base class from DropDown to wxComboBox and get
> rid of DropDown-specific calls ? That won't be easy and we will have to
> add them later in order to support the drawing...

No, I meant just /use/ wxComboBox for now, to get things working. Obviously
you won't then see the colour patches on the drop down, but at least
things will get working. That's unless you want to work on wxODComboBox
etc. :-) Fixing it up later should be relatively easy.

You will not be able to usefully derive anything from wxComboBox
(as opposed to wxODComboBox) right now because it uses the GTK native
control, which doesn't support owner drawing (as far as I can tell).

> > The dropdowns are essentially combo boxes which are owner drawn.
> > I am looking to use wxODComboBox which the wx-dev folks are currently
> > thinking about putting in 2.7 (if so I shall port it into wxXtra
> > for compatibility).
>
> Is there any way to create owner draw combobox right now or should we
> wait until 2.7 ?

We don't have to wait until 2.7 release. We could incorporate wxODComboBox
right now (by putting the code into wxXtra) but I don't think that's a
great use of time as it is likely to be in flux as it gets pulled into
mainline. When it heads HEAD (which by the looks of things might be in the
next week or so) I was intending to take the version in HEAD and stick it
in wxXtra after doing any necessary 2.6.x backport work.

Then, once the API is clear, we need to work out whether we derive separate
classes from wxODComboBox (for fonts, colour drops, etc.) in which case
DialogManager may need to be altered a little so that the various calls to
populate the box can pass additional information (see the stubbed out
CustomComboBox calls), OR take the same approach as the other owner drawn
controls (e.g. wxCamDrawControl) and get DialogManager to pass redraw
(kernel) messages to the dialog itself. It would be equally possible to
make a composite of these arrangements so (for instance) derived classes of
wxODComboBox could do the drawing themselves, which is probably the best
route as I think it's likely to work best with the current code.

So whilst I don't think we should wait for 2.7 per-se, I was just saying
that if your aim is to get the colour picker working ASAP, I'd treat the
custom combo box stuff as a separate task. Don't let me discourage you from
working on it (in which case I'll take it off my list), it's just it has
wider significance.

By the way wxODComboBox also allows a measure of flexibility in terms
of the combo-boxes sizing that wxComboBox doesn't allow. As far as I can
see, they can get as small as wxTextControl, the pop-up button can be
resized, there's no reason the menu popped up cannot be wider the control
itself, and it will be possible to control the maximum height of the drop
down list without a scrollbar. All these are on Charles' must-have list,
so I propose that once wxODComboBox is in, we drop wxComboBox entirely
(even for non-owner drawn ones). Which should make Charles happy.

Alex