Home Forums WinForms controls Other WinForms controls DockLayoutManager problem

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • User (Old forums)
    Member
    Post count: 23064
    #18438 |

    Since the 2.1 release, tool windows cannot be dragged and then dropped to another (already docked) tool window to create a group (or extend an existing one). This does not happen when the target tool window is in floating state (then everything works ok, even the docking to the top/bottom/left/right of the form, but only when the mouse cursor is over the floating target tool window).

    This is very easy to reproduce, I tried the DockedExplorer sample. I assume this is a bug (because it functioned normally in the previous version).

    I also found another curious problem. When using the TabbedMdiManager, it sometimes happens that the main form cannot be closed at all. I was wondering where the problem could be, and I found out that it is somehow the FormClosing event of the main form, which has FormClosingEventArgs.Cancel set to true, even if there is no event handler associated. I can suppress this problem via this event handler by setting Cancel to false, which always enable me to close the form BUT it disables the option of cancelling closing of an individual MDI child (this also uses the same mechanism and it seems to interfere).

    This second *bug* is not easy to reproduce, it happens quite randomly. In previous version, there was a general problem in using FormClosingEventArgs.Cancel in the MDI child’s FormClosing event at all, but the main form could be closed anytime successfully. So this problem has started with the 2.1 version.

    Best regards,
    Honza Ambroz.

    Imported from legacy forums. Posted by hambroz (had 9895 views)

    Xceed Support
    Member
    Post count: 5658

    It’s strange, using the 2.1 version and the suggested DockedExplorer sample I was not able to reproduce the issue. Maybe I’m missing some steps.

    I started the application. I dragged the floating ToolWindow to add it (as a group) to a Docked ToolWindow and it worked. I also tried starting with an already docked ToolWindow and directly drag it to an other docked ToolWindow (and it still worked).

    Imported from legacy forums. Posted by CharlesB (had 402 views)

    User (Old forums)
    Member
    Post count: 23064

    I must apologize to Xceed in case of the first problem. It is indeed working correctly. I have just found out why it had not worked before. The reason is simple; there is some conflict between the DockLayoutManager (or the application using this control) and the Ultramon software i am using. This software is adding some custom buttons to the title bar of the window and this operation effectively breaks the docking ability of the windows.

    Maybe it is quite interesting to get to know why it is happening, but it is really not an Xceed issue.

    The second problem, on the contrary, is very strange and I am starting to suspect the Vista operating system to have someting with this. As I said before, the previous version (on WinXP) worked normally. Since Vista and the 2.1 version, it sometimes happens. But I have also found out that when Vista is set to Large Fonts, then the main form also can’t be closed sometimes. So this is quite a tricky stuff.

    Best regards,
    Honza Ambroz.

    Imported from legacy forums. Posted by hambroz (had 431 views)

    Xceed Support
    Member
    Post count: 5658

    I took the time to test the second issue this time and again, I wasn’t able to reproduce. I changed my Vista system DPI to a 120 (the “Large Fonts”). I tried many (many) times all our Docking Windows sample -> Closing and opening the ToolWindows and the forms -> Without a problem.

    Imported from legacy forums. Posted by CharlesB (had 365 views)

    User (Old forums)
    Member
    Post count: 23064

    I really thank you for the effort you take to test it. In case of the second problem, I just really don’t know what to do, so I tried to post it here. The only reason it makes me suspect the TabbedMdiManager is the fact that this started to appear just after the upgrade to 2.1 version and Vista. It may be just another problem of type “my computer only”.

    Thank you again, best regards,
    Honza Ambroz.

    Imported from legacy forums. Posted by hambroz (had 569 views)

    User (Old forums)
    Member
    Post count: 23064

    After some hours of testing, debbuging and playing with the Xceed demos, i am finally able to reproduce the second problem mentioned. Please try this:

    freshly rebuild the Imaging sample (be sure that the folder does not contain the previously saved layout file),
    start the sample,
    drag the Rotate Canvas tool window onto the Color Picker tool window title bar to create a group,
    try to close the form.

    I tried this many times and I always ended up with non-closable form. I hope this will finally make it clear as if it will work for you, I’m gonna reinstall my Windows.

    Best regards,
    Honza Ambroz.

    Imported from legacy forums. Posted by hambroz (had 508 views)

    Xceed Support
    Member
    Post count: 5658

    Thanks for the easy to follow steps; I was finally able to reproduce the issue. I will forward this issue to our main developer. As soon as I have new developments regarding this issue, I will notify you.

    Imported from legacy forums. Posted by CharlesB (had 363 views)

    User (Old forums)
    Member
    Post count: 23064

    After many long hours of debugging and headache, this problem appears not correctable in source code.  There has been a changed somewhere between .NET 1.1 and .NET 3.5 (was working in 1.1, not in 3.5) in the way validation is handled, and which results in the problem.

    However, the workaround is to handle the FormClosing event, and in the event handler, set e.Cancel to false (by default, it is set to true when validation fails).

    Imported from legacy forums. Posted by André (had 6363 views)

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.