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 Regards, Sven -- _______________________________________________ Lazarus mailing list [email protected] https://lists.lazarus-ide.org/listinfo/lazarus
