[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

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


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.