Author Topic: DPR / LPR - Program without any window or CMD window...  (Read 7972 times)


  • Hero Member
  • *****
  • Posts: 2345
Re: DPR / LPR - Program without any window or CMD window...
« Reply #15 on: July 12, 2016, 04:19:05 pm »
Sorry for the delay,

That's weird... shouldn't be the case, on my machine I can't see anything like that. Someone tested this little code on an XP-PC and W8.1-PC and W10-Pc and told me, that it's working fine with other Windows-Versions... 
After some research, i concluded this is a windows specific issue.

If the desktop is relatively clean then everything goes fine but, the moment you have your desktop cluttered with about 10+ open application windows then the problem becomes clearly visible. Might even be an application specific issue (i stopped right there as i could not be bothered as in basics the technique from your code works).

Yes, I probably should check if I can reduce that little Log-creation. Maybe I should take a look at TFileStream. The main reason why it looks like this is probably the circumstance, that loading a file could fail and then I would like to save at least the lastest ErrorInfo. But it's always good to make things faster, more stable or use less overhead... I need to check that.
Of course the loading could fail. But ask yourself the question: What is the reason to _load_ the already stored loglines ?

The only reason, until now, was that you 'inserted' new loglines in front of the already logged ones. If you would lift that requirement/restriction then there would be no need anymore to load them... now would there ? ;)

I also use logfiles to monitor program progress. So not only logging exceptions. That way i can 'follow' newly introduced code by letting the program "flip a switch" in case a new release causes issues with the newly introduced code. Additional settings allow for more verbose logging in case required.

That could end up in logfiles that are getting a bit bigger, and even attaching new loglines at the bottom is causing performance issues in the end. Reason why i usually truncate logfiles around 100/200 MB. Of course, mileage may vary depending on the hardware.

Another option is using something like (windows specific) OutputDebugString(), in which case a special app is able to visualize the logging for you.

Most of the above not very interesting for a project as small as shown by you but, the following snippet might get yourself familiar with using a filestream.

Code: Pascal  [Select][+][-]
  1. program duError2;
  5. uses
  6.   Classes, SysUtils;
  8. Procedure ErrorLog(ErrorInfo: String);
  9. const
  10.   LogFileName = 'MyProgramName.log';
  11. Var
  12.   FileStream : TFileStream;
  13.   LogString : String;
  14.   BytesWritten : Integer;
  15. begin
  16.   // create or append ?
  17.   if not FileExists(LogFileName)
  18.   then FileStream := TFileStream.Create(LogFileName, fmCreate)
  19.   else FileStream := TFileStream.Create(LogFileName, fmOpenReadWrite);
  21.   try
  22.     // let stream position point to EOF
  23.     if (FileStream.Size > 0) then FileStream.Position := Pred(FileStream.Size);
  25.     // compose log string
  26.     WriteStr(LogString, DateTimeToStr(Now), LineEnding, ErrorInfo, LineEnding, LineEnding);
  28.     // Write the actual string to the stream
  29.     BytesWritten := FileStream.Write(LogString[1], Length(LogString));
  31.     // check if number of bytes written matches what was expected to write
  32.     if (BytesWritten <> Length(LogString)) then
  33.     begin
  34.       // Since number of bytes written to stream did not match the length of
  35.       // the string we were trying to write this could be considered a serious
  36.       // error.
  37.       // act accordingly, in case no exception was raised/handled
  38.     end;
  39.   finally
  40.     FileStream.Free;
  41.   end;
  42. end;
  44. procedure test;
  45. type
  46.   THelp = record
  47.     ClassName : string;
  48.     Message   : string;
  49.   end;
  50. var
  51.   E: THelp = (ClassName : 'SomeClassName'; Message: 'someMessage');
  53. begin
  54.   ErrorLog('SearchCallback'+#13#10+E.ClassName+#13#10+E.Message);
  55.   sleep(1000);
  56.   ErrorLog('MinAllWnds'+#13#10+E.ClassName+#13#10+E.Message);
  57. end;
  59. begin
  60.   test;
  61. end.

You could always opt for copying the old logfile first and start a fresh one in case you really are worried about messing up existing logdata. But honestly, in case filestream is able to mess up things then this usually means there are disk/filesystem errors and, there is nothing that you as applicaton developer can do about those.
« Last Edit: July 12, 2016, 04:25:10 pm by molly »


  • Hero Member
  • *****
  • Posts: 867
Re: DPR / LPR - Program without any window or CMD window...
« Reply #16 on: July 15, 2016, 09:47:29 pm »
Thank you very much for your TFileStream-Example...

Quote have your desktop cluttered with about 10+ open application windows then the problem becomes clearly visible.
Ok, that's possible, I normally don't use so much programs at the same time, so maybe that's the reason why I didn't see anything like that...
My individual maximum is normally 4 or 5 PRG's at the same time.

...What is the reason to _load_ the already stored loglines ?
For me it's quite interesting to see if there was maybe another problem ealier...
In some cases it's even of interest how many ErrorMessages of the same type are in the log. Sometimes it's easier to calculate what the problem is.

Reason why i usually truncate logfiles around 100/200 MB.
Ok, that's big... In my case those files are very small and mostly only important during the program creation...
Of Course, when the program is ready I don't want to see anything like that..  :)

Now I've got 3 Versions:
See the attachment...  :D

The Restore Version normally needs a Path-Correction, but I couldn't manage this without a Delay or Sleep or Timer...
So I decided to stop trying for now...
All steps that are necessary are separately watched were easy... but when it comes to put them all together, then a special timing is needed otherwise it wouldn't work.

I mean this:
1. Bring the window to top
2. Send VK_F4 and VK_ESCAPE to the WinEx-Window
3. Find the EDIT-comp of the WinEx-Window
4. Send the Path with WM_SetText
5. Finally send VK_Return

All steps are very easy, but all together in one step and very fast they are not that easy for me... and when I use Sleep then it takes too much time... compared to the other versions.
But no problem at all... I've got my versions and they are running fine so far... (the first version is sometimes not able to bring the second window to front, but the other 2 Versions are running stable on my machine)
Windows 7 Pro (x64 Sp1) And Windows XP Pro (x86 Sp3) - LAZARUS 2.0.8 FPC 3.0.4 - TRUNK 2.1.0 FPC 3.3.1
// This is polarity (hell) and hell is reigned by lies, nothing but lies. Be careful what you believe ...
// There are 10 types of people in this world, those who understand mind control and ...


TinyPortal © 2005-2018