If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
the toolbar is created correctly, but some elements of other controls are shifted (for exaple 'x' mark of child frames are displayed below its normal position). Also the main control of the frame is partially displayed on the statusbar.
I tried to place above code in different places (before and after creating wxIFM controls) but nothing works.[/code]
The toolbar looks ok without wxIFM and with only the main control. I initialize wxIFM in the same way as it is done in wxIFM demo (after the above code, in the constructor of the frame).
Has wxIFM got a problem with toolbars? Could anyone (kolo?) show a whole frame constructor with initialization of the wxIFM and toolbar?
Unfortunately, this is caused by a design problem in wxWidgets. The Frame offsets the client area when it is managing a toolbar and moves the position of (0,0) within the client area. When painting to the frames DC however, (0,0) is in a different spot. wxIFM assumes that (0,0) on the DC is in the same spot as (0,0) in its client area, which is untrue. The fact that wxFrame messes up the client area so much completely confuses wxIFM which causes the errors that you see. Its going to be really anoying to fix properly, because there is no way to add a global offset to children or painting within wxIFM, and all of its positioning code relies on the fact that (0,0) in a DC is in the same spot as (0,0) in the client area.
SnakeChomp wrote:Its going to be really anoying to fix properly, because there is no way to add a global offset to children or painting within wxIFM, and all of its positioning code relies on the fact that (0,0) in a DC is in the same spot as (0,0) in the client area.
This means that standard wx toolbars are not supported and a new wxIFM compatible toolbar widget is needed?
It means that wxFrame is doing stupid things which confuses wxIFM. The real fix is to fix wxFrame, but it would be backwards incompatible and I know the wx guys would never agree to it. I'm looking into hacking wxIFM to work around the defect in wxFrame.
Ok, I have thought of a workaround for this problem. If you create a wxPanel as the only child of the wxFrame, and tell wxIFM to manage this panel, everything will work fine. Position (0,0) on the panels client area is in the same location as position (0,0) in the panels client DC, so wxIFM will behave. I have tested this locally with the wxIFM sample and it works just fine. The only thing that won't work is the wxInterfaceManager::SetStatusMessagePane and related functions. To use them, the window that wxIFM is managing must be a wxFrame. This is an oversight on my part and will be corrected in a future release; you will give wxIFM a pointer to the toolbar to use for status messages as well as telling it what status pane.
vasek wrote:Great! But is the toolbar dockable? Your screenshot doesn't say so
No. This would just be a regular wx toolbar. wxIFM does not support dockable toolbars in a way I am satisfied with so as far as I am concerned it does not support dockable toolbars.