User Tools

Site Tools


vo_to_net:pcall

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
vo_to_net:pcall [2018/07/11 06:49] wolfgangriedmannvo_to_net:pcall [2018/07/29 05:22] (current) wolfgangriedmann
Line 3: Line 3:
 ''PCall()'' and ''PCallNative()'' are pseudo-functions or intrinsic functions - they do not need any runtime because they are replaced by the compiler. ''PCall()'' and ''PCallNative()'' are pseudo-functions or intrinsic functions - they do not need any runtime because they are replaced by the compiler.
  
-The X# compiler needs a typed function pointer for ''PCall()'' to work: +The X# compiler needs a typed function pointer for ''PCall()'' to work (and you need the compiler switch /vo6 "Resolve function pointers to PTR")
-<code>STATIC FUNCTION __GetRealOsVersion( struOS AS _winOSVERSIONINFOEX) AS DWORD PASCAL  // typed function pointer+<code visualfoxpro>STATIC FUNCTION __GetRealOsVersion( struOS AS _winOSVERSIONINFOEX) AS DWORD PASCAL  // typed function pointer
   RETURN 0   RETURN 0
 .... ....
Line 10: Line 10:
 dword( _cast , PCALL( hFunc ,@struOS) )</code> dword( _cast , PCALL( hFunc ,@struOS) )</code>
 The alternative (to not define such a function) is to use ''PCallNative()'': The alternative (to not define such a function) is to use ''PCallNative()'':
-<code>local hFunc as ptr+<code visualfoxpro>local hFunc as ptr
 PCALLNative<dword>( hFunc ,@struOS )</code> PCALLNative<dword>( hFunc ,@struOS )</code>
  
-The .NET way would be the definition of a delegate (i.e. a typed function pointer). Please see [[:delegates|Delegates]].+The .NET way would be the definition of a delegate (i.e. a typed function pointer). Please see [[:delegates|Delegates]].  
 +A sample for the delegate version is the following: 
 +<code visualfoxpro>delegate RtlGetVersionDelegate( struOS as _winOSVERSIONINFOEX) as dword 
 +local oFunc as RtlGetVersionDelegate
  
-The X# development team reccommends the use of ''PCall()'' over ''PCallNative()'' because the X# compiler will build a delegate from the typed function pointer and use it.+oFunc := ( RtlGetVersionDelegate ) Marshal.GetDelegateForFunctionPointer( hFunc, TypeOf( RtlGetVersionDelegate ) ) 
 +oFunc:Invoke( @struOS )</code> 
 + 
 +To simplify the code, a static method could help: 
 +<code visualfoxpro>static class DelegateHelper 
 + 
 +static method CreateDelegate<T>( hFunc as ptr ) as T 
 +  local oFunc as T 
 +  local oDelegate as object 
 + 
 +  oDelegate := Marshal.GetDelegateForFunctionPointer( hFunc, TypeOf( T ) ) 
 + 
 +  oFunc := ( T ) oDelegate 
 + 
 +  return oFunc 
 + 
 +end class</code> 
 +and to be used: 
 +<code visualfoxpro>oFunc := DelegateHelper.CreateDelegate<RtlGetVersionDelegate>( hFunc )</code> 
 +(Code courtesy of Chris Pyrgas) 
 + 
 +The X# development team recommends the use of ''PCall()'' over ''PCallNative()'' because the X# compiler will build a delegate from the typed function pointer and use it.
  
 The following was stated by a member of the development team: The following was stated by a member of the development team:
Line 22: Line 46:
 For this reason I would recommend using PCall because the function name used in the declaration gives you full control of the parameter types in the delegate.'' For this reason I would recommend using PCall because the function name used in the declaration gives you full control of the parameter types in the delegate.''
  
-Please see major details in the X# Forum discussion:+Please see more details in the X# Forum discussion:
 [[https://www.xsharp.info/forum/public-product/752-voxporter-icon-naming-problem#5355|www.xsharp.info/forum/public-product/752-voxporter-icon-naming-problem]] [[https://www.xsharp.info/forum/public-product/752-voxporter-icon-naming-problem#5355|www.xsharp.info/forum/public-product/752-voxporter-icon-naming-problem]]
  
Line 35: Line 59:
 In VO, dynamically loading DLLs and executing function from it was interesting to make the application loading times shorter, but in .NET thanks to its lazy loading this is not more necessary. In VO, dynamically loading DLLs and executing function from it was interesting to make the application loading times shorter, but in .NET thanks to its lazy loading this is not more necessary.
  
-Executing functions dynamically is only needed when you are not sure that the functionality is installed, or if you are using different versions dependend on some other parameters like OS version or 3rd party DLL version.+Executing functions dynamically is only needed when you are not sure that the functionality is installed, or if you are using different versions dependent on some other parameters like OS version or 3rd party DLL version.
vo_to_net/pcall.1531291747.txt.gz · Last modified: 2018/07/11 06:49 by wolfgangriedmann