🚀 go-pugleaf

"Monzer George Yazigi" <monzer_yazigi@hotmail.com> wrote in message 
news:4no184p7qt0db7ug73f0uocnnh1180h527@4ax.com...
> Dear All
> Not sure if this the right place or not for this message.
>
> what is the best approach to implement a Logging Functionality within
> my application? I need this for debuging purposes for end user. So
> that when an error occur, end user can send me the log file to
> inspect.
[...]

MadExcept and EurekaLog two of the more popular exception logging tools 
around.  I know you can try MadExcept for free, haven't looked at EurekaLog 
in a while.  Both are active & maintain a presence here in the 
thirdpartytools group.

-- 
Ray Marron

MadExcept and EurekaLog are both great products bur depending on your needs 
and budget you can also roll your own very quickly.

Creating a basic screen and/or file logging is itself not complex. Just 
create a logging unit that your main form inits and publish some logging 
methods from it. Internally make sure you flush the data out to file for 
file logging. For multi-theraded apps use synchronize or better yet post 
logging messages to main thread that then calls your unit.

Main work is then to simply put logging statements in appropriate places of 
your code and also include exceptions (inlucding Application.OnException ).

Raul



"Monzer George Yazigi" <monzer_yazigi@hotmail.com> wrote in message 
news:4no184p7qt0db7ug73f0uocnnh1180h527@4ax.com...
> Dear All
> Not sure if this the right place or not for this message.
>
> what is the best approach to implement a Logging Functionality within
> my application? I need this for debuging purposes for end user. So
> that when an error occur, end user can send me the log file to
> inspect.
>
> Also, is there a why to enable / disable this functionality? For
> example depending on the command line options used to start the
> application.
>
> Best Regards 

> what is the best approach to implement a Logging Functionality within
> my application? I need this for debuging purposes for end user. So
> that when an error occur, end user can send me the log file to
> inspect.
>
> Also, is there a why to enable / disable this functionality? For
> example depending on the command line options used to start the
> application.


i have library function:

procedure LogToFile(filename: string; const s: string);
var
     f: Textfile;
     FilePath: string;
begin
    FilePath := ExtractFilePath(filename);
     if not DirectoryExists(FilePath) then
          CreateDir(FilePath);

     System.Assign(f, filename);
     if FileExists(filename) then
          System.Append(f)
     else
          Rewrite(f);
     try
        WriteLn(f, S);
     finally
          System.Close(f);
     end;
end;


i usually then create a procedure in the application:

procedure FileLog(const LogString: string);
var
     szLogFile: string;
begin
     szLogFile := 
ExtractFilePath(ParamStr(0))+'Logfiles\'+FormatDateTime('yyyymmdd', 
Now)+'.log';
      {The zero-th parameter to an application is, by convention, the
           appliation's path and filename. But since you cannot trust this 
value,
           you should use GetModuleFilename instead.
         Fortunatly, ParamStr() detects if you want the zero-th parameter
       and instead calls GetModuleFilename. As a result, it is safe and 
proper
       to use ParamStr(0) to get our image filename}

     LogToFile(szLogFile, DateTimeToISOStr(Now)+' '+LogString);
end;



This way the logfile rolls over each day, and it handily sitting in a 
Logfiles folder.

Although this is bad bad for anyone running as a standard user under XP, and 
should use SHGetFolderPath to store the log files in the user's local (i.e. 
non-roaming) application data folder (CSIDL_LOCAL_APPDATA). e.g.:
    c:\documents and settings\Monzer\Local Settings\Application Data
    c:\users\monzer\appdata\local

The call to SHGetFolderPath is left as an excercise for the reader :)