I'm using the following code which extracts the rightmost directory of a path string independendly if a backslash is at the end or not works with ASCII but fails with Unicode, what's wrong?!
Procedure.s GetRightMost(s.s)
Protected n
n=Len(s)-1
If n>=0
If PeekC(@s+n<<#PB_Compiler_Unicode)='\'
s=Left(s,n)
EndIf
While n
n-1<<#PB_Compiler_Unicode
If PeekC(@s+n<<#PB_Compiler_Unicode)='\'
ProcedureReturn Mid(s,n+2)
EndIf
Wend
EndIf
ProcedureReturn s
EndProcedure
Debug GetRightMost("\abc\def\ghi\")
Debug GetRightMost("\abc\def\ghi")
Procedure.s GetRightMost(s.s)
Protected n = CountString(s, "\")
If Right(s, 1) <> "\"
n + 1
EndIf
ProcedureReturn StringField(s, n, "\")
EndProcedure
@Edit: In your procedure you are using 'n' to count both characters and bytes. This is fine in ascii (1 char = 1 byte) but not unicode (1 char = 2 bytes). This occurs in more than one place in the procedure:
Procedure.s GetRightMost(s.s)
Protected n
n=Len(s)-1 ;not correct for unicode
If n>=0
If PeekC(@s+n<<#PB_Compiler_Unicode)='\'
s=Left(s,n)
EndIf
While n
n-1<<#PB_Compiler_Unicode
If PeekC(@s+n<<#PB_Compiler_Unicode)='\'
ProcedureReturn Mid(s,n+2) ;not correct for unicode
EndIf
Wend
EndIf
ProcedureReturn s
EndProcedure
Procedure.s GetRightMost(s.s)
Protected n
n=Len(s)-1
If n>=0
If PeekC(@s+n<<#PB_Compiler_Unicode)='\'
s=Left(s,n)
EndIf
While n > 0
n-1
If PeekC(@s+n) = '\'
ProcedureReturn Mid(s, n+2)
EndIf
Wend
EndIf
ProcedureReturn s
EndProcedure
Debug GetRightMost("\abc\def\ghi\")
Debug GetRightMost("\abc\def\ghi")
Sorry by bad English.
HP Pavilion DV6-2155DX: Intel i3-330m 2.13 / 4GB DDR3 / 500GB Sata2 HD / Display 15.6" LED / Win7 Ultimate x64 / PB 4.50 x86 demo.
PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Never use a constant in an expression as you can't predict its value ! We can change it to another number without notice. Also, it can change depending of the OS
Never use a constant in an expression as you can't predict its value !
Like the constant #True could become -1 instead of 1 as well.
Should the constants always be verified at startup? such as If #True <> 1 then show a Warning, #True has changed!
- Windows 11 Home 64-bit
- PureBasic 6.10 LTS (x64)
- 64 Gb RAM
- 13th Gen Intel(R) Core(TM) i9-13900K 3.00 GHz
- 5K monitor with DPI @ 200%
Fred wrote:The whole purpose of the constant is to hide the underlying number.
That is understood, but do you have to be so good at hiding the actual Constants?
I would like to have programmatic access to the list of available constants.
Then, there are no surprises.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Fred wrote:The whole purpose of the constant is to hide the underlying number.
That is understood, but do you have to be so good at hiding the actual Constants?
I would like to have programmatic access to the list of available constants.
Then, there are no surprises.
Tools -> Structure Viewer -> Constants?
Granted, the "Structure Viewer" is misleading since you can view interfaces and constants as well. Maybe it needs a renaming.
The only excuse for my coding and especially the use of the (not so constant) constant is, that the SizeOf function may costs execution time because it will be calculated each time