About 'initialization in a DLL' see the attached image from a quick test as illustration.
About 'name for the logfile via environment': yes, i did read about this possibliity, but it hadn't been my top favorite to pursue
(probably a matter of taste, although i can imagine there are good reasons tu use the environment variable for certain use-cases).
To retrieve from inside the dll code the path and name (without extension) of the 'host applicaton' shouldn't be a problem.
Martin, thank you so much for having involved in this matters and exchange so intensively!
I hope that other uses might benefit from it too (but i'd think so).
From my side i'll try to summarize my findings as of today, for to bring the pieces together at one place.
My personal summary regarding the "HowTo use DebugLn in a stand-alone exe and a DLL"A. I want to use "DebugLn" in my stand-alone executable with results in a log file. What i'd need to do?
1a. In the main unit: include "LazLogger" in the use claus
uses ........ ,
{$IFDEF DEBUG}
LazLogger;
{$ENDIF}
1b. In any other dependent/included unit, in which DebugLn should be used, include "LazLoggerBase". See
https://wiki.freepascal.org/LazLogger2. Project Options > Compiler Options > 'Config and Target': 'Win32 gui application (-WG)' => no
(Otherwise a log file might be created, but you'll see no output from DebugLn in it)
3. Run Parameters > Command line parameters : --debug-log=<logfile_path_and_name>
Note: output written with DebugLn will be added to the log file by default. It survives sessions.
If one wants to have a 'fresh' logfile for each session, there are already existing properties available, or simply remove the log file before a session.
B. I want to use "DebugLn" in my plugin DLL and want to have a log file.
This relates to other forms/units herein too, as well as to embedded/included code, like .inc files. What i'd need to do?1a. In the main unit, or other forms. or "used" units ("use myUtils"), include "LazLogger" in their use clause if you want to use DebugLn herein:
uses ........ ,
{$IFDEF DEBUG}
LazLogger
{$ENDIF}
1b. In any other code being within the scope of the inheritance tree of your controls, in which DebugLn should be used, there's nothing else to do, see 3b.
2. An uncheck of 'Win32 gui application' (in Compiler Options > 'Config and Target') is _Not_ needed here, afais.
3. But what could be the path and name of the debug log file? With "Run Parameters > Command line parameters" one won't achieve.
The 'Host application' will interprete the parameter, and it will it interprete in a way one cannot predict.
Afaik, one cannot pass command line parameters to a DLL, or, otherwise, how to define such in the project settings?
Fortunately a predefined "DebugLogger" object does already exist that allows to add/append contents from diverse sources.
3a. Within your DLL app, in each independent form or an "use"d unit wherein DebugLn should be used, set at an appropriate place:
procedure TMyFormXYZ.FormCreate // Example
.....
if DebugLogger <> nil then
TLazLoggerFile(DebugLogger).LogName := <your_desired_logfile_pathname>;
3b. For each unit attached via class inheritance, in which DebugLn should be used. there's nothing special to do.
It will be seen via the inheritance tree (at least that would be my interpretation).
Example: you have a listview in the form, and can now place a DebugLn in a customlistview.inc without further measures.
3c. That does even work when using build mode Release as well, as far as i can actually see! (without having used "IfDef Debug" of course)
4. Please note that there is also the possibility to set log file name via an environment variable (i didn't test this yet).
Recent
