Recent

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

rick2691

  • Sr. Member
  • ****
  • Posts: 375
Re: Windows 10 and FormClose
« Reply #45 on: July 07, 2019, 06:20:11 pm »
@Cyrex

Can you be more specific about the trunk etc. What is its Web address? Is it many installs? What are their names. Where do you assign your script to effect your features?
Windows 10, LAZ 1.6.4, FPC 3.0.2, SVN 54278, i386-win32-win32/win64, forms use windows unit

Cyrax

  • Hero Member
  • *****
  • Posts: 819
Re: Windows 10 and FormClose
« Reply #46 on: July 08, 2019, 08:42:35 am »
@Cyrex

Can you be more specific about the trunk etc. What is its Web address? Is it many installs? What are their names. Where do you assign your script to effect your features?

It might be easiest to get fpcupdeluxe and build the FPC trunk with it :  https://wiki.lazarus.freepascal.org/fpcupdeluxe

rick2691

  • Sr. Member
  • ****
  • Posts: 375
Re: Windows 10 and FormClose
« Reply #47 on: July 08, 2019, 02:55:57 pm »
I am going to hold off on going the fpcupdeluxe route at this point.

Since I am operating on Win10 and have the 2.0.2 compiler, what are the proper settings for compiling for 32 bit and 64 bit applications?

At present my Target settings are at Default, and I have assumed that would be a 64 bit app.

I have also been using the Default setting with the 1.6.4 compiler, and I was assuming that was doing 32 bit apps.

With both they use the Win32 widgetset. There is no widgetset for Win64.
Windows 10, LAZ 1.6.4, FPC 3.0.2, SVN 54278, i386-win32-win32/win64, forms use windows unit

rvk

  • Hero Member
  • *****
  • Posts: 4189
Re: Windows 10 and FormClose
« Reply #48 on: July 09, 2019, 09:34:25 am »
You also need to launch from an exe. If you do it by run, it is protected.
%)

If you use Run, the program is launched from an exe. The Lazarus IDE (lazarus.exe).
So I don't understand why none of us can reproduce this error.

From what .exe are you launching this to get te error?
Are you also getting the error if you just execute the program from the Windows explorer?

rick2691

  • Sr. Member
  • ****
  • Posts: 375
Re: Windows 10 and FormClose
« Reply #49 on: July 09, 2019, 12:54:46 pm »
@rvk

Run is a protective environment. You have to compile the program as a stand alone exe. I always move it to a new folder, and activate it from there.

The program disappears from the screen, and an Unhandled Exception message appears. If you look at the Windows Task Manager you will see that the program has not been destroyed. It is destroyed after you press OK.

Sometimes there can be many Unhandled Exception messages that show up at the same time. I just go to the Windows Task Manager and end the task for the program. Otherwise you can spend 5 or 10 minutes clicking OK's.

As requested earlier, I would like to know if I have the correct settings for my Compiler Options. I am using the Default settings, but I have Debugging turned off, as it would be if I gave the program to someone else. To date, Debugging has not helped me.
Windows 10, LAZ 1.6.4, FPC 3.0.2, SVN 54278, i386-win32-win32/win64, forms use windows unit

rvk

  • Hero Member
  • *****
  • Posts: 4189
Re: Windows 10 and FormClose
« Reply #50 on: July 09, 2019, 01:07:08 pm »
Still not getting the error.
Just newly installed Laz202 32bit in a separate dir with c:\laz202\config as config directory.
So with all the default settings, just opened your example and pressed Shift+F9 to compile and run the .exe outside the IDE.

Do you have any virusscanner active (other than Windows Defender) ?
Could you disable it temporarily?

rick2691

  • Sr. Member
  • ****
  • Posts: 375
Re: Windows 10 and FormClose
« Reply #51 on: July 09, 2019, 01:53:24 pm »
@rvk

Yes, I use "McAfee LiveSafe," and Windows Defender is disabled. I will try by disabling McAfee later. For now I have discovered something promising.

Code: Pascal  [Select][+][-]
  1. procedure TAppForm.FormClose(Sender: TObject; var CloseAction: TCloseAction);
  2. //begin
  3. //CloseAction:= caFree;
  4.  
  5. var
  6.   i: Integer;
  7.   C: TComponent;
  8. begin
  9.   for i := ComponentCount - 1 downto 0 do
  10.   begin
  11.     C := Components[i];
  12.     if C is TCustomForm then
  13.     begin
  14.       //writeln('Component[',i,'] is  Form: ',C.ClassName,':',C.Name);
  15.       FreeAndNil(C);
  16.     end;
  17.   end;
  18. end;

I changed the above Close method to a code that is posted elsewhere on the forum.

With no incompatibilities set, it raised an exception the same as before. When I set Win8 compatibility, it has not raised any exceptions ... for several attempts with testing. At present I am going to just wait and  see.

Windows 10, LAZ 1.6.4, FPC 3.0.2, SVN 54278, i386-win32-win32/win64, forms use windows unit

rvk

  • Hero Member
  • *****
  • Posts: 4189
Re: Windows 10 and FormClose
« Reply #52 on: July 09, 2019, 02:01:13 pm »
You shouldn't need to FreeAndNil() all those components on the form.
The owner is TAppForm itself so they will be destroyed when the form itself is destroyed.

And in fact... the FreeAndNil() is never executed because you check for "is TCustomForm". And you have no TCustomForm's in the Components of that form. Try setting a breakpoint with F5 on line 15 and see that it's never executed.

Also, setting WinXP and Win8 compatibility shouldn't be need either.
Doing so will only complicate your issue because that shouldn't be the cause.

For now, my guess is McAfee. In fact, disabling the virusscanner should have been the first item on your list to try when having explainable issues with an OS.

I changed the above Close method to a code that is posted elsewhere on the forum.
With no incompatibilities set, it raised an exception the same as before. When I set Win8 compatibility, it has not raised any exceptions ... for several attempts with testing. At present I am going to just wait and  see.
In fact, this makes my suspicions only bigger.
Because your FormClose-changes actually do nothing, the only thing that made the difference would be setting that Win8 compatibility. And that could affect the McAfee virusscanner too. But you don't want to do that every time.

So, first try to set everything back to normal (normal compat and normal options in Lazarus) and disable the virusscanner (temporarily).

« Last Edit: July 09, 2019, 02:15:41 pm by rvk »

rick2691

  • Sr. Member
  • ****
  • Posts: 375
Re: Windows 10 and FormClose
« Reply #53 on: July 09, 2019, 04:55:24 pm »
@rvk

Most of what you say is true. I had not implemented beforehand on account of the same thought. Nevertheless, I have been rigorously trying to get a fail, and it has not happened.

I believe there is a slight flaw in how the IDE is destroying the form. By slight I mean that it happens here, and some have confirmed that it happens with them but for different reasons.

It is some sort of floating garbage. It should be analyzed by the engineers. But I have appealed to them about other cases in the past. I do not intend to do so again.
Windows 10, LAZ 1.6.4, FPC 3.0.2, SVN 54278, i386-win32-win32/win64, forms use windows unit

rvk

  • Hero Member
  • *****
  • Posts: 4189
Re: Windows 10 and FormClose
« Reply #54 on: July 09, 2019, 05:04:02 pm »
I believe there is a slight flaw in how the IDE is destroying the form. By slight I mean that it happens here, and some have confirmed that it happens with them but for different reasons.
The IDE isn't in question because you say it also happens when you run it outside the IDE (as release version). If it's something from Lazarus it would be the LCL-code itself.

You might want to gather information about the other computers which give the error. Do they all run McAfee? Did you try to disable it yet? Could you run your .exe in a virtual machine (or another clean machine without any other software or virusscanner). The latest Windows 10 version has a Sandbox function which is a very clean Windows version onto itself. If the program runs fine there it must be something with your configuration (and still my best bet is the virusscanner as I have experienced 99% of the time).

Quote
It is some sort of floating garbage. It should be analyzed by the engineers. But I have appealed to them about other cases in the past. I do not intend to do so again.
It can only be analysed when they can reproduce the error. That's the whole problem. You (with some of your other clients) are the only ones with this problem. We would be very (and I mean very very) happy to diagnose this problem if we could only reproduce it.

ASerge

  • Hero Member
  • *****
  • Posts: 1618
Re: Windows 10 and FormClose
« Reply #55 on: July 09, 2019, 06:05:14 pm »
It can only be analysed when they can reproduce the error. That's the whole problem. You (with some of your other clients) are the only ones with this problem. We would be very (and I mean very very) happy to diagnose this problem if we could only reproduce it.
I was also able to reproduce the error. Rarely, after a series of operations (in the program), and closing, performed quickly and on the keyboard. The error is the same as rick2691 pointed out. Here are my stats: reproduce on Windows 7, Windows 10, on a physical computer, and in VirtualBox. With built-in Windows defender, with other antivirus (not listed above). Only in the 32-bit version (program). Tested only on 64-bit version of Windows.

rvk

  • Hero Member
  • *****
  • Posts: 4189
Re: Windows 10 and FormClose
« Reply #56 on: July 09, 2019, 09:23:09 pm »
I was also able to reproduce the error. Rarely, after a series of operations (in the program), and closing, performed quickly and on the keyboard.
Could you elaborate as to the sequence?

What keystrokes, fast after each other, could cause the direct error?
And was the error after closing, directly after input or also after some idle time and then closing?

How fast is your system? Could that be a factor? (slower machine so not everything is handled yet)

(I'll try tomorrow again on a slower system)

wp

  • Hero Member
  • *****
  • Posts: 7250
Re: Windows 10 and FormClose
« Reply #57 on: July 09, 2019, 09:58:49 pm »
For now I have discovered something promising.

Code: Pascal  [Select][+][-]
  1. procedure TAppForm.FormClose(Sender: TObject; var CloseAction: TCloseAction);
  2. //begin
  3. //CloseAction:= caFree;
  4.  
  5. var
  6.   i: Integer;
  7.   C: TComponent;
  8. begin
  9.   for i := ComponentCount - 1 downto 0 do
  10.   begin
  11.     C := Components[i];
  12.     if C is TCustomForm then
  13.     begin
  14.       //writeln('Component[',i,'] is  Form: ',C.ClassName,':',C.Name);
  15.       FreeAndNil(C);
  16.     end;
  17.   end;
  18. end;
Why do you do this? This is not needed. All these controls were created with an "Owner" (the form), and the owner takes care of destroying them. Normally it works correctly, but beginning to destroy components yourself at the moment when the form is about to do the same sounds like calling for trouble. Normally, the main form normally does not need an OnClose handler at all.
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

rvk

  • Hero Member
  • *****
  • Posts: 4189
Re: Windows 10 and FormClose
« Reply #58 on: July 09, 2019, 10:02:46 pm »
Why do you do this? This is not needed. All these controls were created with an "Owner" (the form), and the owner takes care of destroying them. Normally it works correctly, but beginning to destroy components yourself at the moment when the form is about to do the same sounds like calling for trouble. Normally, the main form normally does not need an OnClose handler at all.
Yeah, that's what I also already said. And what's even more... It really doesn't do anything because none of the components which are owned, are TCustomForm. So this code really doesn't do anything. It just confused the whole issue and code.

wp

  • Hero Member
  • *****
  • Posts: 7250
Re: Windows 10 and FormClose
« Reply #59 on: July 09, 2019, 10:23:49 pm »
I now found now a way to reproduce an error ("Externeal SIGSEV") when the program closes:
- Run
- Type "1"
- Press "ENTER"
- Type "2"
- Type "+"
- Type "+"
- Close with "x" button or "F4"

Error happens only with keyboard entry, not with clicked buttons. Speed of data entry is not important.

I tested various Laz/FPC combinations on Win 10/64 bit:

- Laz trunk / fpc 3.0.4 (32 bit) --> ERROR
- Laz trunk / fpc trunk (32 bit)  ---> NO ERROR
- Laz 2.0 / fpc 3.2-beta (32 bit) --> NO ERROR
- Laz 1.8.4 / fpc 3.0.4 (32 bit) --> ERROR
- Laz 1.6.4 / fpc 2.6.4 (32 bit) --> NO ERROR
- Laz 1.8.4 / fpc 3.0.4 (64 bit) --> ERROR
- Laz 2.0.2 / fpc 3.0.4 (64 bit) --> NO ERROR
- Laz 2.0.2 / fpc 3.0.4 (32 bit) --> ERROR

It almost looks as if the 32-bit compiler of fpc 3.0.4 has an issue.

« Last Edit: July 09, 2019, 10:43:47 pm by wp »
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

 

TinyPortal © 2005-2018