DPR / LPR - Program without any window or CMD window...

[molly]

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;
2.  
3. {$MODE OBJFPC}
4.  
5. uses
6.   Classes, SysUtils;
7.  
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);
20.  
21.   try
22.     // let stream position point to EOF
23.     if (FileStream.Size > 0) then FileStream.Position := Pred(FileStream.Size);
24.  
25.     // compose log string
26.     WriteStr(LogString, DateTimeToStr(Now), LineEnding, ErrorInfo, LineEnding, LineEnding);
27.  
28.     // Write the actual string to the stream
29.     BytesWritten := FileStream.Write(LogString[1], Length(LogString));
30.  
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;
43.  
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');
52.  
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;
58.  
59. begin
60.   test;
61. end.
62.  

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.

[RAW]

@molly:
Thank you very much for your TFileStream-Example...

..you 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... 

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)