Chr() vs. ChrA() and Asc() vs. AscA()

[Karl-Heinz]

i examine a Ansi2Oem() string and a "normal" string. Only if the AscA() and ChrA() funcs are used the results are equal to the VO Asc() and Chr() results. When you activate the _USE_ASC_CHR_ define you see the Asc() and Chr() differences.

I hope i didn´t overlook something, but IMO, to be compatible with VO, Chr() and Asc() should behave as ChrA() and AscA()

Code: Select all

_DLL FUNCTION MessageBox(hwnd AS intptr , lpText AS STRING, lpCaption AS STRING, uType AS DWORD);
	AS INT PASCAL:USER32.MessageBoxA ANSI

//#define _USE_ASC_CHR_ 

FUNCTION Start() AS VOID
LOCAL c, cResult AS STRING 
LOCAL i AS DWORD

  	
  c := Ansi2Oem ( "Ärger" )
  
   messagebox ( NULL , "Result: " + c + chr(13) + chr(10) +;
   					   "Should be: " + "Žrger" , "" , 0 )     // ok 

  cResult := ""
  
  FOR i := 1 TO SLen ( c   ) 
  	
  	#ifdef  _USE_ASC_CHR_
  		cResult := cResult + NTrim(Asc( SubStr (c , i , 1 ) ) ) + " "  

  	#else
  		cResult := cResult + NTrim(AscA( SubStr (c , i , 1 ) ) ) + " "
  		  
  	#endif 	
  		
 
  NEXT 	

  	#ifdef  _USE_ASC_CHR_
 
	  messagebox ( NULL , c + chr(13) + chr(10) + cResult + chr(13) + chr(10) + CHR ( 90 ) , "" , 0 ) 

	   // "Žrger"  	   
 	   // 90 114 103 101 114
 	   // "Z"  	  
	  
	#else
	
	  messagebox ( NULL , c + chr(13) + chr(10) + cResult + chr(13) + chr(10) + CHRA ( 142 ) , "" , 0 ) // 8E
 
       // VO shows the same results      "codepage 1252"  142 == "Ž"
      
   	   // "Žrger"  	   
 	   // 142 114 103 101 114
 	   // "Ž"          		
	   
	#endif 	  
  

  c :=  "Ärger" 
  cResult := "" 
  
  
  
  FOR i := 1 TO SLen ( c   )
  	
  	#ifdef  _USE_ASC_CHR_
 
  	 		cResult := cResult + NTrim(Asc ( SubStr (c , i , 1 ) ) ) + " "  
  	 		
	#else
	
  	 		cResult := cResult + NTrim(AscA ( SubStr (c , i , 1 ) ) ) + " "  
  
	 
	#endif  	 		
  		

  NEXT 
  	
 	#ifdef  _USE_ASC_CHR_
	 
 		messagebox ( NULL ,  c + chr(13) + chr(10) + cResult + chr(13)+chr(10) + CHR ( 142 ) , "" , 0 )   
 		 
	   // "Ärger" 		   
 	   // 142  114  103  101  114
	   // "?"   	 		
 		 
	#else 
 		 messagebox ( NULL ,  c + chr(13) + chr(10) + cResult + chr(13)+chr(10) + CHRA ( 196 ) , "" , 0 )  // C4

       // VO shows the same results      "codepage 1252"  196 == "Ä"

  		// "Ärger" 		   
	  	// 196  114  103  101  114
		// "Ä"   	 		
  		  	
	#endif 		 
	
	
RETURN

regards
Karl-Heinz

[robert]

Karl-Heinz

At this moment the functions Chr() and Asc() are compatible with Vulcan. I am not sure if they are compatible with VO. Will look into that asap.

Robert

[Chris]

Hi Karl-Heinz,

Just a quick note, the functions Ansi2Oem() and Oem2Ansi() do not make sense and should not be used in .Net with strings. They are meant to be used with 8 bit strings only, as they convert from one codepage to another (ansi<->oem codepage, 1252<->850 for "Western", you can get the codepages of the current system Locale with GetACP() and GetOEMCP()).

In .Net, there's no concept of a codepage inside a string, since strings are anyway unicode, so include all the characters available in all codepages. So Ansi2Oem() and Oem2Ansi() only make sense to be used with PSZs, so I think this is what we need to do, change their definition to accept a PSZ, not a STRING. Using them with strings only invalidates their contents, so that should be disallowed (error reported) in X#.

Chris

[wriedmann]

Hi Chris,

and what with our migrated VO code?

Wolfgang

[Chris]

Hi Wolfgang,

Hi Chris,
and what with our migrated VO code?

It depends. Under what circumstances are you using those functions in VO?

Chris

[wriedmann]

Hi Chris,

this is a very old story and has to do with text prints, where I'm using the MS LineDraw font (mostly for dot matrix printers as preview). I have to check if I can change that.

I have now also searched my major project, and have found that I had used these functions mostly to convert data from MS DOS applications for my Windows application.

So currently this does not seem to be any major showstopper.

Wolfgang

[Chris]

Hi Wolfgang,

Well, the fact that .Net uses unicode strings is supposed to be progress, not a showstopper of course!!! The fact we were forced to use such functions in the past was because of the limitations of the 8bit string system, we had to convert from one codepage to other etc, because there was no other way. In .Net, we simply do not need to worry about codepages at all, it's one less thing to worry about (since conversions happen automatically), not a problem.

In cases where you might indeed still need to work with codepages (for example writing to a text file that you need it to be non-unicode), the .Net classes offer a very easy way (just specify the codepage number you want to use when calling read/write methods) to do that very easily.

Chris

[wriedmann]

Hi Chris,

yes, I think that Unicode is a big step forward, but unfortunately we have a lot of very old code (some of my functions are from the Clipper times....), and when moving forward to Unicode, we need to make sure that all works.

Wolfgang

P.S. ADS is using SetAnsi() to false, so for example I'm not able to store the Euro sign in ADS datafields because it is converted fore and back

[Karl-Heinz]

Are there any news on the "Asc() vs. AscA() and Chr() vs. ChrA()" topic ?

i try to explain the problem once again ...

Code: Select all

/*
VO results:
----------

asc ( "Ä" )  ---> 196 
chr ( 196 )  ---> "Ä"
*/

// x# results
// ----------
  
? asc ( "Ä" )  //  142   
? chr ( 142 )  //  "?"


// the only way to get a VO compatible result is to
// use the  x# funcs chrA() and ascA().

?
? ascA ( "Ä" ) // 196 
? chrA ( 196 ) //  "Ä"

regards
Karl-Heinz

[wriedmann]

Hi Karl-Heinz,

I would think the development team is very busy working on the runtime and the first release of the RDDs, and maybe they have changed that already.

Since Chr() is a pseudo-function, I would make this dependent on the dialect.

Vulcan returns 196 and "Z".

Wolfgang

P.S. after having worked many hours with X# these days (I have released a service that monitors a production machine and updates the progress in the ERP database, and am working on an interface to an electronic invoice sending system) I was really surprised how long the Vulcan compile takes when compared with the X# compile