Plugin Docking Panel floating / docked detection

Michael Vincent

The Notepad++ plugin template provides an interface for Docking Dialogs and ways to detect whether they are visible or closed. It also seems to track whether the dialog is floating or docked in one of the 4 docking positions in the Notepad++ window.

src/DockingFeature/DockingDlgInterface.h

        bool _isFloating = true;

[...]

						case DMN_FLOAT:
						{
							_isFloating = true;
							break;
						}
						case DMN_DOCK:
						{
							_iDockedPos = HIWORD(pnmh->code);
							_isFloating = false;
							break;
						}

I’ve added a simple method to get the _isFloating status:

	bool isFloating() const {
		return _isFloating;
	}

But whenever I check the status of that _myPluginDialog.isFloating() it always returns True whether the dialog is floating or is docked.

Am I missing something?

Cheers.

mkupper

@Michael-Vincent said in Plugin Docking Panel floating / docked detection:

I’ve added a simple method to get the _isFloating status:
	bool isFloating() const {
		return _isFloating;
	}
But whenever I check the status of that _myPluginDialog.isFloating() it always returns True whether the dialog is floating or is docked.

Am I missing something?

Cheers.

_isFloating seems to be a local variable. It’s not clear from src/DockingFeature/DockingDlgInterface.h why the variable exists and what its scope/lifetime would be.

Michael Vincent

@mkupper said in Plugin Docking Panel floating / docked detection:

_isFloating seems to be a local variable. It’s not clear from src/DockingFeature/DockingDlgInterface.h why the variable exists and what its scope/lifetime would be.

So is _isClosed, but I call .isClosed() to check closed status and that returns correctly.

Cheers.

PeterJones

@Michael-Vincent ,

I don’t have any experience with coding the docking plugins, but I would think _isFloating and _isClosed would have the same persistence/visibility, since they have identical scope & protection, so if .isFloating() were defined at the same level as .isClosed(), I would think it should work.

My suggestion would be to add some “debug print” statements (‡) inside each case: DNM_...: – something like display the state of both of those variables, and display the output of both of those calls. Then you could see whether it’s ever hitting the cases that are changing _isFloating, and whether isFloating() is able to know the right state when it’s called after one of the other modes has been entered.

‡: I think that’s possible using OutputDebugString() and sysinternals DebugView

Michael Vincent

@PeterJones said in Plugin Docking Panel floating / docked detection:

My suggestion would be to add some “debug print” statements (‡) inside each case: DNM_…: – something like display the state of both of those variables, and display the output of both of those calls. Then you could see whether it’s ever hitting the cases

Seems to not be even hitting those cases as I added:

OutputDebugString(TEXT("FLOATING"));

and

OutputDebugString(TEXT("DOCKING"));

just inside their respective case statements and they never showed in my DbgView.exe window - while other debug strings did.

Seems maybe an issue in Notepad++ itself? Need to dig into that.

Cheers.

Ekopalypse

@Michael-Vincent

Seems to work for me

Michael Vincent

@Ekopalypse said in Plugin Docking Panel floating / docked detection:

Seems to work for me

How are you detecting them in PythonScript? Are you just running the Notepad++ demo plugin and added the OutputDebugString() like I mentioned above?

I tried on 2 different plugins (my Git and the new MultiReplace one discussed in another recent thread). Docking and undocking the Dockable windows for either does not trigger a FLOAT or DOCK message to print for me. I even added a MessageBox() to pop incase my OutputDebugString() syntax / incantation was wrong.

Cheers.

Ekopalypse

@Michael-Vincent

No, it is a docked dialog with pythonscript.
Which npp version are you using?
How is the tbdata structure created?
What does the dialog-proc look like?
Is one of the versions of the plugins publicly available?

Michael Vincent

@Ekopalypse

Which npp version are you using?

8.5.4 64-bit

How is the tbdata structure created?

https://github.com/vinsworldcom/nppGitSCM/blob/f91f0aa8f64ef28ca5dd8a95b264143cabc3cd93/PluginDefinition.cpp#L734

What does the dialog-proc look like?

https://github.com/vinsworldcom/nppGitSCM/blob/f91f0aa8f64ef28ca5dd8a95b264143cabc3cd93/DockingFeature/GitPanelDlg.cpp#L533

Is one of the versions of the plugins publicly available?

https://github.com/vinsworldcom/nppGitSCM

Cheers.

Ekopalypse

@Michael-Vincent

I am still using 8.5, I will upgrade to 8.5.4.
Thanks for the links - I’ll play with gitscm and see if I can figure out what’s causing it. Will report back tomorrow.

Ekopalypse

@Michael-Vincent

but the default proc is not used, isn’t it?
Your callback is from GitPanelDlg.cpp
but the message DMN_DOCK is in DockingDlgInterface.h

rdipardo

@Ekopalypse is right.

DMN_FLOAT and DMN_DOCK are passed as the code member of a NMHDR struct, which you intercept by hooking the WM_NOTIFY message.

GitSCM seems to be already doing this correctly in the protected run_dlgProc method (in the DockingDlgInterface.h header).

The debug message should be consistently printed if you put the code under the case labels for DMN_FLOAT and DMN_DOCK, respectively.

Michael Vincent

@rdipardo said in Plugin Docking Panel floating / docked detection:

DMN_FLOAT and DMN_DOCK are passed as the code member of a NMHDR struct, which you intercept by hooking the WM_NOTIFY message.

Indeed. This all makes sense now. I’m overriding the default run_dlgProc() in “DockingDlgInterface.h”. So what I need to do in my run_dlgProc() is if I don’t process the WM_NOTIFY, call the default one:

            DockingDlgInterface::run_dlgProc( message, wParam, lParam );

Works now! Thank you all - have a great weekend!

Cheers.