I Love BCX !

[Robert]

The attached HIGHLY EXPERIMENTAL code, I_Love_BCX, contains embedded .rc and manifest in the .bas code file and uses BCX_RESOURCE to load it into the .exe.

The program demonstrates that Unicode characters that are beyond the base level of 0x0000 to 0xFFFF, or 0-65535  can be displayed using Win32 coding on Windows.

The build file is for Visual Studio 2022 code installed in the default location. I have been unable to compile with any other compiler. Perhaps  someone else can do it. Adjust the Build.bat paths for your system. The zip does not contain an .exe.

Happy Valentine's Day

[MrBcx]

Robert,

I successfully compiled with Lcc-Win32, Pelles, and Mingw.

The wrinkle common to all is the resource file.  (UTF-x23__.rc)

Pelles resource compiler (PORC) , Lcc-Win32's (LRC), and MINGW's (Windres) are all unable to compile the .rc to .res

I successfully compiled utf-x23__.rc using the 1998 Microsoft Resource Compiler that should be in every BCX user's /bin/ folder.



I was then able to pass the .res to my Lcc-Win32 and Pelles batch files to compile.

To get the .res into Mingw, one must use CVTRES to convert the res to an .obj file. 
CVTRES should be in every BCX users BCX\Bin folder

I was able to pass that obj file to my MINGW batch file and it too compiled.

I needed to increase the HEIGHT of the BCX_FORM by 30 units to get it to look like your included exe.

Your executable and the three that I generated looked and operated close enough to call it good.

[Robert]

Robert,

I successfully compiled with Lcc-Win32, Pelles, and Mingw.

The wrinkle common to all is the resource file.  (UTF-x23__.rc)

Pelles resource compiler (PORC) , Lcc-Win32's (LRC), and MINGW's Windres are all unable to compile the .rc to .res

I successfully compiled utf-x23__.rc using the 1998 Microsoft Resource Compiler that should be in every BCX user's /bin/ folder.



I was then able to pass the .res to my Lcc-Win32 and Pelles batch files to compile.

To get the .res into Mingw, one must use CVTRES to convert the res to an .obj file. 
CVTRES should be in every BCX users BCX\Bin folder

I was able to pass that obj file to my MINGW batch file and it too compiled.

I needed to increase the HEIGHT of the BCX_FORM by 30 units to get it to look like your included exe.

Your executable and the three that I generated looked and operated close enough to call it good.

Fantastic! I shall get those pieces together and carry on. Thank you, MrBCX.

Yes, regarding the sizing, I had decided, that moving forward, to use the mod's to BCX_FORM that use AdjustWindowRectEx and work from the client area outward. I have made the mods to my Use_Form along with Jose Roca's snippets to deal with scroll bars.

Working from the client area is as a painter works with a canvas from the edges of the canvas not the edges of the frame. I am commited to this and will adjust older work as needed to this new schema. I have inlined a min function because Embarcadero does not have min/max. I switched to fmin for a bit but found that some other compiler doesn't have fmin. The min comparison isn't needed except for corner cases where GetSystemMetrics may return a value less than 0. Any way, thanks again and here's my Use_Form.

Code: [Select]


  IF Use_Form THEN
    IF Use_Library THEN FPRINT FP_WRITE, "// BCXRTLIB: BCX_Form"
    FPRINT FP_WRITE, "HWND BCX_Form(char *Caption,int X,int Y,int W,int H,int Style,int Exstyle)"
    FPRINT FP_WRITE, "{"
    FPRINT FP_WRITE, "  if(Style==-1)"
    FPRINT FP_WRITE, "    {"
    FPRINT FP_WRITE, "       Style= WS_MINIMIZEBOX | WS_SIZEBOX | WS_CAPTION |"
    FPRINT FP_WRITE, "              WS_MAXIMIZEBOX | WS_POPUP   | WS_SYSMENU;"
    FPRINT FP_WRITE, "    }"
    FPRINT FP_WRITE, "  RECT lpr = { 0 };"
    FPRINT FP_WRITE, "  SetRect(&lpr, 0, 0, W, H);"
    FPRINT FP_WRITE, "  AdjustWindowRectEx(&lpr, Style, FALSE, Exstyle);"
    FPRINT FP_WRITE, "  if((Style&WS_HSCROLL)==WS_HSCROLL)"
    FPRINT FP_WRITE, "    {"
    FPRINT FP_WRITE, "      lpr.bottom = lpr.bottom + GetSystemMetrics(SM_CYHSCROLL);"
    FPRINT FP_WRITE, "    }"
    FPRINT FP_WRITE, "  if((Style&WS_VSCROLL)==WS_VSCROLL)"
    FPRINT FP_WRITE, "    {"
    FPRINT FP_WRITE, "      lpr.right = lpr.right + GetSystemMetrics(SM_CXVSCROLL);"
    FPRINT FP_WRITE, "    }"
    FPRINT FP_WRITE, "  long w = lpr.right - lpr.left;"
    FPRINT FP_WRITE, "  long h = lpr.bottom - lpr.top;"
    FPRINT FP_WRITE, "  long x = (GetSystemMetrics(SM_CXSCREEN) - w) / 2;"
    FPRINT FP_WRITE, "  if(x<0 )"
    FPRINT FP_WRITE, "    {"
    FPRINT FP_WRITE, "     x=0;"
    FPRINT FP_WRITE, "    }"
    FPRINT FP_WRITE, "  long y = (GetSystemMetrics(SM_CYSCREEN) - h) / 2;"
    FPRINT FP_WRITE, "  if(y<0 )"
    FPRINT FP_WRITE, "    {"
    FPRINT FP_WRITE, "     y=0;"
    FPRINT FP_WRITE, "    }"
    FPRINT FP_WRITE, "  HWND A = CreateWindowEx(Exstyle, BCX_ClassName, Caption, Style,"
    FPRINT FP_WRITE, "                          x*BCX_ScaleX,y*BCX_ScaleY,w*BCX_ScaleX,h*BCX_ScaleY,"
    FPRINT FP_WRITE, "                          NULL,(HMENU)NULL,BCX_hInstance,NULL);"
    FPRINT FP_WRITE, "  SendMessage(A,(UINT)WM_SETFONT,(WPARAM)((BcxFont==0)?GetStockObject(DEFAULT_GUI_FONT):BcxFont),(LPARAM)MAKELPARAM(FALSE,0));"
    FPRINT FP_WRITE, "  return A;"
    FPRINT FP_WRITE, sENDBCXRTLIB$
  END IF


 

[Robert]

MrBCX

I just noticed that your images of the running .exe are very different from the one I posted and from what I get on my machine. What DPI are you using? My DPI is 100% on a 3840 x 2160 monitor (a TCL T.V. really excellent).

[Robert]

MrBCX

I just noticed that your images of the running .exe are very different from the one I posted and from what I get on my machine. What DPI are you using? My DPI is 100% on a 3840 x 2160 monitor (a TCL T.V. really excellent).

Yeah, it's the DPI. Looks like you are running at 125%.

Gotta fix that DPI thing. Complex though.

[MrBcx]

Correctomundo ... 125%

[Robert]

Also, could not get BCX_GET_TEXT$ to pull the text from the BCX_INPUT  and had to cobble together this stuff


GLOBAL Txt AS LPSTR

      Txt = GetText$(UniHexEdit)
      int1% = strtol(Txt, NULL, 16)

FUNCTION GetText$ (hDlg AS HWND)
  Local T
  Local Boffer$
  T = GetWindowTextLength(hDlg)
  GetWindowText (hDlg,Boffer$,T+1)
  FUNCTION = Boffer$
END FUNCTION

I also fiddled with trying to use BCX_EDIT instead of BCX_INPUT but no luck.

[Robert]

The attached HIGHLY EXPERIMENTAL code, UTF-X23, contains embedded .rc and manifest in the .bas code file and uses BCX_RESOURCE to load it into the .exe.

The program demonstrates that Unicode characters that are beyond the base level of 0x0000 to 0xFFFF, or 0-65535  can be displayed using Win32 coding on Windows.

The build file is for Visual Studio 2019 code installed in the default location. I have been unable to compile with any other compiler. Perhaps  someone else can do it.

Happy Valentine's Day

I modified the code and re-uploaded the UTF-X23.zip. Download from the original post.

To get rid of the shifting of the character at different DPI settings, the Use_Form section, in the BCX 7.4.4 translator, was reverted from my bespoke Use_Form code back to stock. The GUI setting was set as DPI (don't forget the comma, I did, three hours wasted) and consequently all the numbers for sizing the FORM and controls had to be altered.

The app is now much more stable at different DPI settings and the shifting of the character has been eliminated.

I found that the custom Use_Form that I was using did not scale the framing borders properly at different DPI settings so I am back to stock BCX. Don't mess with perfection!

[MrBcx]

Looks good Robert.

Being a lifelong Ascii/Ansi sort of fellow, I've never been compelled to investigate
multibyte character sets.  Your little experiment has piqued my curiosity. 

Pelles C pointed out a couple of unused variable - fyi.


utf-x23.c(241): warning #2135: Static 'utf8' is not referenced.
utf-x23.c(237): warning #2135: Static 'RetVal' is not referenced.

[Robert]

Thank you, MrBCX.

There's something amiss with my Pelle's C operation because recently it stopped doing that unused variable warning.

I probably messed up one of my batch files.

I used Pelle's specifically to check for unused variables (even though I couldn't compile I Love BCX with it it) because the the guts of the I Love BCX program were ripped out of a huge Asian code page translator, Chinese, Taiwanese, Japanese, Korean, UTF-8, Unicode, that I wrote years ago and I wanted to be sure that there was no extraneous junk left in the code.

More of "Yeah, gotta fix that."

The printing of extended Unicode characters, that is those above 65535, has been a problem in Windows because the 16 bit UTF-16 little-endian is the encoding standard at Microsoft (and in the Windows operating system)  so printing emojis or anything beyond 65535 must use surrogate pairs to get the char displayed. Linux is 32 bit and does not have this problem. It sort of reminds me of the old myth of Bill Gates saying "640K ought to be enough for anyone." Similarly, "65535 characters ought to be enough for all the glyphs on Earth" No, not even nearly enough !

[Jeff]

Here's a DPI aware (PerMonitor V2) version of Robert's updated submission. 

You can use DIFF to see what I changed, but generally speaking...

Added includes: dpi_dynamic.inc and dpi_helpers.inc
Modified RESOURCE section to support PerMonitorV2
Added SUB CompleteDpiSetup
Added SUB HandleDpiChange
Added to FORMLOAD:
  Global variables for all controls (left, top, width, height)
  Call CompleteDpiSetup as last step of FORMLOAD
Added handling for WM_DPICHANGED event

I know there must be a better way to handle the globals and HandleDpiChange, but this has worked well for me so far.

[Robert]

Here's a DPI aware (PerMonitor V2) version of Robert's updated submission. 

You can use DIFF to see what I changed, but generally speaking...

Added includes: dpi_dynamic.inc and dpi_helpers.inc
Modified RESOURCE section to support PerMonitorV2
Added SUB CompleteDpiSetup
Added SUB HandleDpiChange
Added to FORMLOAD:
  Global variables for all controls (left, top, width, height)
  Call CompleteDpiSetup as last step of FORMLOAD
Added handling for WM_DPICHANGED event

I know there must be a better way to handle the globals and HandleDpiChange, but this has worked well for me so far.

Hi Jeff:

I appreciate this information. It will take some time for me to digest it but I shall.

I would like you to note, and anyone else using the I Love BCX UTF-X23 that the Unicode character display has been hit and miss. I suspect that the cast in the calculation of the surrogate conversion maybe bit-wonky. I'm going to rework it and see if that helps.

[Robert]

Here's a DPI aware (PerMonitor V2) version of Robert's updated submission. 

You can use DIFF to see what I changed, but generally speaking...

Added includes: dpi_dynamic.inc and dpi_helpers.inc
Modified RESOURCE section to support PerMonitorV2
Added SUB CompleteDpiSetup
Added SUB HandleDpiChange
Added to FORMLOAD:
  Global variables for all controls (left, top, width, height)
  Call CompleteDpiSetup as last step of FORMLOAD
Added handling for WM_DPICHANGED event

I know there must be a better way to handle the globals and HandleDpiChange, but this has worked well for me so far.

Hi Jeff:

While I admire your diligence and the mechanistic brute force approach to the DPI problem, which I admit I had contemplated but not being as industrious as you decided to fall back to sloth, I agree that there must be a better way. So far, what James Fuller and myself set up for DPI in BCX, although not too long ago I expressed my doubts, seems to be working but in old code the container dimensions must be recalculated. There's probably an algorithm for this.

In UTF-X23, in pusuit of stability, I have reconfigured the Unicode to surrogate calculations changing

Code: [Select]


GLOBAL wChar2[4] AS wchar_t


to

Code: [Select]


GLOBAL wChar2[4] AS unsigned short


and changing both instances of

Code: [Select]


        wChar2[0] = (wchar_t)(0xD800 | ((UniDec%-0x10000) >> 10))
        wChar2[1] = (wchar_t)(0xDC00 | ((UniDec%-0x10000) & 0x3FF))


to

Code: [Select]


        wChar2[0] = 0xD7C0 + (UniDec% >> 0xA)
        wChar2[1] = 0xDC00 + (UniDec% & 0x3FF)


I also changed the font from MingLiU to Segoe UI Symbol mainly because I like the rendering of U+1F60E SMILING FACE WITH SUNGLASSES which, now that Valentine's Day is over, I have made the default char when GO is pressed. I was considering adding a BCX_UPDOWN to the Unicode Hex and Unicode Decimal boxes but my ambition dribbled away.

I also made it so when a value is changed in either box the corresponding value is set in the other box.

Attached is the update.

[MrBcx]

Attached is a small mod to Robert's earlier version.

I've added a Bcx_UpDown control to more easily browse the glyphs. 
On my PC, the last meaningful glyph corresponds to decimal 178205,
so that's the upper limit that I set the Bcx_UpDown control to.

Click the up or down arrows on the control then click the Go button to the right. 
Clicking that Go button causes the glyph to change and the values in the
Hex and Decimal text boxes should also update.

You will need BCX 7.4.5 to rebuild this version, as it requires the updated Bcx_UpDown control.

I included my build for Pelles -- adjust paths, as needed.

[Robert]

Gracias Amigo.

Font face and color picker next?