#131 wxStaticBoxSizer highlight error

v1.0_(example)
open
nobody
5
2014-07-15
2014-02-05
sodev
No

Highlighting of items inside a wxStaticBoxSizer is currently wrong, the item highlights are drawn at wrong positions.

You can produce this by adding a top level element, e.g. a frame, add a vertical wxBoxSizer, add 3 buttons, add a vertical wxStaticBoxSizer and add 3 buttons inside it. Now select a button inside the wxStaticBoxSizer and you see that the red highlight is drawn under one of the buttons outside of the wxStaticBoxSizer.

The change of r2159 uses the wxStaticBox as parent for the items inside a wxStaticBoxSizer, the highlighting code searches the parent element of the item to highlight but uses the wxFormBuilder Object hierarchy and the wxStaticBox isn't part of it. The code will find the panel below the wxStaticBox and draw on it using the coordinates of the item which are relative to its wxWidgets parent which is the wxStaticBox. So if the wxStaticBox isn't the top left most item in the underlying panel the coordinates are wrong, like in the example above.

I tried to fix the wxStaticBoxSizer item rendering problem before you commited your fix and my solution was to convert the item coordinates to screen coordinates and these back to client coordinates of the item where the highlight is drawn on, the attached patch contains this change.

However this doesn't fix the problem i still have here on windows, the highlights are getting overwritten. When running a debug compile of wxFormBuilder you can see that the designer window gets painted multiple times and the highlights get overwritten during some of these paints. I currently don't know if its a problem of wxFormBuilder or wxWidgets, you can however see that the highlights survive in one case: select an item inside a wxStaticBoxSizer, minimize the wxFormBuilder window and restore it, the highlights are there. Select any other item and they disappear again :/.

1 Attachments

Discussion

  • Alexey Elizarov

    Alexey Elizarov - 2014-07-14

    I can suggest another solution.

    I tried to finish installation of the wxStaticBoxSizer's StaticBox window in the painting hierarchy, what r2159 began to do.

    I've made the following modifications:
    - Event handler is installed for wxStaticBoxSizer's StaticBox window, as for COMPONENT_TYPE_WINDOW's window etc. (PushEventHandler() / PopEventHandler()).
    - In VisualEditor::OnObjectSelected() the wxStaticBoxSizer's StaticBox is used as the selPanel for the wxStaticBoxSizer. There are two inserts: the parent component search is stopped at wxStaticBoxSizer as if it were COMPONENT_TYPE_WINDOW, and the selPanel is set to wxStaticBoxSizer's StaticBox for the found wxStaticBoxSizer.
    - The wxWidgets 3.0.1 is patched to handle event.Skip() of WM_PAINT properly under MSW port. Issue #16381 (http://trac.wxwidgets.org/ticket/16381).

    I tested this patch under MS Windows 7, compiler: MS Visual Studio 2010, wxFormBuilder: r2187.

    issue131-trunk-2187.patch is for wxFormBuilder: svn://svn.code.sf.net/p/wxformbuilder/code/3.x/trunk r2187.
    msw_paint_tags_3_0_1.diff is for wxWidgets 3.0.1.

     
    Last edit: Alexey Elizarov 2014-07-14
  • Alexey Elizarov

    Alexey Elizarov - 2014-07-15

    I have an amendment. The "issue131-trunk-2187.patch" patch doesn't handle drawing of blue box around wxStaticBoxSizer correctly. The new "issue131-trunk-2187-2.patch" has a correction.

    • In DesignerWindow::HighlightSelection() for m_selSizer of wxStaticBoxSizer type the coordinates of m_selSizer are transformed to coordinates of m_actPanel via screen coordinates, as in the Sodev's "sbox_highlight.patch". (In the patched code in case of wxStaticBoxSizer the m_actPanel is not a parent of m_selSizer as it is for other sizer types.)
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks