Giulio Bernardi wrote:
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.
Thanks for that.
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.
That isn't to surprising. Without the showWindow, the win32 widget is
never created. So the DirectoryDialog is still the only window in the
application. What you showed is that creating a second window breakes it.
With my debugger we found out that the EPriviliged exception is a SxS
exception. Afaik, SxS stands for Side by Side Assemblies. And there my
knowledge stops. I've no clue what that could mean.
Just thinking at some Vista thread at the forum, is it possible that we
with our manifest, load the 32 bit common controls 6.0 and not the 64 ?
We define some assemblies there (assemblyIdentity type="win32") .
(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)
How do you debug at win64 ?
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?
Maybe you can look with some resource tool (ResourceHacker) what kind of
manifest a win64 app has. Or can you try to disable the manifest we load ?
Marc
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
