DockingDlgInterface: Disabling Docking & Size Restriction

Thomas Knoefel

I’ve been working with the DockingDlgInterface. However, I didn’t originally develop the Plugin with docking in mind.

I have two primary questions:

Is there a method to disable the docking functionality?
How can I restrict the size of the window when it’s in the undocked mode?

I’ve tried the following code snippet to manage the window’s size, but it doesn’t seem to work as expected:

switch (message) {
    case WM_GETMINMAXINFO: {
        MINMAXINFO* pMMI = (MINMAXINFO*)lParam;
        pMMI->ptMinTrackSize.x = MIN_WIDTH;
        pMMI->ptMinTrackSize.y = MIN_HEIGHT;
        return 0;
    }
}

If anyone knows how to handle this, I’d be grateful for any tips.

Coises

@Thomas-Knoefel said in DockingDlgInterface: Disabling Docking & Size Restriction:

Is there a method to disable the docking functionality?

I assume you mean docking is to be enabled for a time, and then you want to suspend that functionality during a session? If you want to disable it totally, just don’t send an NPPM_DMMREGASDCKDLG message.

I haven’t used docking dialogs, but I assume you use NPPM_MODELESSDIALOG with MODELESSDIALOGADD before you use NPPM_DMMREGASDCKDLG and again with MODELESSDIALOGREMOVE when you destroy the dialog? Perhaps try NPPM_MODELESSDIALOG with MODELESSDIALOGREMOVE followed by NPPM_MODELESSDIALOG with MODELESSDIALOGADD and no NPPM_DMMREGASDCKDLG message (until and unless you want to enable docking again). If that doesn’t work, you might have to destroy and recreate the dialog itself.

How can I restrict the size of the window when it’s in the undocked mode?

I’ve tried the following code snippet to manage the window’s size, but it doesn’t seem to work as expected:
switch (message) {
    case WM_GETMINMAXINFO: {
        MINMAXINFO* pMMI = (MINMAXINFO*)lParam;
        pMMI->ptMinTrackSize.x = MIN_WIDTH;
        pMMI->ptMinTrackSize.y = MIN_HEIGHT;
        return 0;
    }
}

That looks right. I believe that only affects dragging the edges of a window. It won’t affect the size of an already existing window, nor limit changing the size in any other way. Consider processing WM_SIZING if you can’t get what you need from WM_GETMINMAXINFO.

Thomas Knoefel

@Coises Thanks for your reply.

I’ve tested the methods you’ve suggested:

::SendMessage(_hParent, NPPM_MODELESSDIALOG, MODELESSDIALOGREMOVE, reinterpret_cast<WPARAM>(_hSelf));
::SendMessage(_hParent, NPPM_MODELESSDIALOG, MODELESSDIALOGADD, reinterpret_cast<WPARAM>(_hSelf));

Unfortunately, it didn’t have the desired effect. I’ve also confirmed that _hParent is correctly set.

I’m now doubting if DockingDlgInterface even allows for the disabling of docking or for size restrictions as I’ve attempted with WM_GETMINMAXINFO.

I primarily opted for DockingIntf to inherit N++ theme settings for the plugin window.
It’s not mission-critical, but having that extra polish would elevate the user experience.

Coises

@Thomas-Knoefel I haven’t used the dockable dialog interface, so I don’t have any direct experience. I’ve been looking around the code, trying to figure out what it’s doing.

It looks like you create a docking dialog by deriving a class from either StaticDialog or DockingDlgInterface and then implementing run_dlgProc to make anything happen?

It looks like run_dlgProc should get all dialog procedure messages. Can you verify that you are getting WM_GETMINMAXINFO messages when you drag an edge of the floating dialog?

It looks like there’s a bunch of code to establish the position and size of the floating dialog when it’s first displayed or undocked. There’s a protected RECT member in StaticDialog named _rc that looks like it might have to do with that, but I wasn’t able to follow how it is used.

I think you get neither WM_GETMINMAXINFO nor WM_SIZING messages when the window is resized by code rather than by the user, so if your problem is with when the floating dialog is displayed by Notepad++ (e.g., after undocking) then it’s expected that intercepting those messages wouldn’t help. However, there is WM_WINDOWPOSCHANGING which is not limited to user-initiated changes. I would try that next.

Thomas Knoefel

@Coises said in DockingDlgInterface: Disabling Docking & Size Restriction:

It looks like you create a docking dialog by deriving a class from either StaticDialog or DockingDlgInterface and then implementing run_dlgProc to make anything happen?

Yes, you’re right. I’ve created a docking dialog by inheriting from DockingDlgInterface and implementing the run_dlgProc method.

Regarding the WM_GETMINMAXINFO message, I can confirm that it’s being received. However, any adjustments made within it don’t seem to affect the window’s size.

For the WM_SIZE message, it is indeed triggered when the window size changes. I’ve also tried using WM_WINDOWPOSCHANGING, and the results were interesting. While all UI elements remain in their intended positions as if the window size had reached its defined minimum, the window’s borders can still be resized smaller than this point. In essence, WM_WINDOWPOSCHANGING doesn’t restrict the window frame from resizing below the defined dimensions, even though the internal panel appears to “freeze” at the intended size.

case WM_WINDOWPOSCHANGING:
    {
        WINDOWPOS* pwp = (WINDOWPOS*)lParam;
        if (pwp->cx < MIN_WIDTH) pwp->cx = MIN_WIDTH;
        if (pwp->cy < MIN_HEIGHT) pwp->cy = MIN_HEIGHT;
        return 0;
    }

The blocking of the frame border seems somewhat mysterious in N++ when using DockingDlgInterface.

Coises

@Thomas-Knoefel said in DockingDlgInterface: Disabling Docking & Size Restriction:

In essence, WM_WINDOWPOSCHANGING doesn’t restrict the window frame from resizing below the defined dimensions, even though the internal panel appears to “freeze” at the intended size.

Yes, restricting user sizing is what WM_GETMINMAXINFO is meant to do. I vaguely recall discovering it when I had a situation similar to what you describe (long ago, in a stand-alone program I was writing): I could keep the window from getting too large or too small, but the user interface still made it seem like it would be possible to drag it larger or smaller, until I used WM_GETMINMAXINFO to set the appropriate limits.

Regarding the WM_GETMINMAXINFO message, I can confirm that it’s being received. However, any adjustments made within it don’t seem to affect the window’s size.

Just in case: what you’re saying, taken literally, is expected. The response to WM_GETMINMAXINFO doesn’t change the size of the window, it sets limits on how the user can drag the window. WM_WINDOWPOSCHANGING can change the size of the window itself, but it doesn’t restrict the dragging rectangle. Normally, setting limits on dragging is enough, but in this case, since Notepad++ intervenes and sets a window size when you undock, it makes sense that you might need both.

If WM_GETMINMAXINFO isn’t working to constrain the drag rectangle, though, the only things I can think of are to study the Notepad++ code, and/or build Notepad++ with debug symbols, breakpoint after you get your WM_GETMINMAXINFO message, then step forward and try to see what is happening after you respond to it. I can’t find an obvious place in the Notepad++ code that would alter those messages, but I’ve only done a cursory search for WM_GETMINMAXINFO. I haven’t attempted to follow the entire process of handling dockable dialog messages.

Thomas Knoefel

@Coises I’ve made another attempt and successfully transitioned the Plugin from DockingDlgInterface to StaticDialog. With this change, WM_GETMINMAXINFO operates as anticipated.

However, my initial preference for DockingDlgInterface was because of the noticeable absence of theme support for StaticDialog. I find it a bit peculiar that N++ uses StaticWindow in various places, yet it does support DarkMode.

If StaticWindow can be configured to toggle themes, it is a feasible solution.

Thomas Knoefel

I finally managed to switch the StaticDialog Window into DarkMode using NPPM_DARKMODESUBCLASSANDTHEME. Making the switch to StaticDialog effectively resolved the window resizing issue.