I still struggle with some VO code pieces which throw warnings in XSharp:
1. What would be the correct way to test if 2 strings occupy the same space in memory other than with
IF PTR(SELF:_cValue) == PTR(cResult)
2. How passing a string value to FUNCTION OurCharUpperW (pString AS WORD PTR, dwLen AS DWORD) AS PTR PASCAL other than by
OurCharUpperW(PTR(_CAST,cResult), dwLen)
3. Does this still work in X# (and how avoiding the warning)?
function MarkAsUnicode(cString ref STRING) AS VOID PASCAL
LOCAL pHeader AS _VO_STRING_DME
LOCAL pCollInfo AS _VO_CollectInfo
LOCAL bFlag AS BYTE
pHeader := PTR(_CAST, DWORD(_CAST, PTR(_CAST,cString)) - _sizeof(_VO_DME_HEADER))
// Check to see if the UNICODE bit is set
pCollInfo := @pHeader.flh.colInf
bFlag := pCollInfo.bFlag
bFlag := _OR(bFlag, WAGNER_UNICODE)
pCollInfo.bFlag := bFlag
RETURN
(Still) confused with WORD PTR, PTR/PSZ and strings - how to avoid XS9068?
-
- Posts: 71
- Joined: Thu Jul 15, 2021 10:46 am
- Location: Germany
(Still) confused with WORD PTR, PTR/PSZ and strings - how to avoid XS9068?
Hi Stefan,
You can't do any of those things in .Net. Strings are immutable, you cannot modify directly their contents (without creating new strings) and you cannot access their memory location (at least not for any useful operation). You will need to do things in a different way, which way depends on what string manipulation you are doing in each case.
You can't do any of those things in .Net. Strings are immutable, you cannot modify directly their contents (without creating new strings) and you cannot access their memory location (at least not for any useful operation). You will need to do things in a different way, which way depends on what string manipulation you are doing in each case.
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
-
- Posts: 71
- Joined: Thu Jul 15, 2021 10:46 am
- Location: Germany
(Still) confused with WORD PTR, PTR/PSZ and strings - how to avoid XS9068?
Hi Chris,
maybe I don't need all that stuff which mostly comes from our own UnicodeString class. In X# a string is a set of Unicode chars, in VO it was Ansi (right?). So if I want i.e. to upper a Unicode string I can just call upper( cString ), right? I also suppose that all the handling passing strings from and to a dbf Field (where only Ansi is stored) happens internally, right?
Sorry, but my biggest challenge is actually to decide which of all the tricks we do (like having Unicode content of DBF fields passed from and to VO controls) can be replaced or even be dropped...
Is there a paper pointing out the whole X# string system from the point of an old developer who stuck with DBF and VO for decades?
maybe I don't need all that stuff which mostly comes from our own UnicodeString class. In X# a string is a set of Unicode chars, in VO it was Ansi (right?). So if I want i.e. to upper a Unicode string I can just call upper( cString ), right? I also suppose that all the handling passing strings from and to a dbf Field (where only Ansi is stored) happens internally, right?
Sorry, but my biggest challenge is actually to decide which of all the tricks we do (like having Unicode content of DBF fields passed from and to VO controls) can be replaced or even be dropped...
Is there a paper pointing out the whole X# string system from the point of an old developer who stuck with DBF and VO for decades?
(Still) confused with WORD PTR, PTR/PSZ and strings - how to avoid XS9068?
Hi Stefan,
It's not really the X# system, it's the .Net string system, apart from the automatic ANSI<->Unicode conversions (in dbfs, when reading/writing from text files etc), which indeed happen automatically by the X# runtime. It's actually still possible to use 8bit strings, via the PSZ type, but I wouldn't go that way, just use regular unicode strings which are the standard in .Net. And yes, of course you can just use Upper() on the unicode strings.
What information exactly are you looking for regarding strings? There's plenty info around about strings in general in .Net, and there have been also many discussions here, will have a look to find some.
It's not really the X# system, it's the .Net string system, apart from the automatic ANSI<->Unicode conversions (in dbfs, when reading/writing from text files etc), which indeed happen automatically by the X# runtime. It's actually still possible to use 8bit strings, via the PSZ type, but I wouldn't go that way, just use regular unicode strings which are the standard in .Net. And yes, of course you can just use Upper() on the unicode strings.
What information exactly are you looking for regarding strings? There's plenty info around about strings in general in .Net, and there have been also many discussions here, will have a look to find some.
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
(Still) confused with WORD PTR, PTR/PSZ and strings - how to avoid XS9068?
Hi Stefan,
if you have unicode strings in a DBF, maybe you need some dirty tricks like reading the DBF values using byte arrays and then converting it to a string. I cannot immagine another solution (I'm regularly storing compressed and/or crypted strings into DBF files, therefore I had to check that out).
Wolfgang
if you have unicode strings in a DBF, maybe you need some dirty tricks like reading the DBF values using byte arrays and then converting it to a string. I cannot immagine another solution (I'm regularly storing compressed and/or crypted strings into DBF files, therefore I had to check that out).
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
(Still) confused with WORD PTR, PTR/PSZ and strings - how to avoid XS9068?
Good point Wolfgang! Stefan, in X# we have introduced a new method in the DBServer class, FieldGetBytes(), which reads the given field into a BYTE[] array. There's also a same named function, for if you're doing procedural access to dbs.
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu