From WxWiki
Jump to: navigation, search

wxFrameLayout manages containment and docking of control bars, which can be docked along the top, bottom, right, or left side of the parent frame. Most GUI API's support some form of drag and drop controls such as toolbars and docking panels. There are draggable toolbars in Windows Forms but not docking panels, though you can see docking panels used in applications such as Visual Studio where you can drag the solution explorer and property panels around.

Experiences of some oddities

Docking library in contrib. wxFL hasn't been actively developed for some time, aside from a few minor patches now and again. Therefore, you might want to check out one of the following libraries

   * WxIFM, which allows more advanced layouts than wxFL,
   * WxDockIt, a simpler but (reportedly) less buggy one
   * WxAUI, a new frame/toolbar docking library

See also: wxFrameLayout generated docs


Until version 2.2 of wxWidgets you had to download it separately, now you'll find it in the directory contrib/src/fl. Building is straightforward as you already know it from building wxWidgets. If you have done the ./configure ; make dance (Unix and alikes) you need to do a simple make ; make install ; ldconfig in the FL source directory to build and install FL.


Next you should build and execute the sample applications in the contrib/samples/fl directory, to check if building was successful and to get a first impression about FL

How to use it

The idea behind FL is, to place a sort of layout manager between the frame window and it's children (probably only a wxPanel or wxMDIClientWindow or so, which then contains the real interesting stuff).

So take this imaginary MyFrame constructor for an MDI app (I stripped all the unneccesary stuff here)

 MyFrame::MyFrame(...) : wxMDIParentFrame(...)
   wxMDIClientWindow *pClient=GetClientWindow();
   m_pLayout=new wxFrameLayout(this, pClient);

Now we placed a layout manager just between a window and it's child. The usage of the child remains completely unchanged, so in this mannor FL is transparent to use. However we still want to populate the now existing space for toolwindows with those. But in the sense of modularity also FL does this not alone, but relies on 'plugins' to do it's job. Since there are always standard plugins to load the convenience function wxFrameLayout::PushDefaultPlugins will do this for us. There also a few other plugins we want to have, since they make the whole thing really tasty.

   m_pLayout->AddPlugin( CLASSINFO ( cbAntiflickerPlugin ) ); // This adds a nice doublebuffering
   m_pLayout->AddPlugin( CLASSINFO( cbBarHintsPlugin ) ); // This gives us toolbar handles as known from VC++
   m_pLayout->AddPlugin( CLASSINFO( cbRowDragPlugin ) ); // You know the Netscape Communicator Row Draggers, here's the FL version

Now we can populate the whole thing. This is simply done with the function wxFrameLayout::AddBar(wxWindow *pWindow, cbDimInfo dim_info, int alignment, int column, int row, wxString title, BOOL spy, int inittial_state ); For this example I'll use the first 2 parameters.

   m_pLayout->AddBar(new wxTextCtrl(this), cbDimInfo(50,50,50,50,50,50));

The first parameter is obvious. The second gives just the initial sizes of the toolwindow when docked horizontally, docked vertically and free floating. There's also the possibility to supply an own function, which determines this on the fly, but I didn't use it until now, so I can't tell you about this. The rest is the usual.

   wxMenu *file_menu=new wxMenu;
   file_menu->Append(wxID_EXIT, _("E&xit"));
   wxMenuBar *menu_bar = new wxMenuBar;
   menu_bar->Append(file_menu, _("&File"));

Now you have a small application with a freely placeable, dockable and floatable text control. Not very usefull, but you know the way.

The Oddities

Unfortunately there seem to be some bugs (or are these features). For example, when trying to set the initial state of a toolwindows to wxCBAR_FLOATING, or when doing this using wxFrameLayout::SetBarState the specific toolwindow just vanishes, really strange.

Another oddity is, that I were not able to float a toolwindow when using wxGTK, while it works just perfectly under Win32. I don't understand this, since the toolbars of the normal wxToolBar class, which creates a GTK toolbar, are perfectly floatable under wxGTK. Also the miniframe example shows, that reparenting is no problem under wxGTK so this cannot be the reason, too.

Under win32 using FL in combination with wxUniv, toolbar buttons are not displayed correctly. Trying to drag the 'collapse'-handle of a closed tool-bar does crash the application.


FL is just a great library, even with it's oddities, so just use it in your apps.

See Also