Re: [fpc-pascal] importtl tool
Dňa 24.10.2016 o 13:10 José Mejuto napísal(a):
El 24/10/2016 a las 8:17, LacaK escribió:
I'm not "sure" because if the flag does not tell us nothing (no IN, no
OUT) I do not know if there is a "default behavior" except the "ByRef"
flag and both "constref" and "var" are "ByRef".
I have found:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367051(v=vs.85).aspx
"The*[in]*attribute is applied to a parameter by default when no
directional parameter attribute is specified."
Hello,
I was not aware about that "default" so, yes you are right.
Take a look in you TLB looking for a widestring that should return
information, if with this code is marked as "var" everything should be
ok, if it will be marked as "constref" something in the logic is wrong.
? I do not understand what do you mean
When I use Microsofts OLEView to look at TLB I see only:
long ScGetStringValue(long Type, BSTR* Value);
There is no attribute [in],[out],... specified
I'm quite sure that using "var" in both cases is safe in 99.9% of the
cases.
OLEView will not show you the "attributes", only in the IDL source.
According to:
https://msdn.microsoft.com/en-us/library/cc237804.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms221019(v=vs.85).aspx
*"PARAMFLAG_NONE: *The behavior of the parameter is not specified."
I guess, that my case is PARAMFLAG_NONE so patch should look like:
case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN
or PARAMFLAG_FOUT) of
PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
PARAMFLAG_FOUT:sPar:='out ';
*PARAMFLAG_NONE,*
PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
end;
I leave 'var ' for Delphi compatibility ...
Yes.
Thank you. Patch attached. I will attach it to bug report 30764, but
there is now new comment about using "constref" ... :-)
-Laco.
--- typelib.pas.ori Thu Oct 20 14:46:27 2016
+++ typelib.pas Mon Oct 24 13:15:54 2016
@@ -641,9 +641,10 @@
sPar:='';
if bParamByRef then
case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of
-PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
-PARAMFLAG_FOUT:sPar:='out ';
-PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
+ PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
+ PARAMFLAG_FOUT:sPar:='out ';
+ PARAMFLAG_NONE, // [in] is default when no
directional parameter attribute is specified
+ PARAMFLAG_FIN:sPar:='var '; // constref in safecall? TBD
end;
if not MakeValidId(GetName(k+1),sVarName) then
AddToHeader('// Warning: renamed parameter ''%s'' in %s.%s to
''%s''',[GetName(k+1),iname,sMethodName,sVarName],True);
@@ -1835,6 +1836,7 @@
end;
if (L<>' ') then
UnitSource.Add(L);
+ UnitSource.Add('');
UnitSource.addStrings(InterfaceSection);
UnitSource.addStrings(ImplementationSection);
UnitSource.Add('end.');
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 24/10/2016 a las 8:17, LacaK escribió: I'm not "sure" because if the flag does not tell us nothing (no IN, no OUT) I do not know if there is a "default behavior" except the "ByRef" flag and both "constref" and "var" are "ByRef". I have found: https://msdn.microsoft.com/en-us/library/windows/desktop/aa367051(v=vs.85).aspx "The*[in]*attribute is applied to a parameter by default when no directional parameter attribute is specified." Hello, I was not aware about that "default" so, yes you are right. Take a look in you TLB looking for a widestring that should return information, if with this code is marked as "var" everything should be ok, if it will be marked as "constref" something in the logic is wrong. ? I do not understand what do you mean When I use Microsofts OLEView to look at TLB I see only: long ScGetStringValue(long Type, BSTR* Value); There is no attribute [in],[out],... specified I'm quite sure that using "var" in both cases is safe in 99.9% of the cases. OLEView will not show you the "attributes", only in the IDL source. According to: https://msdn.microsoft.com/en-us/library/cc237804.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms221019(v=vs.85).aspx *"PARAMFLAG_NONE: *The behavior of the parameter is not specified." I guess, that my case is PARAMFLAG_NONE so patch should look like: case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN or PARAMFLAG_FOUT) of PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var '; PARAMFLAG_FOUT:sPar:='out '; *PARAMFLAG_NONE,* PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD end; I leave 'var ' for Delphi compatibility ... Yes. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
To note that both "constref" are intentional. Ok I can create patch if we (you ;-)) are sure that it is okay ? -Laco. I'm not "sure" because if the flag does not tell us nothing (no IN, no OUT) I do not know if there is a "default behavior" except the "ByRef" flag and both "constref" and "var" are "ByRef". I have found: https://msdn.microsoft.com/en-us/library/windows/desktop/aa367051(v=vs.85).aspx "The*[in]*attribute is applied to a parameter by default when no directional parameter attribute is specified." Take a look in you TLB looking for a widestring that should return information, if with this code is marked as "var" everything should be ok, if it will be marked as "constref" something in the logic is wrong. ? I do not understand what do you mean When I use Microsofts OLEView to look at TLB I see only: long ScGetStringValue(long Type, BSTR* Value); There is no attribute [in],[out],... specified According to: https://msdn.microsoft.com/en-us/library/cc237804.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms221019(v=vs.85).aspx *"PARAMFLAG_NONE: *The behavior of the parameter is not specified." I guess, that my case is PARAMFLAG_NONE so patch should look like: case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN or PARAMFLAG_FOUT) of PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var '; PARAMFLAG_FOUT:sPar:='out '; *PARAMFLAG_NONE,* PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD end; I leave 'var ' for Delphi compatibility ... -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 21/10/2016 a las 13:57, LacaK escribió: To note that both "constref" are intentional. Ok I can create patch if we (you ;-)) are sure that it is okay ? -Laco. Hello, I'm not "sure" because if the flag does not tell us nothing (no IN, no OUT) I do not know if there is a "default behavior" except the "ByRef" flag and both "constref" and "var" are "ByRef". Take a look in you TLB looking for a widestring that should return information, if with this code is marked as "var" everything should be ok, if it will be marked as "constref" something in the logic is wrong. In the other hand I do not have information about how TLBs are defined, my fixes were based in experience with some TLBs that I had and that should use, and in my case fortunately I had an equivalent C API to match against. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
Dňa 21.10.2016 o 13:42 José Mejuto napísal(a): El 21/10/2016 a las 12:32, LacaK escribió: So result should be: case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN or PARAMFLAG_FOUT) of PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var '; PARAMFLAG_FOUT:sPar:='out '; else sPar:='constref '; end; Hello, Maybe a big note should be added if it is fixed in that way. Or even better PARAMFLAG_FOUT:sPar:='out '; PARAMFLAG_FIN:sPar:='constref '; else sPar:='constref '; To note that both "constref" are intentional. Ok I can create patch if we (you ;-)) are sure that it is okay ? -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 21/10/2016 a las 12:32, LacaK escribió: So result should be: case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN or PARAMFLAG_FOUT) of PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var '; PARAMFLAG_FOUT:sPar:='out '; else sPar:='constref '; end; Hello, Maybe a big note should be added if it is fixed in that way. Or even better PARAMFLAG_FOUT:sPar:='out '; PARAMFLAG_FIN:sPar:='constref '; else sPar:='constref '; To note that both "constref" are intentional. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
Dňa 21.10.2016 o 12:10 José Mejuto napísal(a):
El 21/10/2016 a las 12:05, LacaK escribió:
- in typelib.pas is on line 631 vt=VT_PTR and sl='PWideString' ('P' is
deleted on line 635) wParamFlags=0
When I add "else" part:
case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of
PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
PARAMFLAG_FOUT:sPar:='out ';
PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
/*added*/ else sPar:='var ';
end;
it works for me.
But I have no idea if it can negative impact other cases ?
Hello,
Looking again to the code I think you are right and is the third case
"PARAMFLAG_FIN" which may be wrong, it should be "constref" (IN only).
Have you tried to use constref in the else case ?
Yes, when I use:
else sPar := 'constref ';
Then it works for me ...
So result should be:
case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of
PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
PARAMFLAG_FOUT:sPar:='out ';
else sPar:='constref ';
end;
-Laco.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 21/10/2016 a las 12:05, LacaK escribió:
- in typelib.pas is on line 631 vt=VT_PTR and sl='PWideString' ('P' is
deleted on line 635) wParamFlags=0
When I add "else" part:
case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of
PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
PARAMFLAG_FOUT:sPar:='out ';
PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
/*added*/ else sPar:='var ';
end;
it works for me.
But I have no idea if it can negative impact other cases ?
Hello,
Looking again to the code I think you are right and is the third case
"PARAMFLAG_FIN" which may be wrong, it should be "constref" (IN only).
Have you tried to use constref in the else case ?
--
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
Dňa 20.10.2016 o 17:48 José Mejuto napísal(a):
El 20/10/2016 a las 15:20, LacaK escribió:
There is:
if bParamByRef then
case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of
PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
PARAMFLAG_FOUT:sPar:='out ';
PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
end;
In my case bParamByRef = True, but wParamFlags=0 so no "var" nor "out"
is added ...
(as I do no known about type libraries I fear, that any modification
which fixes my case can cause problems in another cases)
So I have posted bug report:
http://bugs.freepascal.org/view.php?id=30764 may be somebody experienced
can fix it ...
Hello,
If wParaFlags is 0 then no "var" or "out" must be added (unless bug in
filling wParamFlags with value)
I do not know, but I know, that:
- when I import this type library in Delphi gives in this function "var"
(not only in case of WideString but also in case of integer for example)
... so I guess that there must be way how to handle it
- when I manually add in FPC "var" it works as expected (without "var"
it gives runtime error about incompatible types)
- in documentation of OCX is function parameter described as "BSTR*
Value" for "var WideString" resp. "long* Value" for "var integer"
- in typelib.pas is on line 631 vt=VT_PTR and sl='PWideString' ('P' is
deleted on line 635) wParamFlags=0
When I add "else" part:
case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of
PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
PARAMFLAG_FOUT:sPar:='out ';
PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
/*added*/ else sPar:='var ';
end;
it works for me.
But I have no idea if it can negative impact other cases ?
Thanks
-Laco.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 20/10/2016 a las 15:20, LacaK escribió: There is: if bParamByRef then case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN or PARAMFLAG_FOUT) of PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var '; PARAMFLAG_FOUT:sPar:='out '; PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD end; In my case bParamByRef = True, but wParamFlags=0 so no "var" nor "out" is added ... (as I do no known about type libraries I fear, that any modification which fixes my case can cause problems in another cases) So I have posted bug report: http://bugs.freepascal.org/view.php?id=30764 may be somebody experienced can fix it ... Hello, If wParaFlags is 0 then no "var" or "out" must be added (unless bug in filling wParamFlags with value) as it should be something like "constref" as "const" is not valid because it will try to perform a copy. Maybe "var" could be used :-? but it could be a problem if the called function changes the param expecting it to be discarded on return. For native types like int and so on a const will work, but for interfaces, widestring, ... inclusion of var can crash some functions and not adding it could crash another ones. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
Dňa 20.10.2016 o 14:05 José Mejuto napísal(a): El 20/10/2016 a las 11:09, LacaK escribió: Hi, I have noticed, that tool for importing type library into pas incorrectly imports interface methods, which should have "var" parameter. For example in my case imported: function ScGetStringValue(Type_:Integer;Value:WideString):Integer;dispid 33; but it should be: function ScGetStringValue(Type_:Integer;var Value:WideString):Integer;dispid 33; I think, that it is bug as far as delphi imports same type library with "var". Has somebody similar experience? Hello, I had fixed some of this bugs in: http://bugs.freepascal.org/view.php?id=27486 And my patch was applied with small modification (as noted by Michael Van Canneyt) and I'm not sure if this modification alters the "var" inclusion in some fields. IMO this is not my case. As I see in your patch these lines are about property setter "procedure Set_..." but I have error in "INVOKE_FUNC" branch (about line 640-650) ... There is: if bParamByRef then case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN or PARAMFLAG_FOUT) of PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var '; PARAMFLAG_FOUT:sPar:='out '; PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD end; In my case bParamByRef = True, but wParamFlags=0 so no "var" nor "out" is added ... (as I do no known about type libraries I fear, that any modification which fixes my case can cause problems in another cases) So I have posted bug report: http://bugs.freepascal.org/view.php?id=30764 may be somebody experienced can fix it ... Thanks -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 20/10/2016 a las 11:09, LacaK escribió: Hi, I have noticed, that tool for importing type library into pas incorrectly imports interface methods, which should have "var" parameter. For example in my case imported: function ScGetStringValue(Type_:Integer;Value:WideString):Integer;dispid 33; but it should be: function ScGetStringValue(Type_:Integer;var Value:WideString):Integer;dispid 33; I think, that it is bug as far as delphi imports same type library with "var". Has somebody similar experience? Hello, I had fixed some of this bugs in: http://bugs.freepascal.org/view.php?id=27486 And my patch was applied with small modification (as noted by Michael Van Canneyt) and I'm not sure if this modification alters the "var" inclusion in some fields. Unfortunatly I'm not working with the TLBs anymore so I can not perform more tests. Maybe you can try to look at my patch and replace the last lines in your typelib.pas and recompile fpc tool. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] importtl tool
Hi, I have noticed, that tool for importing type library into pas incorrectly imports interface methods, which should have "var" parameter. For example in my case imported: function ScGetStringValue(Type_:Integer;Value:WideString):Integer;dispid 33; but it should be: function ScGetStringValue(Type_:Integer;var Value:WideString):Integer;dispid 33; I think, that it is bug as far as delphi imports same type library with "var". Has somebody similar experience? -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
