[Lazarus] Breaking change

[Michael Van Canneyt]

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.