Hi folks A couple of questions: 1) I seem to get funny artifacts in the display of TreeCtrl, ComboBox and ListBox when the MDI child frame containing it is first painted (see attached - it should be two-root treeview, unopened). I''m not sure if it''s related to being in a MDI, but the controls sample looks OK. The artifacts are cleared up when it''s repainted or resized, but I was wondering if there was anything else I could do - even manually forcing the frame to repaint? I''m on WinXP Pro. 2) Would it be sensible to have methods like TreeCtrl#get_selection return Ruby''s nil rather than 0 if nothing is highlighted in the control. It feels more natural Ruby to me to write something like if sel = get_selection() ... rather than if sel = get_selection() and sel != 0 ... cheers alex -------------- next part -------------- A non-text attachment was scrubbed... Name: mdi_treeview_glitch.gif Type: image/gif Size: 8705 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20040522/4b6b846e/mdi_treeview_glitch.gif
alex fenton wrote:> 1) I seem to get funny artifacts in the display of TreeCtrl, ComboBox > and ListBox when the MDI child frame containing it is first paintedVery strange. If you could provide source code for a small sample that duplicates the problem it would be easier to debug. Otherwise, it would be interesting to know the sequence you use to initialize everything. For example, do you add the tree items before or after calling show on the MDI frame? Forcing a repaint is easy (call "refresh"), but the trick is figuring out when and where to make that call. I think I would need to understand a lot more about your app to figure out if there is a good place.> 2) Would it be sensible to have methods like TreeCtrl#get_selection > return Ruby''s nil rather than 0 if nothing is highlighted in the > control.Since the docs only say it will return "an invalid tree item", and since wxWindows itself returns NULL, it seems reasonable that we should return nil for that case. I added a bug at rubyforge for this. Thanks, Kevin
Hi>> 1) I seem to get funny artifacts in the display of TreeCtrl, ComboBox >> and ListBox when the MDI child frame containing it is first painted > > > Very strange. If you could provide source code for a small sample that > duplicates the problem it would be easier to debug.Thanks for your advice Kevin. I''ve attached some source code which duplicates the problem more simply. I''ve noticed the following: - The problem only appears when there''s borders given to the BoxSizer which is arranging the TreeCtrl (or ListBox...), and the glitchiness seems to get bigger as the borders get bigger. - It only appears when there''s another widget above the TreeCtrl in the sizer - It only apppears when in a MDIChildFrame (I think)> Forcing a repaint is easy (call "refresh"), but the trick is figuring > out when and where to make that call. I think I would need to understand > a lot more about your app to figure out if there is a good place.So far as I can tell from using my app, the tree and listboxes only get this "glitchy" look when they''re first painted. To be honest, I guess this might be a subtle bug, and might well be in the WxWidgets library rather than the Ruby bindings. I''d be quite happy with advice along the lines of ''do it this way instead'' or ''call refresh here''.> Since the docs only say it will return "an invalid tree item", and since > wxWindows itself returns NULL, it seems reasonable that we should return > nil for that case. I added a bug at rubyforge for this.Thanks very much Alex -------------- next part -------------- require ''wxruby'' ID_CREATE = 5 ID_CLOSE = 6 ID_EXIT = 99 class MyFrame < Wx::MDIParentFrame def initialize(title) super(nil, -1, title) @child_number = 0 menuFile = Wx::Menu.new menuFile.append(ID_EXIT, "E&xit\tAlt-X") menuMDI = Wx::Menu.new menuMDI.append(ID_CREATE, "&Add Child") menuMDI.append(ID_CLOSE, "&Remove Child\tCtrl-F4") menuBar = Wx::MenuBar.new menuBar.append(menuFile, "&File") menuBar.append(menuMDI, "&Window") set_menu_bar(menuBar) evt_menu(ID_EXIT) { close } evt_menu(ID_CREATE) { create_child } evt_menu(ID_CLOSE) { on_close_child } create_child end def create_child @child_number += 1 name = "Child #{@child_number.to_s}" frame = Wx::MDIChildFrame.new(self, -1, name) sizer = Wx::BoxSizer.new(Wx::VERTICAL) text = Wx::TextCtrl.new(frame, -1, ''Some text'') sizer.add(text, 1, Wx::GROW|Wx::ALL, 10) tree_ctrl = Wx::TreeCtrl.new(frame, -1) root_id = tree_ctrl.add_root(''ROOT'') tree_ctrl.append_item(root_id, ''FOO'') sizer.add(tree_ctrl, 1, Wx::GROW|Wx::ALL, 10) frame.set_sizer(sizer) end end class GlitchyApp < Wx::App def on_init MyFrame.new("MDI App").show() end end GlitchyApp.new.main_loop()
alex fenton wrote:> - The problem only appears when there''s borders given to the BoxSizer > which is arranging the TreeCtrl (or ListBox...), and the glitchiness > seems to get bigger as the borders get bigger. > - It only appears when there''s another widget above the TreeCtrl in the > sizer > - It only apppears when in a MDIChildFrame (I think)Nice job of narrowing it down. Unfortunately, I can''t reproduce the problem here. It may be simply because Linux doesn''t actually have MDI frames (it simulates them with tabs).> To be honest, I guess this might be a subtle bug, and might well be in > the WxWidgets library rather than the Ruby bindings. I''d be quite happy > with advice along the lines of ''do it this way instead'' or ''call refresh > here''.I suspect it is a wxWidgets problem, since wxRuby pretty much just passes everything through. I can''t think of a way right now to force a refresh. I''m sure there is one, but the best I can thing of is the absolutely hideous: set a timer for 100 ms, and when the timer goes off, resize the window slightly. Ugh. On the other hand, your diagnosis does suggest a couple ways that you might be able to work around it: Instead of putting the tree control directly into the sizer (with a border), you could try putting the tree control into a panel, and putting the panel into the sizer. You can try putting the border in when you add the tree, or when you add the panel. There''s a pretty good chance one of those will work correctly. An alternative would be to have both the tree control and the control above it in a panel, and add that panel to your sizer. Again, you could set the border when you add the controls to the panel, or when you add the panel to the main sizer. Hopefully one of those will work for you. If not, let me know, and I''ll think harder about how to cleanly trigger a refresh. Kevin
Hi Kevin Smith wrote:> I suspect it is a wxWidgets problem, since wxRuby pretty much just > passes everything through. I can''t think of a way right now to force a > refresh. I''m sure there is one, but the best I can thing of is the > absolutely hideous: set a timer for 100 ms, and when the timer goes off, > resize the window slightly. Ugh.Ditto> On the other hand, your diagnosis does suggest a couple ways that you > might be able to work around it: > > Instead of putting the tree control directly into the sizer (with a > border), you could try putting the tree control into a panel, and > putting the panel into the sizer. You can try putting the border in when > you add the tree, or when you add the panel. There''s a pretty good > chance one of those will work correctly.Thanks - putting it within a Panel fixed it for me first time.> An alternative would be to have both the tree control and the control > above it in a panel, and add that panel to your sizer. Again, you could > set the border when you add the controls to the panel, or when you add > the panel to the main sizer.Alex