i have a number of icons, but only a icon named "Delete.ico" causes a problem.
the VO code:
CLASS IconDeLete INHERIT Icon
RESOURCE IconDeLete Icon D:VOImagesDelete.ico
METHOD Init(kLoadoption, iWidth, iHeight) CLASS IconDeLete
SUPER:Init(ResourceID{"IconDeLete", _GetInst()},kLoadoption, iWidth, iHeight)
RETURN SELF
is translated to:
CLASS IconDeLete INHERIT Icon
CONSTRUCTOR(kLoadoption, iWidth, iHeight)
SUPER(ResourceID{"IconDeLete", _GetInst()},kLoadoption, iWidth, iHeight)
RETURN SELF
END CLASS
but the created entry in the rc file is:
IconDeLete Icon D:VOImages65536.ico
of course, when i manually change 65536.ico to delete.ico it compiles.
regards
Karl-Heinz
VOXporter - Icon (?naming?) problem
-
- Posts: 774
- Joined: Wed May 17, 2017 8:50 am
- Location: Germany
VOXporter - Icon (?naming?) problem
Karl Heinz,
This probably happens because there is a define DELETE in VO with the value 0x00010000L
The Transporter finds this define and replaced the name in the resource with the value of the define.
We will have a look at this and will try to fix this for the next build.
Robert
This probably happens because there is a define DELETE in VO with the value 0x00010000L
The Transporter finds this define and replaced the name in the resource with the value of the define.
We will have a look at this and will try to fix this for the next build.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
VOXporter - Icon (?naming?) problem
Yes, this is fixed now. Karl Heinz, if you need a quickfix for this please let me know, it's easy to send it.
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
-
- Posts: 774
- Joined: Wed May 17, 2017 8:50 am
- Location: Germany
VOXporter - Icon (?naming?) problem
Hi Chris,
no hurry, i can wait - currently i´m playing with the hardcore stuff - Pcall , extension methods, delegates . My first goal is to change only things that are absolutly neccessary. i´ve tried Pcall and PCallNative and both work. Maybe Wolfgang can update his Pcall articel ?
https://docs.xsharp.it/doku.php?id=vo_to_net:pcall
The attached zip contains two files ( start.prg and funcs.prg ) that use Pcall and PcallNative to call RtlGetVersion() .The only change that needs to be made in existing code is to type the Pcall function ptr. But such things are already used in the vo sdk sources ( std_dlg.prg ) and if the VO compiler would have forced us in the past to use a typed ptr only, it would already be there
BTW. what´s the difference between PCall and PCAllNative ? It´s clear that PCall wants a typed pointer, while PCallNative doesn´t ? Which one is recommended to use ?
regards
Karl-Heinz
no hurry, i can wait - currently i´m playing with the hardcore stuff - Pcall , extension methods, delegates . My first goal is to change only things that are absolutly neccessary. i´ve tried Pcall and PCallNative and both work. Maybe Wolfgang can update his Pcall articel ?
https://docs.xsharp.it/doku.php?id=vo_to_net:pcall
The attached zip contains two files ( start.prg and funcs.prg ) that use Pcall and PcallNative to call RtlGetVersion() .The only change that needs to be made in existing code is to type the Pcall function ptr. But such things are already used in the vo sdk sources ( std_dlg.prg ) and if the VO compiler would have forced us in the past to use a typed ptr only, it would already be there
BTW. what´s the difference between PCall and PCAllNative ? It´s clear that PCall wants a typed pointer, while PCallNative doesn´t ? Which one is recommended to use ?
regards
Karl-Heinz
- Attachments
-
- pcall.zip
- (1012 Bytes) Downloaded 84 times
VOXporter - Icon (?naming?) problem
Hi Karl-Heinz,
PCallnative() was introduced in vulcan as a replacement to PALL() and I'm pretty sure PCALL() was originally not meant to be supported at all, all PCALL() calls were supposed to be converted to PCAllNative(). But what I think happened, is that Don Caton (who originally wrote the biggest part of vulcan) realized down the way that PCALL() is used extremely often, especially in the VOSDK code and he did not want to make so many dozens of changes, so he eventually added support to the compiler for PCALL() as well
We added support for PCALL() in X# as well, and the way it works is that it derives the return type of the function from the code. So in the case of your sample, the compiles sees you have
LOCAL hFunc AS __GetRealOsVersion PTR
so it goes to the definition of this function:
STATIC FUNCTION __GetRealOsVersion( struOS AS _winOSVERSIONINFOEX) AS DWORD PASCAL
and it sees that the return type is DWORD, so it does not require you to explicitly provide it, with PCallNative().
Other than that, the function type in the LOCAL declaration is ignored, the local is actually emitted in the binary as
LOCAL hFunc AS PTR
So, in general, I'd say it's probably better to use PCallNative(), as this is cleaner I think, but then again, if you have lots and lots of PCALL()s, I don't think it's really important to go through changing all of them...
Chris
PCallnative() was introduced in vulcan as a replacement to PALL() and I'm pretty sure PCALL() was originally not meant to be supported at all, all PCALL() calls were supposed to be converted to PCAllNative(). But what I think happened, is that Don Caton (who originally wrote the biggest part of vulcan) realized down the way that PCALL() is used extremely often, especially in the VOSDK code and he did not want to make so many dozens of changes, so he eventually added support to the compiler for PCALL() as well
We added support for PCALL() in X# as well, and the way it works is that it derives the return type of the function from the code. So in the case of your sample, the compiles sees you have
LOCAL hFunc AS __GetRealOsVersion PTR
so it goes to the definition of this function:
STATIC FUNCTION __GetRealOsVersion( struOS AS _winOSVERSIONINFOEX) AS DWORD PASCAL
and it sees that the return type is DWORD, so it does not require you to explicitly provide it, with PCallNative().
Other than that, the function type in the LOCAL declaration is ignored, the local is actually emitted in the binary as
LOCAL hFunc AS PTR
So, in general, I'd say it's probably better to use PCallNative(), as this is cleaner I think, but then again, if you have lots and lots of PCALL()s, I don't think it's really important to go through changing all of them...
Chris
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
VOXporter - Icon (?naming?) problem
Chris,
Sorry to interrupt, but it actually works differently. A delegate is created by the compiler and the parameters for the delegate have to be determined by the compiler . In the case of PCallNative it looks at the actual arguments to "guess" the types. The return type is then the type as specified in the code. In the case of PCall it copies both the parameter types and return value of the function in the declaration to the delegate. The compiler then emits the code to use the native function pointer and call this with the managed 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.
Vulcan works differently. I uses an IL instruction that is not available in /supported by Roslyn.
Robert
Sorry to interrupt, but it actually works differently. A delegate is created by the compiler and the parameters for the delegate have to be determined by the compiler . In the case of PCallNative it looks at the actual arguments to "guess" the types. The return type is then the type as specified in the code. In the case of PCall it copies both the parameter types and return value of the function in the declaration to the delegate. The compiler then emits the code to use the native function pointer and call this with the managed 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.
Vulcan works differently. I uses an IL instruction that is not available in /supported by Roslyn.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
VOXporter - Icon (?naming?) problem
Robert,
Ah right, vulcan used calli, had forgotten about that, thanks. Yeah about the X# implementation I just didn't go into the implementation details of creating a delegate etc.
Chris
Ah right, vulcan used calli, had forgotten about that, thanks. Yeah about the X# implementation I just didn't go into the implementation details of creating a delegate etc.
Chris
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
VOXporter - Icon (?naming?) problem
Hi Karl-Heinz,
I will update the documentation later today.
Wolfgang
I will update the documentation later today.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
-
- Posts: 774
- Joined: Wed May 17, 2017 8:50 am
- Location: Germany
VOXporter - Icon (?naming?) problem
Hi Chris and Robert
thanks for your valueable inside views !
I think i´ll do it that way:
So there´s no need to declare any additional functions. The only change would be to add a #ifdef directive
BTW. Ok, this is nonsense, but it works
IF ! PCALLnative <LOGIC> ( hFunc , @struOS )
:woohoo:
ENDIF
regards
Karl-Heinz
thanks for your valueable inside views !
I think i´ll do it that way:
Code: Select all
FUNCTION GetRealOsVersion( dwMajor REF DWORD , dwMinor REF DWORD , dwBuild REF DWORD ) AS LOGIC PASCAL
LOCAL struOS IS _winOSVERSIONINFOEX
LOCAL hFunc AS PTR // <----- no typed ptr required. Works on both sides ( VO and X# )
LOCAL lOk AS LOGIC
IF ( hFunc := GetProcAddress( GetModuleHandle( String2Psz ("Ntdll") ) , String2Psz ( "RtlGetVersion" ))) != NULL_PTR
struOS.dwOSVersionInfoSize:= _SIZEOF ( _WINOSVERSIONINFOEX )
#IFDEF __XSHARP__
IF PCALLnative <DWORD> ( hFunc , @struOS ) == 0
#ELSE
IF DWORD ( _CAST , PCALL ( hFunc , @struOS) ) == 0
#ENDIF
dwMajor := struOS.dwMajorVersion
dwMinor := struOS.dwMinorVersion
dwBuild := struOS.dwBuildNumber
lOk := TRUE
ENDIF
ENDIF
RETURN lOk
BTW. Ok, this is nonsense, but it works
IF ! PCALLnative <LOGIC> ( hFunc , @struOS )
:woohoo:
ENDIF
regards
Karl-Heinz
VOXporter - Icon (?naming?) problem
Hi all,
I have now changed the page in the docs project:
https://docs.xsharp.it/doku.php?id=vo_to_net:pcall
but I don't think it is correct because I'm not able to compile this code using the Vulcan runtime:
Only the code using PCallNative works:
Wolfgang
P.S. I cannot use the X# runtime in this project yet as I would need the VO compatible class libraries
I have now changed the page in the docs project:
https://docs.xsharp.it/doku.php?id=vo_to_net:pcall
but I don't think it is correct because I'm not able to compile this code using the Vulcan runtime:
Code: Select all
local ptrHandle as ptr
local ptrFunction as ptr
ptrHandle := GetModuleHandle( String2Psz( "ntdll" ) )
ptrFunction := GetProcAddress( ptrHandle, String2PSZ( "RtlGetVersion" ) )
PCall( ptrFunction, @strWinOsVersionInfo )
Code: Select all
PCallNative<int>( ptrFunction, @strWinOsVersionInfo )
P.S. I cannot use the X# runtime in this project yet as I would need the VO compatible class libraries
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it