On Sun, 23 Jul 2017, Sven Barth via Lazarus wrote:
On 23.07.2017 12:50, Michael Van Canneyt via Lazarus wrote:
Hello,
I have fixed bug 28760:
https://bugs.freepascal.org/view.php?id=28760
This will cause compilation of win32wsdialogs.pp to fail, in particular in
class procedure TWin32WSOpenDialog.SetupVistaFileDialog(ADialog:
IFileDialog; const AOpenDialog: TOpenDialog);
search for:
if InitialDir <> '' then
begin
if
Succeeded(SHCreateItemFromParsingName(PWideChar(UTF8ToUTF16(InitialDir)), nil,
IShellItem, DefaultFolderItem)) then
ADialog.SetFolder(DefaultFolderItem);
end;
Directly passing an interface where (T)REFIID is expected, will no
longer be possible.
I don't think that it was necessary to change (T)REFIID to be a pointer
and thus making COM interface usage unnecessarily more complicated in
Object Pascal:
- Microsoft implicitely defines a REFIID in guiddef.h to always be an
"IN" parameter, by defining it as "const IID &" for C++ code, so it can
never be written to anyway, thus a "constref" would have sufficed (a
"const IID &" in C++ behaves the same as a "IID *" in C or a "constref
x: IID" in FPC)
- aggregates (which is what a TGUID is) are always passed as pointers
for stdcall functions (basically all functions that are related to COM
and thus to REFIID) and also the Win64 ABI anyway, so a mere "TIID"
already behaved correctly for the Windows targets
Being old school, I really don't like all this magic.
But if you feel it necessary, you are of course free to change it back.
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
https://lists.lazarus-ide.org/listinfo/lazarus
