| Name |
Description |
| AdapterMenuItem |
Summary description for AdapterMenuItem. |
| BasicPaneBarContainer |
|
| ClassA |
|
| CommandBarAdaptor |
|
| GenericUITests |
Summary description for GenericUITests. |
| HighColleague |
|
| HtmlControl |
Summary description for HtmlControl. |
| HtmlControlEventArgs |
|
| HtmlViewer |
Summary description for HtmlViewer. |
| LowColleague |
|
| MedColleague |
|
| MenuAdapter |
Creates the menu bar and menus for an XCore application. |
| MultiPane |
A MultiPane (actually currently more a DualPane) displays two child controls, either side by side or one above the other, with a splitter between them. It is normally created using XML like this: The vertical parameter causes the two controls to be one above the other, if true, or side by side, if false. (Default, if omitted, is true.) The id parameter gives the MultiPane a name (which should be unique across the whole containing application) to use in storing state, such as the position of the splitter, persistently. It is mandatory to specify the area that the control is part of, but I (JT) don't know why. If the mediator has a property called id_ShowFirstPane (e.g., LexEntryAndEditor_ShowFirstPane), it will control the visibility of the first pane (visible if the property is true). |
| PaneBar |
PaneBar, AKA "information bar" |
| PaneBarContainer |
|
| PanelButton |
|
| PanelEx |
|
| PanelMenu |
|
| PersistenceProvider |
A PersistenceProvider which uses the XCore PropertyTable |
| Property |
|
| PropertyTable |
|
| PropertyTableTests |
|
| ReBarAdapter |
Creates the toolbars for an XCore application. |
| RecordBar |
Summary description for RecordBar. |
| RecordFilterListProvider |
|
| SidebarAdapter |
Creates a SidebarAdapter. |
| Spacer |
|
| StatusBarSizeGrip |
This is a size grip that can be added to a status bar. We use this instead of letting the status bar draw the size grip because the size grip can draw too large at 120dpi overlapping adjacent panels. |
| StringPair |
|
| TestColleague |
|
| TestControl1 |
Test class that implements sequencing of messages, but simulates no recursion. This is a good model for what a class needs to do to get messages sequentially. |
| TestControl2 |
This is initialized with windows messages for an activate, a killFocus, and a set focus. RunPendingMessages fires the killFocus and set focus from inside the activate; the activate from inside the keyDown |
| TestControl3 |
This is initialized with windows messages for a paint event, kill and set focus. RunPendingMessages fires the killFocus and setfocus from inside the paint. |
| TestControlBase |
Test class that implements WndProc by noting start and finish, and possibly making recursive calls. |
| TestMessagePriority |
|
| TestMessageSequencer |
|
| TestMessageSequencer.DummyForm |
|
| TestTupleComparer |
|
| ToolStripManager |
Controls the position of a single MenuStrip and 1 or more ToolStrips |
| TrickQueue |
This adds an extra set of numbers, 900..909, whenever we grow. |
| XMessageBoxExManager |
a subclass of the (open-source) message box manager which interfaces it to XCore |
| XWindow |
XWindow is a window which is configured with XML file. |
