Most of the planned tasks have been finished. I suggest we review remaining tasks and set up a day for release.

SharpDevelop 3.* uses a customized build of DockPanel Suite based on original 2.2 release.

May review the patches there and see which are suitable to be included here.

• Have a FloatWindow and hide the DockPanel it belongs to.
• Start to move the float window.
• Notice you get docking indicators even though the panel to dock into is not visible.

This is even more bizarre on a multi-monitor setup, because if your DockPanel is not on the primary monitor, you end up getting the docking indicators on the primary monitor even though there is nothing related to your application there.

This is due to a bad rectangle returned from the DockPanel.RectangleToScreen() call in DockPanel.DockDraghandler.DockIndicator.RefreshChanges();

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Repro case:

1. Dock a window to the left or right side of the main form
2. Drag the tab out to make it float
3. Double click the window title bar to redock the window.
4. Poof!

The solution is to replace the call to Remove() in DockPane.FloatAt() with a call to NestedDockingStatus.NestedPanes.SwitchPaneWithFirstChild(this);

This needs to be tested for unintended consiquences.

Docking indicators as well as power to dock by moving the dockable windows does not work after moving to 2.6.

Any info needed?

I mean just right under MdiClient. Not under DockPanel control.

When you close a document, it may invoke a resize to occur on disposed controls which can cause a null-reference exception or a disposed-object exception. I have a map editor control that has a Resize event added to update/redraw the control whenever its parent window has resized. When I close the document it is contained inside of, the control is resized but fails because it has been disposed.

Also, the tab will remain as only the icon (text disappears), clicking on it again gives an object-disposed exception.

If I remove the resize code it all works, but then the control doesn't redraw to the new sizes as it should.

JArchitect is a cross platform Java static code analysis tool,

http://www.javadepend.com/

It is written in C# and based on DockPanel Suite (when running on Mono),

http://codebetter.com/patricksmacchia/2011/11/07/real-world-feedback-on-a-net-to-mono-migration/?

Their patch has been fully tested, so should be better than the one in 5e27774

Already sent a mail to ask if they would like to contribute their patch under MIT/X11 license. Will wait for the reply.

This exception has popped up a couple times when running in a terminal services environment (Citrix). More specific details will be provided if/when the issue can be reproduced.

System.Runtime.InteropServices.ExternalException (0x80004005): A generic error occurred in GDI+.
    at System.Drawing.Graphics.CheckErrorStatus(Int32 status) 
    at System.Drawing.Graphics.DrawRectangle(Pen pen, Int32 x, Int32 y, Int32 width, Int32 height)
    at WeifenLuo.WinFormsUI.Docking.DockWindow.OnPaint(PaintEventArgs e) 
    ...in WeifenLuo.WinFormsUI\Docking\DockWindow.cs:line 128
    at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
    at System.Windows.Forms.Control.WmPaint(Message& m) 
    at System.Windows.Forms.Control.WndProc(Message& m) 
    at System.Windows.Forms.ScrollableControl.WndProc(Message& m) 
    at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) 
    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) 
    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) 

I have a DockPanel with a single DataGridView form hosted as a document within the DockPanel. The DataGridView is pretty basic -- 40 rows x 20 columns with a mixture of text box, check box, and combo box columns.

When the DGV form's DockState is set to Document within the DockPanel, I've noticed a significant amount of lag when resizing the parent form which is hosting the DockPanel (resize is not smooth at all).

When the DGV form's DockState is set to Floating outside the DockPanel (i.e. drag document tab out of DockPanel) or if I show the form hosting the DGV separately, the lag disappears and everything is smooth when resizing as expected.

FloatWindow.SetBoundsCore() contains logic to prevent dragging a float window off the bottom of the screen.

This is inconsistent with nearly any other Windows application and can be a significant frustration when attempting to reposition a window temporarily for access behind it.

You are allowed to drag windows off to the side, just not off the bottom. I see no reason to enforce this constraint. At the least, it should be modified not only not allow the title bar from dipping off the bottom, but not the entire window.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Hi,

I try, with no success, to implement a sticky behavior on FloatWindow, more precisely on the ghost window (DragForm) which appears when we move a FloatWindow.
Did someone already try? Is it possible?

StickyWindow sample : http://www.codeproject.com/Articles/6045/Sticky-Windows-How-to-make-your-top-level-forms-to?fid=33209&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Quick&fr=1#xx0xx

Thanks

Clicking the middle mouse button on a tab should close the tab.

This may or may not already be in the last release.

When an application restores the dockpanel's serialized state on startup and there are many float windows being created, the creation of the float windows steals focus repeatedly, which can be a frustrating experience for the user.

The focus manager should suspend focus tracking until after the dockpanel has been initialized and the owning form has been shown.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Dock multiple items in a float window and note that you are unable to close a tab via middle click.

This fork is made by a Chinese developer named Yongrong Guo.

He has many changes checked in to SVN, so need some time to review all his changes.

i left to windows floating then i close the program.but it closes one of the window and don't let me close the program. Then i close it with stop debugger button in vs2012.. But now i reopen the program which loads the xml saved on form exit event i get the error Index was outside the bounds of the array. at line 675 of DockPanel.Persistor.cs which is for sorting with zorder. i have five dockcontent which takes name as a persiststring.

Rather than modify the existing skin we should create an additional skin that takes on the contributed changes (SharpDevelop and John Barton both have skin changes).

Additonally, we should move the skin files around so they are better organized, and add a Skin designer property to the DockPanel that will allow selection of the built-in skin.

DockPanel Suite assembly contains a reference to System.Design, and some classes are especially for design time support.

This prevents users from using it in a project that targets client profile (.NET 3.5/4).

We can split such design time support to a separate assembly.

I did the same for Crad's ActionList,

lextm/ActionListWinForms#9

A common question in the forums is "how do I make my float windows maximizable."

Although this isn't difficult to extend on your own, the support for this should really just be built in to make it easier to achieve.

The DockPanel.ActiveDocument value holds the previous active document when switching between documents with keyboard shortcuts (Ctrl+Tab, Shift+Ctrl+Tab) or by selecting document from the Window menu.

Steps to reproduce:

1. Load the WinFormsUI.Docking.sln.
2. Open MainForm in the designer.
3. Add ActiveDocumentChanged event handler to the dockPanel control.
4. Edit the created event handler to look like this:

    if (this.dockPanel.ActiveDocument != null)
        System.Diagnostics.Debug.WriteLine(this.dockPanel.ActiveDocument);

1. Build and run.
2. Create 3 empty documents (File -> New). The Visual Studio Output window should contain 3 lines, the last one being "DockSample.DummyDoc, Text: Document3". (http://imageshack.us/photo/my-images/600/32047518.png)
3. Go to the Window menu and select "1 Document1". The active tab changes to the "Document1", but there is no new line in the Output window, meaning the event handler wasn't invoked. (http://imageshack.us/photo/my-images/405/78826564.png)
4. Go to the Window menu again and select "2 Document2". This time the event handler was invoked, but the last line shows, that the ActiveDocument property contains the previous active document (Document1). (http://imageshack.us/photo/my-images/19/64776299.png)
5. The above step can be repeated multiple times, but the ActiveDocument property will always be one step behind.
6. Now activate some other window (Toolbox for example). The event handler is immediately invoked and the Output window contains the line with the correct ActiveDocument property value. (http://imageshack.us/photo/my-images/834/19438604.png)

The issue is not present when activating tab with a mouse button.

Testing environment: latest DockPanel Suite source (commit 7154d18), Windows 7 x64, Visual Studio 2008.

We have a layout that updates tool windows whenever a dockpanel form is activated, notifying other dockpanels to clear their controls from the tool windows, which are reused. (Deactivates never seem to come in, so we went with a document declaring focus scheme).

This works properly when switching between docked dockpanels and when switching between floating dockoanels. It does NOT work when switching between docked and floating dockpanels.

On selecting the floating window the first time, we get an activation.
Selecting the docked dockpanelagain, we again get an activation.
Selecting the floating window gets activation.
Selecting the docked dockpanel for the second time, we do NOT get an activation.

repeating thereafter results in no activations in the docked document. Floating dockpanel continues to get activations. The only way to resolve the issue is to either dock the floating window or select another docked dockpanel.

It appears that once we activate the docked dockpanel for the first time, the active pane gets set and thereafter, the framework does not realize that activation events still need to be thrown. We have observed that the suspend focus tracking gets "off" by as much as 3 or 4 through repeatedly selecting one after the other, but it appears random.

So far, I haven't found the solution. :-(

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

WinForms applications based on DPS currently cannot work on Mono/Linux/Mac due to the P/Invoke code on Win32 API.

Should disable the Win32 P/Invoke dependent features (drag and drop) if running on Mono/Linux/Mac right now till someone rewrites those parts with *nix friendly P/Invoke.

I've been trying with no success, but is there a way to disable an individual tab page within the DockPanel? I'd like to be able to disable (and gray out) the text on a TabPage. When the cursor is placed over the TabPage, it wouldn't expand. I doubt this feature is currently available, but would be a great addition.

Thanks

Reproduce:

1. Open sample application
2. Click 'Show Layout By Code' button
3. Make Document2 floating
4. Drag titlebar of float window to dock it in the area occupied by one of the docked documents.
5. Notice that while the cursor is over the float window, docking indicators are shown on the outside of the main dock (to dock top/left/bottom) but the center indicator doesn't appear on the existing docked content unless the cursor leaves the float window.

This behavior differs from VS2010, where the indicator is shown through the float window.

Original issue:
https://sourceforge.net/projects/dockpanelsuite/forums/forum/402316/topic/1583731

I think this may be related to Issue #46, but it is different in that my application fails to show the docking indicators, or allow any tabs to redock running with or without the debugger in x86 or x64 under .Net 4.5.

(Originally reported on SourceForge: http://sourceforge.net/projects/dockpanelsuite/forums/forum/402316/topic/5409456)

I have noticed some strange behaviour using the demo project.

Closing a window docked at the bottom (hitting X) results in the tab in the main Document window changing.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Issue:
SplitContainer.Panel1.Width != SplitContainer.Width

Steps:
var uc = new UserControl();
var sc = new SplitContainer()
sc.Orientation = System.Windows.Forms.Orientation.Horizontal;
sc.Dock = DockStyle.Fill;
sc.Panel1.BackColor = Color.Red;
uc.Controls.Add(sc);
uc.Dock = DockStyle.Fill;

var dc = new WeifenLuo.WinFormsUI.Docking.DockContent();
dc.DockAreas = WeifenLuo.WinFormsUI.Docking.DockAreas.DockBottom;
dc.Text = "Caption 1";
dc.Controls.Add(uc);
dc.Show(this.dockPanel);
dc.DockState = WeifenLuo.WinFormsUI.Docking.DockState.DockBottomAutoHide;

Yuo will see red Panel1 that doesn't fit SplitContainer.

Feature request for the ability to change appearances such as the color of a tab for a given DockContent, overriding the colors set in the active DockPanelSkin.

http://sourceforge.net/projects/dockpanelsuite/forums/forum/402316/topic/4482610

Steps to reproduce it

1. Compile the source code on Linux using xbuild or MonoDevelop.
2. Go to DockSample binary folder (DockSample/bin/Debug), and open a Terminal.
3. Execute "mono DockSample.exe".
4. Repeat step 3, and this time click View | Solution Explorer menu item to open Solution Explorer panel.

After step 3, when you see the DockSample window, please close it immediately (File | Close Without Saving Layout). Here you only see an exception at the Terminal,

lextm@linux-9xno:~/Projects/dockpanelsuite/DockSample/bin/Debug> mono DockSample.exe
X11 Error encountered: 
  Error: BadMatch (invalid parameter attributes)
  Request:     12 (0)
  Resource ID: 0x360001E
  Serial:      522
  Hwnd:        Hwnd, Mapped:True ClientWindow:0x360001F, WholeWindow:0x360001E, Zombie=False, Parent:[<null>]
  Control:     WeifenLuo.WinFormsUI.Docking.DockPanel, BorderStyle: None   at System.Environment.get_StackTrace()
   at System.Windows.Forms.XplatUIX11.HandleError(IntPtr display, XErrorEvent ByRef error_event)
   at System.Windows.Forms.XplatUIX11.XTranslateCoordinates(IntPtr , IntPtr , IntPtr , Int32 , Int32 , Int32 ByRef , Int32 ByRef , IntPtr ByRef )
   at System.Windows.Forms.XplatUIX11.ClientToScreen(IntPtr handle, Int32 ByRef x, Int32 ByRef y)
   at System.Windows.Forms.XplatUI.ClientToScreen(IntPtr handle, Int32 ByRef x, Int32 ByRef y)
   at System.Windows.Forms.Control.PointToScreen(Point p)
   at System.Windows.Forms.Control.RectangleToScreen(Rectangle r)
   at WeifenLuo.WinFormsUI.Docking.DockPanel.GetAutoHideWindowBounds(Rectangle rectAutoHideWindow)
   at WeifenLuo.WinFormsUI.Docking.DockPanel.OnLayout(System.Windows.Forms.LayoutEventArgs levent)
   at System.Windows.Forms.Control.PerformLayout(System.Windows.Forms.Control affectedControl, System.String affectedProperty)
   at System.Windows.Forms.ScrollableControl.OnVisibleChanged(System.EventArgs e)
   at WeifenLuo.WinFormsUI.Docking.DockPanel.OnVisibleChanged(System.EventArgs e)
   at System.Windows.Forms.Control.OnParentVisibleChanged(System.EventArgs e)
   at System.Windows.Forms.Control.OnVisibleChanged(System.EventArgs e)
   at System.Windows.Forms.ScrollableControl.OnVisibleChanged(System.EventArgs e)
   at System.Windows.Forms.Form.OnVisibleChanged(System.EventArgs e)
   at System.Windows.Forms.Control.SetVisibleCore(Boolean value)
   at System.Windows.Forms.Form.SetVisibleCore(Boolean value)
   at System.Windows.Forms.Control.set_Visible(Boolean value)
   at System.Windows.Forms.Application.RunLoop(Boolean Modal, System.Windows.Forms.ApplicationContext context)
   at System.Windows.Forms.Application.Run(System.Windows.Forms.ApplicationContext context)
   at System.Windows.Forms.Application.Run(System.Windows.Forms.Form mainForm)
   at DockSample.Program.Main()

This is a warning which is not critical at this moment.

However, after step 4, if close DockSample window (File | Close Without Saving Layout), you will see at Terminal tons of logs and finally the process terminates with a runtime error.

Workaround
A possible workaround is to close all DockContent manually in DockSample MainForm's Closing event before exiting.

This workaround has been tested in #SNMP MIB Browser and Compiler.

Root Cause
As this does not happen on Windows, I know it must be caused by the Mono patch #7/#8.

Will later investigate and resolve it.

Sorry if i just missed it, but how can i set the MaximumSize of a dockpanel when it is hidden? I found out how to set the MaximumSize for a visible Dockpanel, but that doesn't work iwhen the panel is hidden. Mousehover over the panel shows the panel in a bigger size then the MaximumSize.

Thanks for help!

Hi, I am using DockPanel control in my application and I want to use drag and drop feature like in VS i.e. in VS in can drag and drop toolbox controls from Toolbox to form.

A user reported this mistake today and it has just been fixed in 7a02833.

A new NuGet package has been submitted to NuGet.org, versioned 2.6.0.1,

https://nuget.org/packages/DockPanelSuite

There are a variety of focus and painting issues that appear on 64-bit operating systems that rarely are seen on 32-bit systems. Examples:

http://sourceforge.net/projects/dockpanelsuite/forums/forum/402316/topic/4509929
http://sourceforge.net/projects/dockpanelsuite/forums/forum/402316/topic/4482610

Although this was previously (and correctly) identified as a Windows kernel stack overflow issue a good solution had not been found for the focus issue. The true cause of the problem is when multiple instance of the dockpanel are used in a single application and each dockpanel hooks into win32 to monitor for focus changes. When the hook processing callback yields to the next hook in the chain, it ends up calling itself again due to the multiple hook installations that exist in the application. If you have enough hooks installed the callstack while processing the hooks will grow too large and windows will silently abandon the call.

The solution will be to make the LocalWindowsHook static, ensuring only one hook is installed per application. This is desired since the hook is installed at the thread level (all hooks install on the UI thread) and the callback simply raises an event to notify the focus manager that a message has been received.

Steps to reproduce it

1. In design create a panel in a window.
2. Compile and run and manually re-size window.

panel.height when re-sized does not get set correct in first move but after second little re-size it gets close.

panel.width is nearly the same.

I have tested with version 2.2 , 2.31 and 2.5 and it works fine but with 2.6 the error is produced.

I must Thank You for your initiative to continue the development of this very useful library.

Is there a public event handler that I can subscribe to that will tell me when a document has been reordered in a dockpanel? I have a dockpanel set to DocumentStyle.DockingWindow that can contain two or more separate document tabs, and I would like to know when and if the user manually reorders these.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

When closing an inactive tab with the middle mouse button the tab should just close gracefully. Instead, the tab is first activated, then closed. In addition to the noticable delay this may induce, the active tab is then changed to an adjacent tab. One should expect the active tab to not change when closing an inactive tab in this manner.

We finished all items under Milestone 2.6 (https://github.com/dockpanelsuite/dockpanelsuite/issues?milestone=1).

To release DPS 2.6, the following sub-tasks remain,

1. Open .nuget\DockPanelSuite.nuspec
2. Document the changes in release notes format in release notes section.
3. Change the version to 2.6.0.0.
4. Go back to root directory and then go to WinFormsUI\Properties\AssemblyInfo.cs. Also update the version numbers there.
5. Go back to root directory, execute all.bat to prepare the binaries.
6. Go to .nuget folder and launch command prompt.
7. Execute "nuget pack" at prompt.

The final NuGet package will be available, and can be published to http://nuget.org.

Not sure if we need to create a virtual identity on http://nuget.org to be the owner of DPS nuget packages. We can discuss here.

After that we can zip up bin folder for SF.net, and export the source code, too.

I need Mdi application with docked panels on all sides of MainForm.

So, center part of DockPanel is full MdiClient with standart floated mdichildren forms which can't to be docked and all sides that acting like dockpane.

I hope you understand me!

When a window is docked within a dock panel, Resources.DockPane_Dock bitmap is not displayed (shows a grey rectangle without painting the bitmap). Problem does not exist on Windows 7.

John Barton (https://github.com/jcbarton) has a few patches for DPS, as he revealed on SF.net,

http://sourceforge.net/projects/dockpanelsuite/forums/forum/402316/topic/5080422

We already merged the fix for SF bug 1849882 in #10.

John already forked DPS at https://github.com/jcbarton/dockpanelsuite. He will publish the patches there. The patches will be reviewed and gradually merged.

The localization attributes are applied to the m_tabText variable instead of TabText property.

File: WinFormsUI\Docking\DockContent.cs
Line: 65

SF bug link is at https://sourceforge.net/tracker/?func=detail&aid=1849882&group_id=110642&atid=659401

Discussion on SF is at https://sourceforge.net/projects/dockpanelsuite/forums/forum/402316/topic/5080422

The patch has been checked in to a dedicated branch, 34efe35

Need to Test out the fix, and then confirm it works as expected.

There is a CloseButtonVisible property on DockContent, but the window list button is not user-hidable. Perhaps this can be a tri-state: Show, Hide, Auto; where Auto will only show the button when a Dock Content tab is not visible on the strip.

Does this make sense to place on the DockContent alone or should the default be settable on the DockPanel?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

The float window should reflect the icon of the active content instead of showing the default winforms icon. The benefit is only realized by applications that change the floatwindow style via the extender since by default no icon is shown.

For discussion:

Currently the code base is written such that it will compile against .NET 2.0 on a .NET 2.0 era compiler. At what point do we increase the minimum requirements so that we can use auto-implemented properties, the var keyword, or other features not available to developers under the .NET 2.0 compiler?

The compiler under Visual Studio 2010 supports these language features even when targeting the build to .NET 2.0. So in effect, we can raise the minimum requirements for the source code without raising the .NET CLR requirements to execute the binaries.

I believe this to be a fair trade off, as the only impact would be that those running VS 2005 would only be able to use the binaries.

#42 If we are going to make the split, then we must create an installer to register the design time support on Visual Studio.

We can reuse the installer script I used for Crad's ActionList,

lextm/ActionListWinForms#8

[Errantly created issue. Feel free to recycle it if you're creating a new issue.]

A NullReferenceException is occasionally logged at roughly line 526 in DockContentHandler:

if (Pane != null && DockState == Pane.DockState)
{
if ((Pane != oldPane) ||
(Pane == oldPane && oldDockState != oldPane.DockState)) << logs indicate exception on this line
// Avoid early refresh of hidden AutoHide panes
if ((Pane.DockWindow == null || Pane.DockWindow.Visible || Pane.IsHidden) && !Pane.IsAutoHide)
RefreshDockPane(Pane);
}

It seems this would only happen if oldPane was null, but logically we cannot get into that state (Pane cannot be null, so if oldPane is null, the DockState will not be checked).