display glitches on wxpython 2.9.3 (comparing to 2.9.2)

Hi all,
after upgrading to wxpython 2.9.3.1 from 2.9.2.4, I am experiencing
some display glitches in my older app, which closely resemble the
problems of the (almost) same gui on the move from wxpython 2.8 to 2.9
some time ago, mentioned in an older thread:
http://groups.google.com/group/wxpython-users/browse_thread/thread/10a0600a57059702

Basically, many widgets are not displayed at first (checkboxes,
buttons, listctrls. scrollbars in textctrls), and even after
refreshing the screen (e.g. by moving a mouse over the widgets, or
overlying the frame with another app temporarilly) there are missing
scrollbars, listcontrols etc.

Older screenshots documenting the issue on the 2.8 - 2.9 transition
illustrate exactly the current state too:
http://www.vbr.wz.cz/wxpy-tmp/test-wx-2-9.html
(Only that the - correct - gui labeled as 2.8 in the screenshots
correspond with my current app using 2.9.2.4, while the buggy display
was run with 2.9.3.1 now.)

In the previously mentioned case, the visual problems were gone
mysteriously after commenting out the line:
inner_Panel.SetBackgroundColour("#D4D0C8")

Unfortunately, in the current version, I am not able to find any such
"solution"; I am almost sure, there would be something wrong in the
code (sizers, parenting, refreshing?), but I can't find anything
relevant.
The further information about the app in question, the messiness of
the code and the difficulties of creating a concise sample mentioned
in the cited thread still apply for the current state.

However, while some kind of breakage was maybe partly expectable
between 2.8 and 2.9, it seems surprising between the minor versions.

Were there maybe some changes, which could be relevant for this
change? (I unfortunately could not find anything similar in the Recent
Changes, which would seem similar to this.)
Could id be, that wx become somehow less tolerant to some previously
accepted non-standard code?

(Using python 2.7.2 on win XP Czech with the classic theme (however
the XP theme behaves the same in this respect).

Thanks in advanced for any hints,
   regards,
       Vlastimil Brom

Not that I know of. Have you been able to come up with a small standalone example that demonstrates this problem that we can take a look at and experiment with?

···

On 1/5/12 5:34 PM, Vlastimil Brom wrote:

Hi all,
after upgrading to wxpython 2.9.3.1 from 2.9.2.4, I am experiencing
some display glitches in my older app, which closely resemble the
problems of the (almost) same gui on the move from wxpython 2.8 to 2.9
some time ago, mentioned in an older thread:
http://groups.google.com/group/wxpython-users/browse_thread/thread/10a0600a57059702

Basically, many widgets are not displayed at first (checkboxes,
buttons, listctrls. scrollbars in textctrls), and even after
  refreshing the screen (e.g. by moving a mouse over the widgets, or
overlying the frame with another app temporarilly) there are missing
scrollbars, listcontrols etc.

Older screenshots documenting the issue on the 2.8 - 2.9 transition
illustrate exactly the current state too:
test - gui - wx-2-9
(Only that the - correct - gui labeled as 2.8 in the screenshots
correspond with my current app using 2.9.2.4, while the buggy display
was run with 2.9.3.1 now.)

In the previously mentioned case, the visual problems were gone
mysteriously after commenting out the line:
inner_Panel.SetBackgroundColour("#D4D0C8")

Unfortunately, in the current version, I am not able to find any such
"solution"; I am almost sure, there would be something wrong in the
code (sizers, parenting, refreshing?), but I can't find anything
relevant.
The further information about the app in question, the messiness of
the code and the difficulties of creating a concise sample mentioned
in the cited thread still apply for the current state.

However, while some kind of breakage was maybe partly expectable
between 2.8 and 2.9, it seems surprising between the minor versions.

Were there maybe some changes, which could be relevant for this
change? (I unfortunately could not find anything similar in the Recent
Changes, which would seem similar to this.)
Could id be, that wx become somehow less tolerant to some previously
accepted non-standard code?

--
Robin Dunn
Software Craftsman

Thanks Robin,
in my experimenting with the code, the magic (or woodoo coding or ...)
seems to be partly effective in this case too...
the current issue appears to be not less unclear, than the previous
one concerning the wxpython 2.8 - 2.9 migration.

Also in this case, the problem appears to be solved (hopefully) after
removing other SetBackgroundColour(...) calls, namely: ...
.SetBackgroundColour("#D4D0C8"), used previously on the main_frame,
outer_panel, scroll_win; (on inner_panel, the colour setting was
removed with the previously mentioned change (wx 2.8 -> 2.9). The
containers are parented in this order; all actual widgets are children
of inner_panel and are laid out using nested (Static)BoxSizers.
The only drawback of this appeared as an incompletely redrawn areas
below the comboboxes, which, however are displayed ok after adding an
extra call of main_frame.Update().

There might be some other interferences, with wx.stc.StyledTextCtrl as
after replacing this widget the display problems were gone or reduced
while experimenting.
However, after removing the mentioned background colour setting, the
gui is displayed ok, even in with the original widgets.
I am fairly confident, that there are likely to be bugs in my code
rather than in the wx library, although I don't understand, how
setting the background colour could possibly be relevant.
In case, it might be of interest, there is a shortened code attached,
which displays the same problems, I do apologize in advance for the
code style and quality, as this respective app is only being adapted
gradually over years and hasn't been refactored sofar ...

Thanks for any suggestions,
   regards
   Vlastimil Brom

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
#! Python
# -*- coding: utf-8 -*-

# sample gui-only code to demonstrate unusual display glitches in wxpython 2.9.3

# uncommenting any of the below lines causees display glitches on
wxpython 2.9.3.1 and is ok on 2.9.2
# frm.SetBackgroundColour("#D4D0C8")
# outer_panel.SetBackgroundColour("#D4D0C8")

# uncommenting the line:
# inner_panel.SetBackgroundColour("#D4D0C8")
# causes the same glitch even on 2.9.2 and is ok (like the above) on wx 2.8

# after commenting out the creation and sizer addition of stc_txt, the
gui is ok,
# even after uncommenting all the SetBackgroundColour calls mentioned above

# in wx 2.9.2 and 2.9.3 (unlike 2.8), there is a minor glitch under
the combobox,
# which disapears after frm.Update() in the original app, but not in this sample

# there might be other unspecific bug causing the windows error message
# about invalid memory access instruction - after closing the python
stdout window; closing the gui works ok.

# tested on Win XP, Python 2.7.2

import wxversion
# wxversion.select('2.8')
# wxversion.select('2.9.2')
wxversion.select('2.9.3')
import wx
import wx.stc

appl = wx.App(redirect=False)
frm = wx.Frame(None, -1, "TextRiX")
# !!!!!!!!!!!
# frm.SetBackgroundColour("#D4D0C8")
outer_panel = wx.Panel(frm, -1)
# !!!!!!!!!!!
# outer_panel.SetBackgroundColour("#D4D0C8")
scroll_win = wx.ScrolledWindow(outer_panel, -1, (0, 0), (-1,-1),
wx.BORDER_SUNKEN)
inner_panel = wx.Panel(scroll_win, -1)
# !!!!!!!!!!!
# inner_panel.SetBackgroundColour("#D4D0C8")
scroll_win.SetVirtualSize((-1,-1))
scroll_win.SetScrollRate(20,20)

frm_box_prog = wx.StaticBox(inner_panel, -1, u" text analysis")
frm_box_search = wx.StaticBox(inner_panel, -1, u" search ")
combo_box = wx.ComboBox(inner_panel, -1, u"", (-1, -1), (150, -1))
check_box = wx.CheckBox(inner_panel, -1, u" ?? ")
button_search = wx.Button(inner_panel, -1, u"search")
frm_box_conc = wx.StaticBox(inner_panel, -1, u" concordance")
listCtrlOdkazyKonk = wx.ListCtrl(inner_panel, -1, (-1,-1), (-1,100),
style=wx.LC_REPORT|wx.LC_HRULES|wx.LC_VRULES)
listCtrlOdkazyKonk.InsertColumn(0, u"word",-1,180)
listCtrlOdkazyKonk.InsertColumn(1, u"freq",
format=wx.LIST_FORMAT_RIGHT,width=40)
txt_ctrl = wx.TextCtrl(inner_panel, -1, style=wx.TE_MULTILINE | wx.TE_RICH2)
# !!!!!!!!!!!
stc_txt = wx.stc.StyledTextCtrl(inner_panel, -1)

sizer_frm = wx.BoxSizer(wx.HORIZONTAL)
sizer_frm.Add(outer_panel, 1, wx.EXPAND)
frm.SetSizer(sizer_frm)

sizer_outer_panel = wx.BoxSizer(wx.HORIZONTAL)
sizer_outer_panel.Add(scroll_win, 1, wx.EXPAND)
outer_panel.SetSizer(sizer_outer_panel)

sizer_scroll_win = wx.BoxSizer(wx.HORIZONTAL)
sizer_scroll_win.Add(inner_panel, 1, wx.EXPAND)
scroll_win.SetSizer(sizer_scroll_win)

sizer_search = wx.StaticBoxSizer(frm_box_search, wx.HORIZONTAL)
sizer_search.Add(combo_box, 0, wx.EXPAND)
sizer_search.Add(check_box, 0, wx.EXPAND)
sizer_search.Add(button_search, 0, wx.EXPAND)

sizer_txt = wx.BoxSizer(wx.HORIZONTAL)
# !!!!!!!!!!!
sizer_txt.Add(stc_txt, 0, wx.EXPAND)
sizer_txt.Add(txt_ctrl, 0, wx.EXPAND)

sizer_conc_content = wx.BoxSizer(wx.HORIZONTAL)
sizer_conc_content.Add(listCtrlOdkazyKonk, 1, wx.EXPAND)
sizer_conc_content.Add(sizer_txt, 0, wx.EXPAND)
sizer_conc = wx.StaticBoxSizer(frm_box_conc, wx.VERTICAL)
sizer_conc.Add(sizer_conc_content, 1, wx.EXPAND)
sizer_prog = wx.StaticBoxSizer(frm_box_prog, wx.VERTICAL)
sizer_prog.Add(sizer_search, 0, wx.EXPAND)

sizer_prog.Add(sizer_conc, 2, wx.EXPAND)
sizer_main = wx.BoxSizer(wx.VERTICAL)
sizer_main.Add(sizer_prog, 1, wx.EXPAND)
inner_panel.SetSizer(sizer_main)

frm.SetClientSize
((inner_panel.GetBestSize()[0]+4,inner_panel.GetBestSize()[1]+4))# ??
scrollbars adjustment
frm.Show(True)
# !!!!!!!!!!!
# frm.Update()

appl.MainLoop()

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

sample_gui_wx_2_9_3_problems.py (3.72 KB)

···

2012/1/6 Robin Dunn <robin@alldunn.com>:

On 1/5/12 5:34 PM, Vlastimil Brom wrote:

Hi all,
after upgrading to wxpython 2.9.3.1 from 2.9.2.4, I am experiencing
some display glitches in my older app, which closely resemble the
problems of the (almost) same gui on the move from wxpython 2.8 to 2.9
some time ago, mentioned in an older thread:

http://groups.google.com/group/wxpython-users/browse_thread/thread/10a0600a57059702

Basically, many widgets are not displayed at first (checkboxes,
buttons, listctrls. scrollbars in textctrls), and even after
refreshing the screen (e.g. by moving a mouse over the widgets, or
overlying the frame with another app temporarilly) there are missing
scrollbars, listcontrols etc.

Older screenshots documenting the issue on the 2.8 - 2.9 transition
illustrate exactly the current state too:
test - gui - wx-2-9
(Only that the - correct - gui labeled as 2.8 in the screenshots
correspond with my current app using 2.9.2.4, while the buggy display
was run with 2.9.3.1 now.)

In the previously mentioned case, the visual problems were gone
mysteriously after commenting out the line:
inner_Panel.SetBackgroundColour("#D4D0C8")

Unfortunately, in the current version, I am not able to find any such
"solution"; I am almost sure, there would be something wrong in the
code (sizers, parenting, refreshing?), but I can't find anything
relevant.
The further information about the app in question, the messiness of
the code and the difficulties of creating a concise sample mentioned
in the cited thread still apply for the current state.

However, while some kind of breakage was maybe partly expectable
between 2.8 and 2.9, it seems surprising between the minor versions.

Were there maybe some changes, which could be relevant for this
change? (I unfortunately could not find anything similar in the Recent
Changes, which would seem similar to this.)
Could id be, that wx become somehow less tolerant to some previously
accepted non-standard code?

Not that I know of. Have you been able to come up with a small standalone
example that demonstrates this problem that we can take a look at and
experiment with?

--
Robin Dunn
Software Craftsman
http://wxPython.org

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Having just noticed this thread, I'm now watching it rather intently.
I had a very similar issue with some widgets not being fully drawn
(missing borders etc) until forced to refresh in some way such as
minimising and restoring the window. I assumed I had parenting issues
or such and the project got put on hold due to lack of time, but I was
using SetBackgroundColour on the panels containing the widgets, so it
could be related. I don't think I can contribute a sample app
demonstrating my own issue (not for a week or so at least), but I'll
be interested to see how this thread turns out.

Indeed, very weird... I'll poke at this a little and see if I can track down what's going on or perhaps find a better workaround.

···

On 1/6/12 1:03 PM, Vlastimil Brom wrote:

2012/1/6 Robin Dunn<robin@alldunn.com>:

On 1/5/12 5:34 PM, Vlastimil Brom wrote:

Hi all,
after upgrading to wxpython 2.9.3.1 from 2.9.2.4, I am experiencing
some display glitches in my older app, which closely resemble the
problems of the (almost) same gui on the move from wxpython 2.8 to 2.9
some time ago, mentioned in an older thread:

http://groups.google.com/group/wxpython-users/browse_thread/thread/10a0600a57059702

Basically, many widgets are not displayed at first (checkboxes,
buttons, listctrls. scrollbars in textctrls), and even after
  refreshing the screen (e.g. by moving a mouse over the widgets, or
overlying the frame with another app temporarilly) there are missing
scrollbars, listcontrols etc.

Older screenshots documenting the issue on the 2.8 - 2.9 transition
illustrate exactly the current state too:
test - gui - wx-2-9
(Only that the - correct - gui labeled as 2.8 in the screenshots
correspond with my current app using 2.9.2.4, while the buggy display
was run with 2.9.3.1 now.)

In the previously mentioned case, the visual problems were gone
mysteriously after commenting out the line:
inner_Panel.SetBackgroundColour("#D4D0C8")

Unfortunately, in the current version, I am not able to find any such
"solution"; I am almost sure, there would be something wrong in the
code (sizers, parenting, refreshing?), but I can't find anything
relevant.
The further information about the app in question, the messiness of
the code and the difficulties of creating a concise sample mentioned
in the cited thread still apply for the current state.

However, while some kind of breakage was maybe partly expectable
between 2.8 and 2.9, it seems surprising between the minor versions.

Were there maybe some changes, which could be relevant for this
change? (I unfortunately could not find anything similar in the Recent
Changes, which would seem similar to this.)
Could id be, that wx become somehow less tolerant to some previously
accepted non-standard code?

Not that I know of. Have you been able to come up with a small standalone
example that demonstrates this problem that we can take a look at and
experiment with?

--
Robin Dunn
Software Craftsman
http://wxPython.org

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Thanks Robin,
in my experimenting with the code, the magic (or woodoo coding or ...)
seems to be partly effective in this case too...
the current issue appears to be not less unclear, than the previous
one concerning the wxpython 2.8 - 2.9 migration.

Also in this case, the problem appears to be solved (hopefully) after
removing other SetBackgroundColour(...) calls, namely: ...
.SetBackgroundColour("#D4D0C8"), used previously on the main_frame,
outer_panel, scroll_win; (on inner_panel, the colour setting was
removed with the previously mentioned change (wx 2.8 -> 2.9). The
containers are parented in this order; all actual widgets are children
of inner_panel and are laid out using nested (Static)BoxSizers.
The only drawback of this appeared as an incompletely redrawn areas
below the comboboxes, which, however are displayed ok after adding an
extra call of main_frame.Update().

There might be some other interferences, with wx.stc.StyledTextCtrl as
after replacing this widget the display problems were gone or reduced
while experimenting.
However, after removing the mentioned background colour setting, the
gui is displayed ok, even in with the original widgets.
I am fairly confident, that there are likely to be bugs in my code
rather than in the wx library, although I don't understand, how
setting the background colour could possibly be relevant.
In case, it might be of interest, there is a shortened code attached,
which displays the same problems, I do apologize in advance for the
code style and quality, as this respective app is only being adapted
gradually over years and hasn't been refactored sofar ...

--
Robin Dunn
Software Craftsman