In one of my biggest FF project that was working well with FF 3.51 the application now GPF with FF3.60.
I found the exact line where the problem is:
FORMNAME_SHOW(%HWND_DESKTOP, %FALSE)
works with FF 3.51 but GPF with FF 3.60 in my project.
If I replace %HWND_DESKTOP by HWND_MAIN (the handle of the main FORM) it works in both FF 3.51 and FF 3.60.
I made a simple project to see if I was able to reproduce this issue; but I had no success; with a simple project with 2 or 3 forms it works perfectly with FF 3.51 and FF 3.60; so that should be something else ...
Any ideas ?
Thanks,
Jean-Pierre
I had the same problem and made this change:
Local hWnd as Dword
hWnd = FORMNAME_SHOW(%HWND_DESKTOP, %FALSE)
GPF's stopped occurring.
Hello Carl,
Thank you for your post.
I tried your workaround but it doesn't work for my project.
Regards,
Jean-Pierre
And why are you using %HWND_DESKTOP? Only the main form can be child of the desktop. The secondary ones must be children of the main form.
Quote from: Jose Roca on July 15, 2012, 01:19:54 PM
And why are you using %HWND_DESKTOP? Only the main form can be child of the desktop. The secondary ones must be children of the main form.
For a very simple and practical reason: to be able to switch between forms with Alt+Tab keys !
I'm still trying to track down this weird issue.
For the moment I can say that I have the same behavior (GPF) on my both PCs :
- Win XP Pro 32 bits SP3
- Win 7 Pro 64 bits SP1
Jean-Pierre
Hi Jean-Pierre, I am running some tests on this now to see if there is anything I can do.
I get random GPF's if the main form is destroyed prior to the secondary windows being closed.
Maybe the following will help:
' load the second form as non-modal as a child of the main form
Form2_Show hWndForm, %FALSE
Set the WindowStyles for the second form, WS_EX_APPWINDOW
Hi Paul,
Thank you for your help on this one.
To be more precise I got the GPF only when I try to open a form with %HWND_DESKTOP handle as the parent windows; this kind of code was working perfectly until FF 3.51.
If I replace %HWND_DESKTOP by HWND_MAIN (the handle of the main FORM in my project) it works in both FF 3.51 and FF 3.61.
But I would like to be able to use the %HWND_DESKTOP handle to be able to switch between forms with Alt+Tab keys.
PS: I made a test with an empty form (without any control) and I got the same issue.
Paul,
I added a dummy FORM (called Toto) in my project and compile it with both FF3.51 and FF3.60.
There is no control on this form. Then i compared the generated codes.
At the beginning of TOTO_FORMPROCEDURE we have now these lines of codes :
FLY_pWindow = CWindow_GetObjectFromWindowHandle(hWndForm)
If IsObject(FLY_pWindow) Then
FLY_ScaleX = FLY_pWindow.rxRatio
FLY_ScaleY = FLY_pWindow.ryRatio
Else
FLY_ScaleX = 1
FLY_ScaleY = 1
End If
I'm not able to explain but if I comment these lines of codes everything works fine with %HWND_DESKTOP as the parent handle when I open the FORM; if these lines are not commented I got a GPF.
I hope that could help.
Thanks.
Jean-Pierre
Paul,
I made more tests and I can tell you that the line that is causing the GPF is the first one :
FLY_pWindow = CWindow_GetObjectFromWindowHandle(hWndForm)
I'm happy to have been able to find the code that is causing this GPF in my project; I hope that you can understand why and that you could find a fix for that.
Thanks a lot for your support.
Jean-Pierre
It seems strange that it would be that function call that would cause a GPF. I use that code to determine the scaling. I will replace that code with the better choices of AfxScaleX and AfxScaleY.
I will post a test exe for you shortly.
Hi Jean-Pierre,
Try the attached exe to see if the GPF is gone. If not, then the problem probably exists elsewhere but was only triggered by that function call.
[attachment deleted by admin]
Hi Paul,
Thank you for the quick fix; I didn't get anymore GPF; the behavior of the application is now exactly the same as with FF3.51.
Thanks a lot
Jean-Pierre
Awesome! Very happy that it is okay now.
By using the independent functions instead of the scale methods provided by the class you're making impossible other possibilities like zooming... I will keep for myself what I think about making two (or more) forms of the same application children of the desktop.
Luckily, in this case, the only thing affected is the StatusBar if one is present on a Form. The scaling factor is needed in the WM_SIZE of the Form in order to proportionally scale the individual panels of the status bar.
The cWindow class scaling is still used in the CreateControls sub. No change there.