FW_SetUnicode( .T. ) 2-Byte characters

[frose]

karinha,

nothing changed, the chars ÄÜÖß are misinterpreted:

[Jimmy]

hi,

as i can say you need to set Codepage for "Controls" AND for DBF

i do set in MAIN

Code: Select all | Expand

LOCAL cLangCode    := "DE"
LOCAL cCodepage    := "DEWIN"

   FW_SetUnicode( .T. )                                               // use UniCode
   hb_LangSelect( cLangCode )
   hb_CDPSELECT( cCodepage )

now when open DBF it will be default DEWIN, but when have OEM (Cl*pper) DBF i need to switch Codepage to DE850

Code: Select all | Expand

PROCEDURE DoSetNewCP( cPathcFile, cCodepage, cAlias, oBrw )
LOCAL cVia

   IF EMPTY( cAlias )
      hb_CDPSELECT( TRIM( cCodepage ) )
      oBrw:Refresh()
   ELSE
      IF SP_cInxExt() = "CDX"
         cVia := "DBFCDX"
      ELSE
         cVia := "DBFNTX"
      ENDIF
      CLOSE

      IF SP_lShared()
         USE (cPathcFile) VIA (cVia) NEW SHARED ALIAS (cAlias) CODEPAGE TRIM(cCodepage)
      ELSE
         USE (cPathcFile) VIA (cVia) NEW EXCLUSIVE ALIAS (cAlias) CODEPAGE TRIM(cCodepage)
      ENDIF
   ENDIF
RETURN

p.s. when "hardcode Umlaute" you must use a Unicode Editor like "Notepad ++"

---

wir können uns auch in Deutsch unterhalten. schreibe mir eine Email an "AUGE unterstrich OHR at WEB dot DE"

[frose]

Hello Jimmy,

thank you for the helpful information.
But in the context of this thread, the CP settings do not change the misinterpretation of these 2-byte characters.

Greetings from Ostwestfalen (Rietberg) to Hamburg

Frank

[frose]

When editing 2-Byte chars they are converted to there Unicode equivalent, NOT to UTF-8

Example - https://www.charset.org/utf-8:

Code: Select all | Expand

Dec      Hex   UTF-8 Char  Unicode description
---------------------------------------------------------------------------------------
216   U+00D8   C3 98   Ø   Latin Capital Letter O With Stroke

As you can see, xBrowse tolerates this and displays the Unicode characters correctly, which is amazing but also a bit confusing!
IMHO it would be better, to show � instead.

This happens in TGet(), TEdit and TMultiGet()!

[frose]

The following images demonstrate the change of Unicode Ä (0xC4) to UTF-8 Ä (0xC3 84) via Hex codes:

Before change, the new hex code is already in the MemoEdit:



Due to the Unicode code 0xC4 the sorting is not ok.

MsgInfo() to control what to change:



The UTF-8 Ä (0xC3 84) ist misinterpreted.

After the change:



The sorting is now correct and case insensitive thanks to the new function U82Upper()!

When opened in a dialog, the full term is displayed correctly if it contains UTF-8 codes only..

[frose]

same Prob here with unicode

I want move to Harbour from xHarbour

My getfield blocks if itype "Müller" t stops at "Mü"

U.diemer using ads Server 12.2

cannot confirm this behavior for Harbour.
Uwe, try example from this thread

Can confirm this behavior for Harbour.
When opened in a dialog, the full term is displayed correctly if it contains UTF-8 codes only.

[Jimmy]

hi,

i have use your last Sample

when start and "direct" press Check Button you are right

but try this :
after start press TAB until reach Button and press SPACE Bar
now in Msginfo() all "Umlaute" are ok

i do not know what is going on but it "seems" GET must have Focus

[frose]

yes, this issue (bug) is very confusing. To better understand what is happening, I have adjusted the sample again:

Code: Select all | Expand

function Main()

   local oDlg
   local oGet
   local oEdit
   local oMulti
   local oMemo
   local cVar1 := "üäö"
   local cVar2 := "üäö"
   local cVar3 := "üäö"
   local cVar4 := "üäö"

   REQUEST HB_CODEPAGE_UTF8
   HB_CDPSELECT( "UTF8" )
   FW_SetUnicode( .T. )
   
   DEFINE DIALOG oDlg SIZE 600, 600 PIXEL TRUEPIXEL
   
   @  20, 20 GET oGet VAR cVar1 SIZE 200,20 PIXEL OF oDlg VARCHAR 20
   
   @  40,20 EDIT oEdit VAR cVar2 SIZE 200,20 PIXEL OF oDlg
   
   @  60, 20 GET oMulti VAR cVar3 MULTILINE SIZE 200, 50 PIXEL OF oDlg

   @ 120, 20 GET oMemo VAR cVar4 MEMO OF oDlg PIXEL SIZE 400, 100
  
   @ 240, 20 BUTTON "CHECK" SIZE 100,40 PIXEL OF oDlg ;
      ACTION MsgInfo( ;
         "oGet/TGet():        " + cVar1 + " - " + StrToHex( cVar1, " " ) + CRLF + CRLF + ;
         "oEdit/TEdit():      " + cVar2 + " - " + StrToHex( cVar2, " " ) + CRLF + CRLF + ;
         "oMulti/TMultiGet(): " + cVar3 + " - " + StrToHex( cVar3, " " ) + CRLF + CRLF + ;
         "oMemo/TMultiGet():  " + cVar4 + " - " + StrToHex( cVar4, " " ) ;
         )
 
   ACTIVATE DIALOG oDlg CENTERED
 RETURN NIL
 

Screenshot before editing:

Screenshot after editing:


I marked the results I think are correct in green, the wrong ones in red.

As already mentioned above, the UTF-8 codes in MsgInfo() are also misinterpreted.

The hex codes marked in red are the Unicode equivalents to the corresponding characters. It can be assumed that the characters are incorrectly converted (not to UTF-8) by FWH in several places in the source.

[nageswaragunupudi]

These issues with Umlauts is fixed in FWH2307 soon to be released.

[frose]

[frose]

tested with:

Code: Select all | Expand

#include "fivewin.ch"

function Main()

   local oDlg
   local oGet
   local oEdit
   local oMulti
   local oMemo
   local cVar1 := "üäö" + Replicate( " ", 25 )
   local cVar2 := "üäö"
   local cVar3 := "üäö"
   local cVar4 := "üäö"

   REQUEST HB_CODEPAGE_UTF8
   HB_CDPSELECT( "UTF8" )
   FW_SetUnicode( .T. )

   DEFINE DIALOG oDlg SIZE 600, 600 PIXEL TRUEPIXEL
   @  20, 20 GET oGet VAR cVar1 SIZE 200,20 PIXEL OF oDlg

   @  40, 20 EDIT oEdit VAR cVar2 SIZE 200,20 PIXEL OF oDlg

   @  60, 20 GET oMulti VAR cVar3 MULTILINE SIZE 200, 50 PIXEL OF oDlg

   @ 120, 20 GET oMemo VAR cVar4 MEMO OF oDlg PIXEL SIZE 400, 100

   @ 240, 20 BUTTON "CHECK" SIZE 100,40 PIXEL OF oDlg ;
      ACTION MsgInfo( ;
         "oGet/TGet():        " + cVar1 + " - " + StrToHex( cVar1, " " ) + CRLF + CRLF + ;
         "oEdit/TEdit():      " + cVar2 + " - " + StrToHex( cVar2, " " ) + CRLF + CRLF + ;
         "oMulti/TMultiGet(): " + cVar3 + " - " + StrToHex( cVar3, " " ) + CRLF + CRLF + ;
         "oMemo/TMultiGet():  " + cVar4 + " - " + StrToHex( cVar4, " " ) ;
         )

   ACTIVATE DIALOG oDlg CENTERED

RETURN NIL

SOLVED, thanks to Rao