Plugin Docking Panel floating / docked detection
-
@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.
-
I don’t have any experience with coding the docking plugins, but I would think
_isFloatingand_isClosedwould 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 whetherisFloating()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
-
@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
casestatements and they never showed in myDbgView.exewindow - while other debug strings did.Seems maybe an issue in Notepad++ itself? Need to dig into that.
Cheers.
-
-
@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 myOutputDebugString()syntax / incantation was wrong.Cheers.
-
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? -
Which npp version are you using?
8.5.4 64-bit
How is the tbdata structure created?
What does the dialog-proc look like?
Is one of the versions of the plugins publicly available?
https://github.com/vinsworldcom/nppGitSCM
Cheers.
-
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. -
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 -
@Ekopalypse is right.
DMN_FLOATandDMN_DOCKare passed as thecodemember of aNMHDRstruct, which you intercept by hooking theWM_NOTIFYmessage.GitSCM seems to be already doing this correctly in the protected
run_dlgProcmethod (in theDockingDlgInterface.hheader).The debug message should be consistently printed if you put the code under the case labels for DMN_FLOAT and DMN_DOCK, respectively.
-
@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 myrun_dlgProc()is if I don’t process theWM_NOTIFY, call the default one:DockingDlgInterface::run_dlgProc( message, wParam, lParam );Works now! Thank you all - have a great weekend!
Cheers.
