From: Vadim Zeitlin on
On Thu, 07 Jun 2007 09:08:51 -0700 Robin Dunn <robin(a)alldunn.com> wrote:

RD> > I haven't tested this on any platform except Windows, but because of
RD> > the symptoms I am pretty sure it's windows specific and is related to
RD> > the windows event loop. I've also only tested with wxPython but
RD> > wxPython doesn't appear to add any extra code to the C++ objects
RD> > involved beyond normal wrapping.
RD>
RD> It is Windows specific, and has been a known problem for a long time.
RD> You've already discovered the workaround that is normally suggested,
RD> which is to just embed the combo in a panel and put that in the htmlwindow.

I wonder if wxHtmlWindow could do this automatically. I admit that I have
absolutely no idea why does this happen but then I don't remember looking
into it in details neither, I guess I automatically skipped it being
HTML-specific. Robin, do you have any pointers to the past discussions?

Thanks,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-unsubscribe(a)lists.wxwidgets.org
For additional commands, e-mail: wx-users-help(a)lists.wxwidgets.org

From: "Chris Mellon" on
On 6/7/07, Vadim Zeitlin <vadim(a)wxwidgets.org> wrote:
> On Thu, 07 Jun 2007 09:08:51 -0700 Robin Dunn <robin(a)alldunn.com> wrote:
>
> RD> > I haven't tested this on any platform except Windows, but because of
> RD> > the symptoms I am pretty sure it's windows specific and is related to
> RD> > the windows event loop. I've also only tested with wxPython but
> RD> > wxPython doesn't appear to add any extra code to the C++ objects
> RD> > involved beyond normal wrapping.
> RD>
> RD> It is Windows specific, and has been a known problem for a long time.
> RD> You've already discovered the workaround that is normally suggested,
> RD> which is to just embed the combo in a panel and put that in the htmlwindow.
>
> I wonder if wxHtmlWindow could do this automatically. I admit that I have
> absolutely no idea why does this happen but then I don't remember looking
> into it in details neither, I guess I automatically skipped it being
> HTML-specific. Robin, do you have any pointers to the past discussions?
>
> Thanks,
> VZ
>

With Robins reminder, I was able to find the discussion in my
archives. It's the good old windows-specific WM_SIZE wierdness with
combo boxes.

There was a fix for it that went in, but it was backed out because it
broke wxComboBox on win2k.

The root cause is that SetSize() with the same size isn't a noop for
wxChoice (because the base class implementation that should make it
one in wxWindow doesn't work because of the win32 wierdness).
wxHtmlWidgetCell resizes it's controlled widget in response to paint
events, size events to the wxChoice issue a paint event to the parent,
and that just spins overloading the event loop.

Using a panel to nest around the control bypasses the behavior because
now it's the wxPanel being resized, and it correctly noops the second
SetSize call.

There was some discussion in a thread titled "[wxMSW2.6.2, MINGW] BUG
in wxChoice / wxComboBox used with wxHTML", but the archive search
isn't showing up.

---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-unsubscribe(a)lists.wxwidgets.org
For additional commands, e-mail: wx-users-help(a)lists.wxwidgets.org

From: "Chris Mellon" on
On 6/7/07, Chris Mellon <arkanes(a)gmail.com> wrote:

> There was some discussion in a thread titled "[wxMSW2.6.2, MINGW] BUG
> in wxChoice / wxComboBox used with wxHTML", but the archive search
> isn't showing up.
>

Found it on gmane:

http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/71765/focus=71810

---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-unsubscribe(a)lists.wxwidgets.org
For additional commands, e-mail: wx-users-help(a)lists.wxwidgets.org