Creating a DockablePanel-Controlmanager Using C#, Part 7

Creating a DockablePanel-Controlmanager Using C#, Part 7

Pinning and how to hide a docked panel

Welcome to Part 7 of a series of articles on how to create dockable forms. The design is similar to the C# IDE, where you are able to dock the toolbox and various other panels, and where you can see a preview rectangle and some icons while dragging the DockableForm around. These icons and the preview rectangle show you the different ways to drop your panel. To get the whole picture of what I’m doing to create a fully dockable panel, I have included a lot of pictures to demonstrate the entire logic behind the particular topic I’m covering. If this is your first visit to this series, I would really recommend to go through all the previous parts first. Why? Because each of the recent parts include the full source code (up to that point), as well as some retrospective short explanations about the different topics covered already.

As mentioned in earlier lessons, these articles are aimed at programmers who are relatively new to C# (currently reading a C# book, or did some small examples in C#), but also have an existing basic knowledge of programming, (for example, former Visual Basic programmers), and at those who want to learn how to build your own Usercontrols.

The actual article will talk about how to hide the dockable panels and to slide them back to the screen in a fashion similar to the Visual Studio style. I will need to talk about hooking and I’ll also cover a short introduction on how to debug a hooked application at a beginner’s level.

If you want to follow this article and you haven’t read all the other parts yet, you should do this first, or you will not be able to follow these explanations. Here are the links to the previous articles:

Note: Because you have to add some parts here and there, the code becomes more and more complex now and, to be sure where you are, I have added the regions where the code is to find or where it should be created so that it is easier for you to follow. If you still haven’t created all the regions by now, you really should do this organizational work first; it will save you hours of work.

In the former articles, you already built the DockableForm with its basic and some more advanced docking actions. Looking to the IDE, you will see that your Toolbox and other panels too are normally pinned, so you can see them all the time or you can use a pin button there to get them temporarily hidden, and only a button on that side of the IDE belonging to this panel shows you where you are able to slide your panel back on the screen, whenever needed.

Your DockingManager already contains some of the things you need for this. Remember that in Part 1, you already added the ToolStrips that you will need for exactly this mechanism. They normally are hidden as long as none of the docked panels are unpinned. Here is a picture of them when they are visible. But, be aware this is only the ToolStrips; the ToolStripButtons for this still need to be designed.

Figure 1: ToolStrips on each side ready to wear ToolStripButtons whenever needed.

And this is how it looks when for example one of two panels, both docked to the left, is unpinned.

Figure 2: Left ToolStripButton shown when a Panel docked to the left side is unpinned.

When designing this mechanism, you have to be aware of the different conditions that may occur, that influence your ToolStripButtons and also your ToolStrip itself, depending on what the user does. Maybe the best way is to have them all in a list:

User’s action ToolStrip State
No panel docked ToolStrips invisible
Some Panels docked but all of them pinned ToolStrips invisible
Some panels docked and pinned, at least one unpinned. There are two possibilities: All ToolStrips associated with an unpinned docked Panel are visible, for each unpinned panel one ToolStripButton can be seen on the adequate ToolStrip.
        Mouse outside the area of one of the ToolStripButtons The unpinned panel isn’t shown, you only will see all the other pinned panels
Mouse hovers one of the shown ToolStripButtons The unpinned Panel slides on the screen so you can see both the unpinned panel and the corresponding ToolStripButton. This mechanism is at least necessary to re-pin the unpinned Panel.
Mouse hovers one of the unpinned panels that are just visible on the screen caused by the above action The unpinned panel stays on screen as long as the mouse is in the range of the DockingControler where the unpinned panel was added.
You have unpinned a panel that was docked using DockType.Center so it is part of a TabControl In this case, you unpin all the panels contained in this TabControler. On the opposite, you pin all the panels that are part of a specific TabControler, even if only one of them is pinned again by the user.
Hover over one of the ToolStripButtons that is the companion for a panel docked using DockType.Center In this case, you are not only sliding one panel back to be visible, you are taking the whole TabControler with all the panels it contains back to the screen to be visible.
Closing a panel while it was unpinned but visible The ToolStripButton that is associated with this Panel is removed from its ToolStrip. If all ToolStripButtons of a specific ToolStrip are removed, the ToolStrip is hidden again. If the panel was part of a TabControl, it is also removed there. The remaining other unpinned panels stay as they have been before.
Undocking a panel while it is unpinned but visible The ToolStripButton that is associated with this Panel is removed from its ToolStrip. If all ToolStripButtons of a specific ToolStrip are removed, the ToolStrip is hidden again. If the panel was part of a TabControl, it is also removed there. The remaining panels stay as they have been before.
No more unpinned panels exist on a specific DockingControler Don’t forget that, in a more complex environment, a ToolStrip could wear Buttons that are accompanied to panels in different DockingControlers. So, it may happen that all ToolStripButtons corresponding to a specific DockingControler are removed. But only if there are no more ToolStripButtons left on a specific ToolStrip it is hidden.

Table 1: User actions and how the program reacts

More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read