Giulio Bernardi schreef:
It didn't fix the select directory dialog in win64 though, I still get
TApplication.HandleException Privileged instruction
Stack trace:
$0000000078F2A966
Vincent
yes, that patch wasn't meant to solve SelectDirectoryDialog bug in
win64: I was fixing qt LCL
to work with 64 bit systems and I noticed the wrong size of thandles in
CommonDialogs. I sent the
patch a week ago but i got canceled from the list, so I sent it again
yesterday.
But since THandle is already a 64 bit integer in RTL (in win64) there
was no need for the LCLType
stuff. Moreover, CreateHandle of CommonDialog & friends always returns 0
on windows.
But I tried to figure out what happens in win64 with
SelectDirectoryDialog: I didn't find the
bug, but I discovered something that could help solving the bug (now I
don't have time to continue
myself, and I don't know win32 and LCL internals well).
I'm gonna write these clues here, maybe someone can find it useful.
I discovered that SelectDirectoryDialog does work if called from a
program that doesn't use
all TApplication stuff. Okay, I don't know how to explain in words, in
code this means that:
program project1;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Interfaces, // this includes the LCL widgetset
Forms,
Dialogs;
var sdtest : TSelectDirectoryDialog;
begin
sdtest:=TSelectDirectoryDialog.Create(nil);
sdtest.Execute;
sdtest.Free;
end.
Works.
I checked parameters (and their sizes) passed to SHBrowseForFolders and
to the callback functions,
in both cases (the "working one" above and the "bugged one") but it
seems to me that there it's ok.
I don't think there is a bug in SelectDirectoryDialog or in its
"neighbourhood", it looks like
it's a strange and hard to find side effect (maybe a compiler bug, maybe
something bad that is
set in startup code...)
I thought It worked because of something bad being set during
Application.Initialize, but the
following code also works:
Application.Initialize;
sdtest:=TSelectDirectoryDialog.Create(nil);
sdtest.Execute;
sdtest.Free;
Problems arise during Application.CreateForm.
I started to put some "exit" in the various methods to detect when and
what method caused the
crash.
So I ended here:
tapplication.createform
=> handleneeded (wincontrol.inc)
=> createhandle (wincontrol.inc)
=> createwnd (wincontrol.inc)
=> initializewnd (wincontrol.inc)
=> TWin32WidgetSet.ShowHide(Sender: TObject) (win32object.inc).
The odd thing is that the "bad line" seems to be
Windows.ShowWindow(Handle, Flags);
in TWin32WidgetSet.ShowHide method.
That is, if I comment that out, this code works:
Application.Initialize;
Application.CreateForm(TForm1, Form1);
sdtest:=TSelectDirectoryDialog.Create(nil);
sdtest.Execute;
sdtest.Free;
If it's enabled, I receive the EPrivileged exception when trying to
Execute the SelectDirectoryDIalog.
(Moreover, it looks like there are problems with lineinfo: stack trace
doesn't show symbol names
even if lcl is compiled with -g -gl: it only shows WSSPIN_init as first
entry, which is 99% wrong IMHO)
Now, ShowWindow will cause some callbacks to be called. Maybe they do
something wrong (they corrupt
something, they set some flag that will cause Windows to fail with
SHBrowseForFolder). Or maybe there is
a compiler bug that corrupts some data. I don't have the skills in win32
apis and in LCL
internals to analyze callbacks and windows api calls to determine what's
wrong. Maybe someone else knows
how to proceed?
Thanks for looking into it. It is good to know that the dialog can be shown in some
circumstances. That seems to rule out linking to the wrong dll.
At this moment I don't know how to proceed, but I will keep this mail, for in case I
want to take a further look at it.
What you could do, is compile with -gh to increase the chance of finding memory
corruption and compilen the LCL with -dMSG_DEBUG, so make the message handling
verbose. The application must then be compiled without -WG. Maybe this gives a bit
more of information, so that becomes clear what is wrong.
Vincent
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
