FiveTech Software tech support forums

... 20 GET oGet VAR cVar1 PICTUE "@!" SIZE 200,20 PIXEL OF oDlg VARCHAR 70 ON CHANGE { || oDlg:Update() }  In Unicode Gets picture clause "@!" works. Please do not use any other picture clauses. We can also use the clauses CASE "UPPER"CASE ...

... SetStyle( nStyle ) Refer prg source for the list of styles. * ListView: Samples: (1) revised litvie1.prg amd new sample (2) listvie2.prg for Unicode implementation * Unicode implementation for ToolBars and Rebars revised sample: samples\toolbar1.prg * Enhanced: function FW_SayTextHilite(). ...

...     ::nStartReplace := nPosi   ELSE      msginfo( "no more found" )      lRet := .F.   ENDIFRETURN lRet but i have Problem with UNICODE in HB_FUNC() ( ANSI Version work ) static TCHAR       cFindWhat[ 1024 ];static TCHAR       cReplaceWith[ 1024 ];static FINDREPLACE ...

... work with UTF8 encoded Umlauts. Even with Ansi encoded umlauts, Harbour Upper/Lower functions work only if the codepage is set to German. But a Unicode Get control does not have to depend on Harbour's Upper() function for converting to Upper case when picture clause "@!" is used. Windows ...

UTF-8 to Unicode

Utf-8 is Unicode
Probably you mean ANSI to UTF8.

...  local oDlg   local oGet   local cVar1 := "üäö"   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 70 PICTURE ...

... Languages are not the biggest Problem for Fivewin my TGrid() ANSI Version work so far but when enable LVS_OWNERDATA it does not work with FW_SetUnicode( .T. ) :(      ::nStyle := nOR( ::nStyle, LVS_OWNERDATA )      ::bDisplay := { | nPtrNMHDR | ::OnDISPINFO( nPtrNMHDR ) ...

... I will stand corrected if I am wrong. I think if the application is not at all meant for East Asian Languages which are totally dependent on Unicode, better we stick to ANSI mode only ( I mean for applications meant for West European Languages only. Only requirement for UTF8 is when writing ...

This is happening because our metafile functions like create, open, etc are not supporting Unicode file path names. These functions are now made Unicode compatible. With this you will not face this problem from the next version of FWH2208 to be released. For the present ...

... "C" but for these "Problem" my "C" Knowledge is to small my ANSI Version , using TCHAR / LPSTR , work but how with Unicode :?: need some help please

how to use this with Unicode
Code:
lvi.pszText = (TCHAR*) hb_parvc (2, 1);

can I see the full HB_FUNC?
Or you can send to me.

i guess it is while i have not use fw_parWide() / LPWSTR but LPTSTR

Yes.
If you like we can make the modifications.

#define UNICODE    // Made Unicode compatible 2023-07-07#include <CommCtrl.h>#undef UNICODE#include "fwh.h"  Sole purpose of this def and undef is to get the our program defines to work with Wide ...

... It is safer to use FWH built-in functions to make properly working Unicode library.

hi, i have found in c:\fwh\source\winapi\listview.c what was change for Unicode   LPWSTR pWide = fw_parWide( 3 );//   lvi.pszText  = ( LPTSTR ) hb_parc( 3 );   lvi.pszText  = pWide; Question : is fw_parWide() the same as AnsiToWide() :?: --- i have now ...