DF20 bug with strings

[wila]

Sorry for posting here... but as it is a specific DF20 bug I figured to create a new topic here.
Move it if you like.

I am playing a bit with WebQuery from Mike and noticed something weird.
In the field list the "Id" column ended up as "I".. so I tracked it down to a difference of behavior in DF20

Here's the code:


Use Windows.pkg

Function UpperChar String sData Integer iChar Returns String
Function_Return (Overstrike(Uppercase(Mid(sData, 1, iChar)), sData, iChar))
End_Function


Procedure Test
String sUpper
Get UpperChar "id" 1 to sUpper
Showln sUpper
End_Procedure

Send Test
Inkey windowindex


On DF20 this produces "I" on DF19.1 the result is "Id".

As it turns out, this is overstrike misbehaving.
On DF20 the output of the following is:


Use Windows.pkg

Procedure Test
Showln (Overstrike("X","xy",1))
Showln (Overstrike("X","xyz",1))
End_Procedure

Send Test
Inkey windowindex




X
Xyz


Of course that should have been:



Xy
Xyz



--
Wil

[wila]

Title should have been "bug with overstrike"..

You might wonder, but who uses THAT?

Well.. dll.pkg and datadict.pkg are depending on this to work correctly.
So.. you do.

Yes, maybe only an issue with 2 characters, so hopefully the "blast range" is not that big.
I'll leave it to DAW to investigate.
--
Wil

[Samuel Pizarro]

I have used overstrike several times in the past. :-(

and I am sure to have a few global functions using it ..

thks for pointing it out.. need to revisit this

[Dennis Piccioni]

Hi Wil,

thanks for the report. I've reproduced it and will log a bug report.

[wila]

Thanks Dennis.

Superrrr fast ack.
--
Wil

[wila]

Hi Wil,

thanks for the report. I've reproduced it and will log a bug report.

FWIW, it's not just 2 char strings.. this is also an issue:



Showln (Overstrike("Y","xyz",2))




xY


--
Wil

[wila]

Temporary workaround.
Not really unicode safe, or very performant, but at least it works with normal strings and will do until DAW has a fix.



Function tempOverstrike Global String sSource String sDestination Integer iPos Returns String
Integer iChar iLen j
UChar[] Destination
String sResult
Move 0 to j
Move (StringToUCharArray(sDestination)) to Destination
Move (Length(sSource)) to iLen
For iChar from 1 to (Length(sDestination))
If (iChar=(iPos+j)) Begin
Move (Ascii(Mid(sSource,1,j+1))) to Destination[iChar-1]
If (j<(iLen-1)) Begin
Increment j
End
End
Loop
Move (UCharArrayToString(Destination)) to sResult
Function_Return sResult
End_Function


It passed my preliminary quick testing (whatever that means)

--
Wil

[Dennis Piccioni]

Thanks, I'll update the bug report.

[Stephen W. Meeley]

Wil,

I moved this here because it's likely a Unicode-related issue.

[wila]

Yes, most likely that is why this happens.

No problem on the move. I was fine with it staying at the old spot and ending up getting locked too.
The bugs have been confirmed & logged, which was my main aim, well OK.. I prefer "fixed" over logged. ;)

Down here it stays open for discussion which I guess makes sense too.
--
Wil

[Marcia Booth]

Hello! We have released an updated build of DataFlex 2021 (20.0.7.152) that addresses various issues reported after the release of DataFlex 2021. The post on this release (https://support.dataaccess.com/Forums/showthread.php?67724-DataFlex-2021-Updated-Release-(20-0-7-152)-Published-Update-Now!) includes links to the full release notes as well as to downloading the new installation programs.


The issue you reported here has been addressed in this new build. Thank you for helping us make DataFlex a better product for the whole community!

[wila]

Tested again and can confirm it is fixed.
--
Wil