By Robert O'Connor (robertoconnor)
This patch is a draft which successfully allows a wxArtProvider to serve out icons to bitmaps for XRC files.
The syntax to use a wxArtProvider bitmap is:
<bitmap stock_id="wxART_INFORMATION" stock_client="wxART_TOOLBAR">somefallbackicon.png</bitmap>
The bitmap is optional, and will only be used as a fallback image, if the wxArtProvider returned a wxNullBitmap for some reason.
The client attribute, if not specified, currently will be wxART_OTHER. Perhaps there should be a guessing heuristic of it being in a menu node to call wxART_MENU.
Usage of XRC resouces and wxArtProvider together can be seen in an updated /contrib/samples/xrc demo, which is a separate patch.
Search the wx-dev mailing lists for "wxArtProvider" and "XRC" for the full discussions on this feature's API design.
Applied patch [ 594932 ] Extended XRC XML resources sample
By Robert O'Connor (robertoconnor)
This is a more comprehensive introduction to how to get up and running using XRC in your new wxWindows project.
It describes both the basics (for new users) and advanced features. It consists of a demo of dialogs and frames loaded from XRC. Each dialog has a textctrl at the top of the dialog, which walks the new user through that feature.
There are 8 demos:
The 4 basic ones:
-A non-derived dialog, as typically used for an about dialog.
-A derived dialog that loads its resources from an XRC (a frequently-asked question on the mailing lists), and responds to some simple events, including the disable-another-control-via-EVT_UPDATE_UI that is another FAQ, and powerful and simple-to-use feature.
-A XRC reference "Controls" dialog, using a notebook. Each tab has a single control. All XRC handled widgets can be seen at a glance, and how to use them under XRC.
-An uncentered dialog, to demonstrate the easy use of <centered>1</centered> to automatically place a Dialog centered on its parent..
The 4 advanced ones:
-Embedding a custom class into an XRC dialog, by using the "unknown" class.
-Using wxArtProvider to use stock icons from within your your XRC resources.
-Using the platform attribute to selectively show a part of XRC based on the current OS.
-Runtime variable expansion (demo only. Not implemented at this time).
Also:
-The main frame is now demonstrated as being loaded as an XRC.
- The toolbar has longhelp tag demonstrated, and are hooked up to the same events as the menu to show how XRCID() works on the same tool and menuitem XRCID.
-Some custom icons for the demonstration were created, and put into the toolbar and menubar. A custom icon also for the demonstration.
-The example code has been put in 1 class per file (both .cpp and a matching .xrc), to make it much less confusing for a newcomer to figure out what class is what, expecially with all the wx macros for declaration and implementation.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@16542 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
1) There is a problem
in that floating frames are not currently supported
with !mRealTimeUpdates. We wrote a patch to correct
this problem. You will find it attached to this
posting.
Here is a description of what was changed and why. In
cbBarDragPlugin::ShowHint(), SetBarState is called
every time mpCurPane changes. This is correct.
However, this also happens every time, even if
mRealTimeUpdates is false. The state should not be
changed during the drag operation if mRealTimeUpdates
is off. This is corrected in this patch. Code was
also added in cbBarDragPlugin::OnLButtonUp() to
actually do the state changing, only if
mRealTimeUpdates is off. Normally, this is performed
in ShowHint if mRealTimeUpdates is on.
I also took the liberty of changing the drag cursor
back to an arrow. This is the way it is in MS Visual
C++, and it looks way better. The MoveWindow cursor
looks terrible, IMHO. When FL gets the embedded
cursor code working, we can switch back to a hand or
something else.
2) This time we have
discovered a crash bug in FL. The steps to reproduce this
bug are as follows:
1. Open up a pane, dock it.
2. Click the Expand button (arrow button) in the
frame hints portion
3. Click it again to Collapse the pane.
4. Now click the close button of the pane. Crash.
We investigated what was causing this problem, and it turns
out that the button state never gets unset. Once a button
is pressed, it is always pressed. Thus, when the expand/
collapse button is pressed, and then the close button is
pressed, the pane will close, but then FL will also try to
expand or collapse the pane as well, because it thinks that
the expand/collapse button was set.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@15802 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
