Recent

Author Topic: Windows 10 and FormClose  (Read 22805 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Windows 10 and FormClose
« Reply #15 on: June 26, 2019, 12:53:21 pm »
<slightly off topic>
About 50% of my customers still run computers with 32bit OS versions on it (ranging from XP, few, to Windows 7 majority). Although Windows 7 might be out of support it's still used a lot.

I guess I need to look into compiling and maintaining two versions then.
</slightly off topic>
WHY didn't they upgrade...? It was free (I don't know if it still is..) Government customers? Social sector? you know what I mean.
XP is no longer supported except for - very expensive - special cases. Same goes for Win7 LTS support next year, 2020.
Remember: you are the messenger, don't shoot the messenger....

As for two versions: No, make sure your codebase is bitness agnostic and don't use assembler (that's the niggle)
« Last Edit: June 26, 2019, 12:57:02 pm by Thaddy »
Specialize a type, not a var.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Windows 10 and FormClose
« Reply #16 on: June 26, 2019, 01:04:07 pm »
I forgot to add windows 32 bit SERVER editions are already gone for a long time.
If your customers use that, they have real issues. Gimme the links and I do - with permission - a QED,,, (this time for free)  8) :D )
I am CEH as you know.
Specialize a type, not a var.

rvk

  • Hero Member
  • *****
  • Posts: 6111
Re: Windows 10 and FormClose
« Reply #17 on: June 26, 2019, 01:05:55 pm »
Some computers (workstations within companies) with XP that couldn't be upgraded.
Some other people didn't upgrade to Win10 (reasons ranging from unknown to "didn't want to upgrade" or "didn't want to bother an administrator to do it"). These are companies with 0 to 5 employees (so small companies).

I even have some customers on a DOS-version of our program (inside WinXP-Win7) although that version doesn't get any new development anymore.

Luckily I'm not responsible for their network environment  %)

Anyway, the program is mostly pure pascal so recompiling for Win64 should be relatively easy (changing the source code here and there).

Quote
WHY didn't they upgrade...? It was free (I don't know if it still is..)
Until last year you could still upgrade (under the assumption you used the disabled-features which wasn't checked).
Don't know if that's still the case.

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Windows 10 and FormClose
« Reply #18 on: June 26, 2019, 02:49:59 pm »
@rvk

Quote
Best way to find it is debugging and stepping through the code.
Set some Showmessage at certain points and see if the code reaches it.
Or use F5 to set breakpoints and use the debugger.

If the program only crashes at the end you'll need to strip the code. For example strip the complete CloseQuery and see if it makes a difference. If not, strip some other code until you don't receive the error on exit.

Thanks for the input. I try to track your way (sounds like tracking LISP). By posting I was hoping that someone else would have had a similar issue and a quicker fix.

@others
I am developing in both Win32 and 64 (vers 1.6.4 and 2.0.2). Both are having the same failure at closing the app. WinXP does not have the problem, so I expect that it is Win10 issue. Also, I have a dozen programs that don't have a closing error on either platform.

So, yes, I am probably using a function or format with this program that is not supported anymore. It is an old program, so it might be the GUI interface.
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Windows 10 and FormClose
« Reply #19 on: June 26, 2019, 04:00:50 pm »
Microsoft has been way more strict with rights, so I expect that is the real issue , not the compiler, nor Lazarus. The only thing that got REALLY dropped by fpc is win95/98 support. Note that older versions of the compiler are still available w/o any modern features.

I need a simple code example that reproduces the issue to pinpoint it to you. That's probably just reading it...
« Last Edit: June 26, 2019, 04:04:21 pm by Thaddy »
Specialize a type, not a var.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Windows 10 and FormClose
« Reply #20 on: June 26, 2019, 04:08:16 pm »
Luckily I'm not responsible for their network environment  %)
Actually, morally, you are.... Accidents waiting to happen and then they blame your software......
Be grumpy, you have my permission... >:D 8-)
Specialize a type, not a var.

ASerge

  • Hero Member
  • *****
  • Posts: 2222
Re: Windows 10 and FormClose
« Reply #21 on: June 26, 2019, 09:13:04 pm »
With backtrace active:
In file 'lclproc.pas' at line 902

source://C:\Lazarus\fpc\3.0.2\source\rtl\win32\system.pp(16,1)

Code: Pascal  [Select][+][-]
  1. procedure RaiseGDBException(const Msg: string);  // *lclproc.pas*
  2. begin
  3.   debugln(rsERRORInLCL, Msg);
  4.   // creates an exception, that gdb catches:
  5.   debugln(rsCreatingGdbCatchableError);
  6.   DumpStack;
  7.   if (length(Msg) div (length(Msg) div 10000))=0 then ;   // *line 902*
  8. end;
  9.  
You should look at the stack trace earlier. This procedure is called to pass an error to the debugger, that is, an error has occurred before.

metis

  • Sr. Member
  • ****
  • Posts: 300
Re: Windows 10 and FormClose
« Reply #22 on: June 28, 2019, 12:57:43 pm »
@rick2691

In Case of You use external Libs with Your App:
- Did You ensure, that they close properly with Win10, too ?
- Did You try out SetExceptionMask([exZeroDivide]); {math} ?
With 'SetExceptionMask()' You obtain, what marcov meant with
Quote
In some cases external libraries (...) can toggle  the default state to ignore

Quote
I was hoping that someone else would have had a similar issue and a quicker fix
I don't have Problems with Closing, but with Resizing on Win10:
(More precisely, the Following occurs with Win10 Home, but not with Win10 Pro)

I wrote a FFmpeg-MediaPlayer with LCL (Laz v1.8.4 + FPC v3.0.4), that uses SDL (still SDL1) as VideoOutput (all Win32).
Everything works perfectly on WinXP and Win7 32bit, but on Win10 I got one really insisting Problem:
When the SDL-Window is captured (= internal Videoscreen), it can be resized inside of the PlayerForm, but
Resizing the PlayerForm itself hangs after some Resizes.
When the SDL-Window is released (= external Videoscreen), Resizing of both, the SDL-Window and the PlayerForm
hangs after some Resizings.
In both Cases, no Errors are shown.
There is also a ConsoleVersion of the Player, where there are no ResizingProblems with the SDL1-Window.

Really don't know, if it's because of Win10 or because of still Using SDL1 or because of my Code.
-> No Idea, no Solution, no Fix yet to solve this Problem with the GUI on Win10.  :'(

=> Question to all:
What has changed particularly with Win10 resp. its API, that may cause Behaving the same App differently with Win10 ?
« Last Edit: July 04, 2019, 01:02:23 pm by metis »
Life could be so easy, if there weren't those f*** Details.
My FFmpeg4Lazarus = FFPlay4Laz + FFGrab4Laz + FFInfo4Laz

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Windows 10 and FormClose
« Reply #23 on: July 01, 2019, 08:07:20 pm »
@metis

By excluding certain functions I am pretty sure that my problem is a "floating format" issue. The program is a calculator, so it also has trouble with the str(x:0:4) function. It appears that if "x" is nearly zero (ie. 1123E-240) it throws an exception.

I tried the SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]) method. It did not help, although it was designed for this very reason.

I also tried {+$SAFEFPUEXCEPTIONS}. It is also supposed to help with tracking the errors. But no help.

At this point I do not believe that these things are due to my coding, and although I am hesitant to blame lazarus or freepascal, it does seem possible that their method for managing floating numerals is not completely compatible with Windows10.

Since I have not found any remedy, however, I have to conclude that Windows10 has made the problem to begin with (due to some inane security protocol), because it does not occur with WindowsXP.
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

mas steindorff

  • Hero Member
  • *****
  • Posts: 532
Re: Windows 10 and FormClose
« Reply #24 on: July 01, 2019, 09:43:25 pm »
I jumped from 1.2 to 2.0 and had a similar "onclose" issue. I was not directly writing to file but was using a XMLPropStorage and saving a memo.  I found, for my "exception on close" when away when I unchecked the "use manifest resource" for windows option.  I can tell you why and I've tried to recreate the bug but it's gone away.  I was also playing around with 64 vis 32 bit Lazarus so I can not really say the manifest flag was the fix/issue but it's something quick you can try.
windows 10 &11, Ubuntu 21+ - fpc 3.0.4, IDE 2.0 general releases

ASerge

  • Hero Member
  • *****
  • Posts: 2222
Re: Windows 10 and FormClose
« Reply #25 on: July 01, 2019, 09:50:26 pm »
By excluding certain functions I am pretty sure that my problem is a "floating format" issue. The program is a calculator, so it also has trouble with the str(x:0:4) function. It appears that if "x" is nearly zero (ie. 1123E-240) it throws an exception.
You can make an example? On my machine the following code is executed without problems with x32 and x64:
Code: Pascal  [Select][+][-]
  1. {$APPTYPE CONSOLE}
  2. {$IFDEF FPC} {$MODE OBJFPC} {$ENDIF}
  3. {$LONGSTRINGS ON}
  4.  
  5. uses Math;
  6.  
  7. var
  8.   X: ValReal = 1123;
  9.   S: string;
  10. begin
  11.   X := X * Power(10, -240);
  12.   Str(X:0:4, S);
  13.   Writeln(S);
  14.   Writeln(X);
  15.   Readln;
  16. end.

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Windows 10 and FormClose
« Reply #26 on: July 02, 2019, 12:07:09 pm »
@ASerge, notes are in the code.

But I do not have

{$APPTYPE CONSOLE}
{$IFDEF FPC} {$MODE OBJFPC} {$ENDIF}
{$LONGSTRINGS ON}

in my code.

I have

{$mode objfpc}{$H+}
interface
uses
  {$IFDEF WINDOWS}
  win32proc,
  {$ENDIF}

...

implementation

{$R *.lfm}

...



Code: Pascal  [Select][+][-]
  1. //These are the global variables
  2.  
  3. var
  4.   AppForm: TAppForm;
  5.   Reg0,Reg1,Reg2,Reg3,Reg4,Lst,Hrs,Hms: double; // reg0 is for swapping display stack
  6.   Mem1,Mem2,Mem3,Mem4,Mem5,Mem6,Mem7,Mem8,Mem9: double;
  7.   Err,Dsp: integer;
  8.   TmpStr,LstDsp,PrgmFolder: string;
  9.   NewReg,SavReg,StoActive,HrsMode: boolean;
  10.  
  11.  
  12. //This is the function that creates an onclose crash.
  13. //If I exclude this call the program does not crash at OnClose.
  14. //Debug indicates that it is Str(Reg1:0:Dsp,TmpStr) ... it is as if Reg1 has junk data in it.
  15. //But I don't understand why UpdDsp is firing at OnClose to begin with.
  16.  
  17. procedure TAppForm.UpdDsp;
  18. var x,z:integer;
  19. begin
  20. try
  21. Str(Reg1:0:Dsp,TmpStr); // *** crash point at OnClose ***
  22. x:= pos('.',TmpStr);
  23. z:= length(TmpStr);
  24. if (x>17)or(z>17) then  // this only fires when a number is very large ... large numbers are not the problem.
  25.    begin
  26.    TmpStr:= FloatToStrF(Reg1,ffExponent,17,0); //showmessage(TmpStr);
  27.    end;
  28. RegBox1.text:= TmpStr;
  29. finally
  30. end;
  31.  
  32. try
  33. Str(Reg2:0:Dsp,TmpStr);
  34. x:= pos('.',TmpStr);
  35. z:= length(TmpStr);
  36. if (x>17)or(z>17) then
  37.    begin
  38.    TmpStr:= FloatToStrF(Reg2,ffExponent,17,0); //showmessage(TmpStr);
  39.    end;
  40. RegBox2.text:= TmpStr;
  41. finally
  42. end;
  43.  
  44. try
  45. Str(Reg3:0:Dsp,TmpStr);
  46. x:= pos('.',TmpStr);
  47. z:= length(TmpStr);
  48. if (x>17)or(z>17) then
  49.    begin
  50.    TmpStr:= FloatToStrF(Reg3,ffExponent,17,0); //showmessage(TmpStr);
  51.    end;
  52. RegBox3.text:= TmpStr;
  53. finally
  54. end;
  55.  
  56. try
  57. Str(Reg4:0:Dsp,TmpStr);
  58. x:= pos('.',TmpStr);
  59. z:= length(TmpStr);
  60. if (x>17)or(z>17) then
  61.    begin
  62.    TmpStr:= FloatToStrF(Reg4,ffExponent,17,0); //showmessage(TmpStr);
  63.    end;
  64. RegBox4.text:= TmpStr;
  65. finally
  66. end;
  67. ResetFocus;
  68. Update;
  69. end;
  70.  
  71.  
  72. //I use this exception handler which writes to a log file.
  73. //It does not activate at OnClose, so the crash is not the program.
  74. //Yet debug is indicating that the crash is on account of Str(Reg1:0:Dsp,TmpStr).
  75. //It is as if there are some trashed functions or variables that are not being purged at OnClose.
  76.  
  77. procedure TAppForm.LogException(Sender: TObject; E: Exception);
  78. var ErrorFile: TextFile;
  79.     ErrorInfo: String;
  80.     AppPath,SenderMsg: string;
  81. begin
  82. SenderMsg:= E.Message;  // e.message contains line-feed
  83. AppPath:= ExtractFilePath(ParamStr(0));
  84. AssignFile(ErrorFile, AppPath+'CmdRPN.log');
  85. if FileExists(AppPath+'CmdRPN.log')
  86.    then Append(ErrorFile)
  87.    else Rewrite(ErrorFile);
  88. ErrorInfo:= DateTimeToStr(Now)+' Unhandled exception';
  89. if Assigned(Sender)
  90.    then ErrorInfo:= ErrorInfo+' in '+Sender.UnitName+'->'+Sender.ClassName;
  91. ErrorInfo:= ErrorInfo+': '+SenderMsg;
  92. try WriteLn(ErrorFile, ErrorInfo);
  93.     finally
  94.     CloseFile(ErrorFile);
  95.     ShowMessage('Application fault... message saved: CmdRPN.log');
  96.     end;
  97. end;
  98.  
  99. //These are the Close functions that I employ ... there is no call to UpdDsp in them.
  100.  
  101. procedure TAppForm.FormClose(Sender: TObject; var CloseAction: TCloseAction);
  102. begin
  103. CloseAction:= caFree;
  104. end;
  105.  
  106. procedure TAppForm.FormCloseQuery(Sender: TObject; var CanClose: boolean);
  107. var CfgFile: TextFile;
  108.     DatStr: string;
  109.     OK: boolean;  // DatOK: boolean;
  110.     IOval: integer;  // longint;
  111. begin
  112. AssignFile(CfgFile, PrgmFolder+'CmdRPN.cfg');
  113. {$I-} Rewrite(CfgFile) {$I+};
  114. IOval:=IOresult; OK:=(IOval=0);
  115. if OK then   // was DatOK
  116.    begin try
  117.          Str(Reg0,DatStr); Writeln(CfgFile,DatStr);  // register display
  118.          Str(Reg1,DatStr); Writeln(CfgFile,DatStr);
  119.          Str(Reg2,DatStr); Writeln(CfgFile,DatStr);
  120.          Str(Reg3,DatStr); Writeln(CfgFile,DatStr);
  121.          Str(Reg4,DatStr); Writeln(CfgFile,DatStr);
  122.          Str(Mem1,DatStr); Writeln(CfgFile,DatStr);  // storage memory
  123.          Str(Mem2,DatStr); Writeln(CfgFile,DatStr);
  124.          Str(Mem3,DatStr); Writeln(CfgFile,DatStr);
  125.          Str(Mem4,DatStr); Writeln(CfgFile,DatStr);
  126.          Str(Mem5,DatStr); Writeln(CfgFile,DatStr);
  127.          Str(Mem6,DatStr); Writeln(CfgFile,DatStr);
  128.          Str(Mem7,DatStr); Writeln(CfgFile,DatStr);
  129.          Str(Mem8,DatStr); Writeln(CfgFile,DatStr);
  130.          Str(Mem9,DatStr); Writeln(CfgFile,DatStr);
  131.          Str(Dsp,DatStr); Writeln(CfgFile,DatStr); // decimal display
  132.          if HrsMode=true then DatStr:='1'  // HmsMode ...Dms
  133.                          else DatStr:='0'; // HrsMode ...Dec
  134.          Writeln(CfgFile,DatStr); // angle mode
  135.          finally
  136.          Flush(CfgFile);
  137.          CloseFile(CfgFile);
  138.          CanClose:= true; //showmessage('closing by CanClose');  // good
  139.          end;  // end try
  140.    end else begin
  141.             CloseFile(CfgFile);
  142.             CanClose:= false;
  143.             end;
  144. CanClose:= true; //showmessage('closing by CloseQuery');  // good
  145. end;
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

wp

  • Hero Member
  • *****
  • Posts: 11854
Re: Windows 10 and FormClose
« Reply #27 on: July 02, 2019, 12:29:04 pm »
Code snippets like these are not very helpful unless the issue is very straightforward. If someone wants to use your code to reproduce or study the error he still has a lot to add by himself for which there are numeous possibilities. Better to post a compilable project. The main effect is for yourself because it forces you to remove everything not needed, and this quite often gives you an idea of what causes the issue.

Not your problem, but:
- Use global variables only when absolutely necessary. TmpStr, for example, is needed only locally with several routines. Declare it locally.
- Why are you using empty finally blocks in try-finally-end? This is absolutely useless.

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Windows 10 and FormClose
« Reply #28 on: July 02, 2019, 01:53:39 pm »
@wp
Quote
Why are you using empty finally blocks in try-finally-end? This is absolutely useless.
Because the editor automatically kicks the 'finally' in. I leave them because I might need them later. They do any harm.
Quote
Code snippets like these are not very helpful
I have posted the code because ASerge asked me to.

@ASerge
The crash does not need a large number to crash. I can add 55 and 22 together, and it crashes when I hit the close button at the top of the form. Nevertheless, debug reports that Str() has tried to convert a large number.
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

wp

  • Hero Member
  • *****
  • Posts: 11854
Re: Windows 10 and FormClose
« Reply #29 on: July 02, 2019, 02:53:04 pm »
Quote
Code snippets like these are not very helpful
I have posted the code because ASerge asked me to.
I am asking for it, too. Having no compilable code often leads to endless discussions because everybody does and understands things a bit different.

 

TinyPortal © 2005-2018