Forum > General

[Solved] Q: Debug a plugin DLL - can we do OutputDebugstring to the event log?

<< < (2/2)

d7_2_laz:
@Martin_fr:
Thank you kindly for your understanding!
Of course i'd regret when not being able to employ this useful little helper from within the app's code lines, ,complementing the capabilties of the debugger itself
Nevertheless i'd not call it a bug .... because i really don't know whether it's foreseen to be part of the scope of OutputDebugView to support DLLs.

If any opinion here should come up, i'd be happy to provide a self-containing example (containing also a portable notepad++, with all config), where out-of-the-box one could reproduce by click-and-play (unzip, dblclick on the lpi, compile, Run and see the eventlog) without taking care about downloading and adapting internal paths.
Precondition would be only: we agree on a certain root path (eg. D:\_test_nppPlugin), so that no adaptions would be needed to be done.
Size approx. 14,5 MB (due to the size of the NPP host application; portable version; size already reduced by removing most of the localization files)).
But there should be a decision: should we support or not?

Origin of the demo: rdipardo's 'Notepad++ Plugin Template for Delphi & Lazarus':
https://bitbucket.org/rdipardo/delphiplugintemplate/src/default/Readme.textile
Some of (imo) strange phaenomenoms of the demo i'd already addressed on the Notepad++'s plugin side, or will do so within the new Wiki from rdipardo.
I needed only a few minutes to make the demo initially work with Lazarus; with Delphi, i'd assume, if should be done fast too.
And this could be interesting too: to verify: does (newest) Delphi support this (OutputDebugView from within a DLL)?

@440bx
Oh yes, the good old DebugView, i  remember .... thank you for the hint!
I'm a bit sceptical, looking onto the supported OS versions (no Win 10) as well as the sentence "will captute Win32 OutputDebugString" etc.
I tried with Delphi 7 (32bit) via an old plugin DLL (from 2013) and from within and exe. But i could not see output. I remember ages ago (Windows XP) i had one though.
Sad .. would be nice to be able to use DebugView for this purpose .. but maybe i do something wrong.

Martin_fr:
Well, I don't see, why it shouldn't work in a dll. Have you tried that the same OutputDebugView  works in a normal app?

Have you checked, if it is included in the "Debug output" of the "Ide Internals" (and does not get lost at some later stage...).

Also, I don't know what OutputDebugView maps to: OutputDebugViewW or OutputDebugViewA.
Try either of them explicitly.
Maybe only one is supported.

d7_2_laz:
"works in a normal app?"    -> Yes, works very fine here  ... // "OutputDebugString" (*)

"if it is included in the "Debug output" of the "Ide Internals"  -> still my Todo, sorry!

"Try either of them explicitly"    -> tried both at the same place. Both work from within the exe, but not from within a DLL (the demo DLL)

(*) Edit: the "DebugView" app from sysinternals v4.90 didn't work for me here at all, neither 32bit version (with Delphi 7)  or 64bit version w. Lazarus 3.6 64 bit. On Win 10. - Hopefully i did nothing wrong.
Remember roughly it worked together with Delphi7 on an older OS (XP).

Martin_fr:
I just wrote a test library, and a test pascal program.

I tested
- with the function used via "external ... name", and with OpenLibrary/GetProcAddress.
- FpDebug and gdb 7.9.1
- W/A versions

I got the output of all calls, from within the library and the main app.

Tests performed on Win-10 / 64 bit / 64bit Lazarus and 64 bit program.

Lazarus 4.0RC

-------------------

So I don't know why it does not work for you.

I don't know if notepad++ does something....

Have you made sure, that the code in your library is executed ?
E.g., if you replace it by

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---PByte(0)^:=1;Do you get a crash?

d7_2_laz:
These are very very interesting points Martin. And the question ('the code in your library is executed ?') might sound trivial, but i fear in fact it is not.
It touches a chapter that was unclear for me since the beginning i deal with this plugin demo:

- Given, Npp is installed or unzipped into <npp-dir>.
- Npp expects the plugin to exist in/as:  <npp-dir>\plugins\<plugin-name>\<plugin-name>.dll
  If not at least one copy of the dll does exist here following this rule, the plugin won't never be visible in the Npp menu.
- We can set a 'host application' to <npp-dir>\Notepad++.exe
- But what is 'Working directory' here?  <npp-dir>, or <npp-dir>\plugins (because Npp might extend that implicitely to the correct path, given by the dll's name?)
  Or to (fully extended:) <npp-dir>\plugins\<plugin-name>  ?
-> Wherefrom should the debugger know, where Npp does expect the dll?  -> no chance
-> Wherefrom should Npp know, where Lazarus compiles? -> no chance

The solution: the compiler option 'Target-filename (-o)' must be set to <npp-dir>\plugins\<plugin-name>\$NameOnly($(ProjFile))

And so - see image.

Hard lessons learnt: (was everybody reading really fully aware of it? Me not .....)
If a DLL plugin should be debugged (or OutputDebugString used), it's not sufficent to set 'host application' (and maybe working-dir).
It MUST be assured that the path of the compiler output physically is the same where the host application does expect the plugin to exist.
Well-known to all except me?

Could be noted in the documentation ...

Navigation

[0] Message Index

[*] Previous page

Go to full version