VOXporter - Icon (?naming?) problem

This forum is meant for questions and discussions about the X# language and tools
Karl-Heinz
Posts: 774
Joined: Wed May 17, 2017 8:50 am

VOXporter - Icon (?naming?) problem

Post by Karl-Heinz »

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
User avatar
robert
Posts: 4225
Joined: Fri Aug 21, 2015 10:57 am
Location: Netherlands

VOXporter - Icon (?naming?) problem

Post by robert »

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
XSharp Development Team
The Netherlands
robert@xsharp.eu
User avatar
Chris
Posts: 4562
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

VOXporter - Icon (?naming?) problem

Post by Chris »

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 test
chris(at)xsharp.eu
Karl-Heinz
Posts: 774
Joined: Wed May 17, 2017 8:50 am

VOXporter - Icon (?naming?) problem

Post by Karl-Heinz »

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
Attachments
pcall.zip
(1012 Bytes) Downloaded 23 times
User avatar
Chris
Posts: 4562
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

VOXporter - Icon (?naming?) problem

Post by Chris »

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
Chris Pyrgas

XSharp Development Team test
chris(at)xsharp.eu
User avatar
robert
Posts: 4225
Joined: Fri Aug 21, 2015 10:57 am
Location: Netherlands

VOXporter - Icon (?naming?) problem

Post by robert »

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
XSharp Development Team
The Netherlands
robert@xsharp.eu
User avatar
Chris
Posts: 4562
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

VOXporter - Icon (?naming?) problem

Post by Chris »

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
Chris Pyrgas

XSharp Development Team test
chris(at)xsharp.eu
User avatar
wriedmann
Posts: 3644
Joined: Mon Nov 02, 2015 5:07 pm
Location: Italy

VOXporter - Icon (?naming?) problem

Post by wriedmann »

Hi Karl-Heinz,
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
Karl-Heinz
Posts: 774
Joined: Wed May 17, 2017 8:50 am

VOXporter - Icon (?naming?) problem

Post by Karl-Heinz »

Hi Chris and Robert

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 

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
User avatar
wriedmann
Posts: 3644
Joined: Mon Nov 02, 2015 5:07 pm
Location: Italy

VOXporter - Icon (?naming?) problem

Post by wriedmann »

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:

Code: Select all

local ptrHandle as ptr  
local ptrFunction as ptr
ptrHandle := GetModuleHandle( String2Psz( "ntdll" ) )
ptrFunction := GetProcAddress( ptrHandle, String2PSZ( "RtlGetVersion" ) )
PCall( ptrFunction, @strWinOsVersionInfo )
Only the code using PCallNative works:

Code: Select all

PCallNative<int>( ptrFunction, @strWinOsVersionInfo )
Wolfgang

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
Post Reply