foxgui-users

Re: [Foxgui-users] font dialog error

[John S. <joh...@ja...>]

v1.7.50

It is a custom widget derived form the standard font dialog.

I'll look into what you said.




-----Original Message-----
From: je...@fo... <je...@fo...> 
Sent: Thursday, September 4, 2025 11:28 AM
To: joh...@ja...
Cc: fox...@li...
Subject: Re: [Foxgui-users] font dialog error

On 2025-08-29 16:34, John Selverian wrote:
> On Ubuntu when I enumerate the system fonts and go through them
I get 
> the following error in the cmd window:
> 
> 
> 
> 
> 
> X Error: code 16 major 140 minor 20: BadLength (poly request
too large 
> or internal Xlib length error).

Do you know what version of FOX this was?  Stuff with long
strings was recently fixed and on the linux side, there should be
no buffer length issues at this time.

The fix is two-fold:

1) FXTextField fix which now limits draw calls to visible area.
This should
    be well below buffer limits.

2) FXFont::getTextWidth() change which now measures utf8
character at a time.
    [basically implements exact commands that
XftTextExtentsUtf8() was calling
    under the hood.

3) On Windows, limitations may still exist.  We've removed buffer
limitations
    in FXDCWindow::drawText() and FXDCWindow::drawImageText() on
windows.

Note: drawing APIs are less likely to hit the limits, but
measuring APIs like getTextWidth() are; optimal drawing should
limit itself to visible parts only, and we're now doing a bit
more work to avoid drawing in clipped areas; chiefly, this was
FXTextField as FXText already does this.

If you have custom widgets, perhaps they may have been drawing
clipped parts of text.  A typical screen, e.g. 4k, would only be
able to show a few hundreds of characters, even at really small
font sizes.

   -- JVZ

Re: [Foxgui-users] font dialog error

[<je...@fo...>]

On 2025-09-04 11:00, John Selverian wrote:
> v1.7.50
> 
> It is a custom widget derived form the standard font dialog.

That version is definitely from before the changes.  So please
try with latest snapshot...


     -- JVZ

Re: [Foxgui-users] font dialog error

[<je...@fo...>]

On 2025-08-29 16:34, John Selverian wrote:
> On Ubuntu when I enumerate the system fonts and go through them I
> get the following error in the cmd window:
> 
> 
> 
> 
> 
> X Error: code 16 major 140 minor 20: BadLength (poly request too
> large or internal Xlib length error).

Do you know what version of FOX this was?  Stuff with long strings
was recently fixed and on the linux side, there should be no buffer
length issues at this time.

The fix is two-fold:

1) FXTextField fix which now limits draw calls to visible area.  This 
should
    be well below buffer limits.

2) FXFont::getTextWidth() change which now measures utf8 character at a 
time.
    [basically implements exact commands that XftTextExtentsUtf8() was 
calling
    under the hood.

3) On Windows, limitations may still exist.  We've removed buffer 
limitations
    in FXDCWindow::drawText() and FXDCWindow::drawImageText() on windows.

Note: drawing APIs are less likely to hit the limits, but measuring APIs
like getTextWidth() are; optimal drawing should limit itself to visible
parts only, and we're now doing a bit more work to avoid drawing in
clipped areas; chiefly, this was FXTextField as FXText already does
this.

If you have custom widgets, perhaps they may have been drawing clipped
parts of text.  A typical screen, e.g. 4k, would only be able to show
a few hundreds of characters, even at really small font sizes.

   -- JVZ

[Foxgui-users] font dialog error

[John S. <joh...@ja...>]

On Ubuntu when I enumerate the system fonts and go through them I
get the following error in the cmd window:

 

 

X Error: code 16 major 140 minor 20: BadLength (poly request too
large or internal Xlib length error).

 

 

I've included a screenshot so you can see the setup.

 

 

 

 

Kind regards,

 

js

Re: [Foxgui-users] Building latest snapshop

[<je...@fo...>]

On 2025-08-29 08:11, Cesar wrote:
> Hello,
> 
> I'm having trouble building fox-toolkit and the samples. I was
> successful in building with msys2 mingw64 but whenever i run the
> samples it opens an extra command prompt, even with -mwindows ldflag.
> However with the -mwindows ldflag i can close the command prompy
> without the app closing (calculator for example) so i decided to try
> and build with visual studio instead to see if it does that. But it
> fails to compile because in foxlib the icons.cpp and icons.h keeps
> getting overwritten with an incomplete version. I removed it from the
> "Extensions to Delete on Clean" but it still happens. Please help.
> 
> Thank you,

VStudio2015 works for me; pulling into later versions of VStudio
should work w/o problems, as far as my experience goes.

There's a custom build step to generate icons.h and icons.cpp via
reswrap.  Dependencies are set to ensure reswrap is compiled first
thing, but you might want to make sure that this actually happens.

I have noticed on occasion that custom build step fails; it seems
to be that you have an icons.h or icons.cpp from a previous build;
so clean the project first, and make sure the old icons.h/icons.cpp
are gone.

   -- JVZ

Re: [Foxgui-users] Fox 1.7.86 and png issues

[Pasquale <pjr...@pr...>]

On Thu, Jul 24, 2025 at 1:24 PM, <[je...@fo...](mailto:On Thu, Jul 24, 2025 at 1:24 PM,  <<a href=)> wrote:

> On 2025-07-24 12:18, Roland Hughes via Foxgui-users wrote:
>> stupid question,
>>
>> did you try installing libpng-dev
>>
>> package name might be a wee bit different if you aren't on a
>> Debian/Ubuntu based distro.
>
> libpng-dev is no longer required.
>
> PNG support now is built in; only libz still needed.

Okay, so good to know that png isn’t needed. I relooked at my code and compared it to other code which is similar and apparently I had code in a source/header file that was called before the fox includes. Moving the fox header above the other header worked.

I hadn’t changed anything in my code other than updating the fox version, so I didn’t think it was with my code, but I guess prior to updating fox, I must have changed something.

Thanks everyone for the help!

> -- JVZ
>
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

Re: [Foxgui-users] Fox 1.7.86 and png issues

[<je...@fo...>]

On 2025-07-24 12:18, Roland Hughes via Foxgui-users wrote:
> stupid question,
> 
> did you try installing libpng-dev
> 
> package name might be a wee bit different if you aren't on a
> Debian/Ubuntu based distro.

libpng-dev is no longer required.

PNG support now is built in; only libz still needed.


    -- JVZ

Re: [Foxgui-users] Fox 1.7.86 and png issues

[<je...@fo...>]

On 2025-07-24 11:44, Pasquale via Foxgui-users wrote:
> I switched from v1.7.84 to v1.7.86 to get mousewheel scroll support,
> but when I compile a program, i am getting png issues.
> 
> I noticed in v1.7.86 there is no --disable-png configure option, but
> there is one with v1.7.84, so I was wondering if png support wasn't
> included and how to fix that? I'm don't really know how to modify the
> autoconfig/make system files.
> 
> Thanks,
> Pasquale
> 

Hi,

Before, PNG support could be disabled, in order to avoid linking to PNG
library, which may be big (or, worse, unavailable!).

Now, PNG support is built into FOX so there's no need to disable it 
anymore,
and the implementation is quite small [one single file].  PNG now being
the most common format for non-lossy image compression, we felt it was 
good
to have it supported regardless of libpng availability. [We did add 
another
non-lossy image format, QOIF.  This one is really simple and compression
is pretty good, but not quite as good as PNG].

This new version should work well, but there may be a few improvements 
in the
near future, as the PNG standard has *JUST* been updated [of course this 
had
to happen right after I wrapped up my PNG reader ;-( ].

I have not had time to delve through new PNG docs to see what has 
changed.

Some plans I had before the new PNG standard got dropped on us:

1) Speed up CRC calculation using Intel carry-less multiply [GF(2) 
multiply].
    I've got this *mostly* figured out, but I'm still looking at how this
    should be packaged.  Not sure what we can do about ARM cpus, we might
    need old method as fallback.

2) Some speedups reading and writing the file through FXStream.  Perhaps
    this could be improved a bit.

3) The LZ decoder/encoder could probably also be replaced; right now, 
PNG
    support is still contingent on having libz compression library 
around.
    [Does anyone know if zstd compressed data is compatible with libz; I
    have not been able to find any statement about it...].



    -- JVZ

Re: [Foxgui-users] Fox 1.7.86 and png issues

[Roland H. <ro...@lo...>]

stupid question,

did you try installing libpng-dev

package name might be a wee bit different if you aren't on a 
Debian/Ubuntu based distro.

Probably should tell everyone what platform you are on.

On 7/24/25 11:44 AM, Pasquale via Foxgui-users wrote:
> I switched from v1.7.84 to v1.7.86 to get mousewheel scroll support, but when I compile a program, i am getting png issues.
>
> I noticed in v1.7.86 there is no --disable-png configure option, but there is one with v1.7.84, so I was wondering if png support wasn't included and how to fix that? I'm don't really know how to modify the autoconfig/make system files.
>
> Thanks,
> Pasquale
>
>
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

[Foxgui-users] Fox 1.7.86 and png issues

[Pasquale <pjr...@pr...>]

I switched from v1.7.84 to v1.7.86 to get mousewheel scroll support, but when I compile a program, i am getting png issues.

I noticed in v1.7.86 there is no --disable-png configure option, but there is one with v1.7.84, so I was wondering if png support wasn't included and how to fix that? I'm don't really know how to modify the autoconfig/make system files.

Thanks,
Pasquale

Re: [Foxgui-users] unicode character has 5 digits

[Roland H. <ro...@lo...>]

On 7/8/2025 7:57 AM, je...@fo... wrote:
> Thanks for this wonderful background.  32-bit wide characters would
> indeed incur enormous bloat, but thankfully, it seems UTF8 encoding
> is brilliantly leaving most european langauges very close to 1-byte
> per characters; even people in Korea, Japan, and China, UTF8 is never
> bigger than 32-bit wide characters, but all punctuation, numbers, etc.
> is mercifully as short as 1 byte.
>
> Now RAM and DISK space is cheaper than ever, but the biggest problem
> was always software.  UTF8 also makes software *mostly* able to deal
> with wide characters w/o undue pain and suffering. 

Since I work mostly with embedded systems I've been working on a fork of 
CopperSpice (which is a fork of Qt 4.8 sans QML). One of the many things 
on my never ending TODO list is replace all of the QString classes with 
BdString classes based on UTF8-CPP.

https://github.com/nemtrif/utfcpp?tab=readme-ov-file

I just need to make certain the Boost 1.0 license is compatible.

https://github.com/nemtrif/utfcpp/blob/master/LICENSE

If you are going to pop the hood on strings, you probably want to look 
at that library. I don't remember if Fox is UTF-16 under the hood or 
pure UTF-8.

Yes, UTF-8 has won. Both wide strings and UTF-16 have proven failures. 
Microsoft and a lot of legacy products are trapped with UTF-16.

Too bad embedded systems customers don't like the old Motif look and 
feel Fox has.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

Re: [Foxgui-users] unicode character has 5 digits

[<je...@fo...>]

On 2025-07-08 07:40, John Selverian wrote:
> I try this:
> 
> const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL
> = unescape("\U0001E05F");
> 
> and
> 
> const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL
> = \U0001E05F";
> 
> IN both cases I get this warning on compiling in VS2022:
> 
> “warning C4566: character represented by universal-character-name
> '\U0001E05F' cannot be represented in the current code page (1252)”
> 
> and it displays as ‘??’ in all fonts I try.

Found something else: in some compilers, the escape sequence
only applies to one character, so a 16-bit wide character would
not be able to use \Uxxxxxxxx, only \uxxxx\uxxxx, i.e. a surrogate
pair.  It appears this limitation may go away in future compilers.

FYI, c++ recognized unicode escape sequences require 8 hex digits
for \U and four for \u.



    -- JVZ

Re: [Foxgui-users] unicode character has 5 digits

[<je...@fo...>]

On 2025-07-08 07:40, John Selverian wrote:
> I try this:
> 
> const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL
> = unescape("\U0001E05F");
> 
> and
> 
> const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL
> = \U0001E05F";
> 
> IN both cases I get this warning on compiling in VS2022:
> 
> “warning C4566: character represented by universal-character-name
> '\U0001E05F' cannot be represented in the current code page (1252)”
> 
> and it displays as ‘??’ in all fonts I try.

Please note, on Windows, wide characters are not as wide (only 16-bit).
Thus, surrogate pairs would be needed to compile into 16-bit wide
character strings; wchar_t on windows is 16-bit.

This is partially why FXString can handle both 32-bit wide character
strings as well as 16-bit wide character strings.

So the same code:

     const wchar_t some_string[]=L"blablabla";

is therefore different sizes in Windows vs Linux.

Its OK, FXString can be initialized from both of these, converting them 
to
utf8 immediately.

Needless to say, if you let the compiler unescape escaped characters in
the string, then look at how your compiler does that.  
FXString::unescape()
can also perform unescaping, but then you [at least for now] need to use
surrogate pairs.


    -- JVZ

Re: [Foxgui-users] unicode character has 5 digits

[<je...@fo...>]

On 2025-07-08 03:53, Roland Hughes via Foxgui-users wrote:
> Please define "Does not work."
> 
> Do you get a compilation error?
> 
> Just not see the character?
> 
> What OS are you on?
> 
> I haven't coded with Fox in years, but . . . when it comes to Unicode,
> the first thing you have to do is ensure the font you are using
> actually has the character represented. Most fonts only have a tiny
> subset.
> 
> Here is an ancient discussion about finding which fonts have what
> character
> 
> https://graphicdesign.stackexchange.com/questions/63283/how-to-find-browse-fonts-that-include-certain-rare-characters-unicode-internat
> 
> 
> a 4 year old discussion
> 
> https://www.reddit.com/r/Unicode/comments/l3a3t8/what_font_renders_all_unicode_characters/
> 
> 
> A bit of barefoot in the snow for you
> 
> We should have forced all countries to use American English just so
> software developers would have an easier life. Internationalization is
> where it all went to Hell. Those who are long in the tooth (or now
> toothless) will remember wide characters.
> 
> https://www.geeksforgeeks.org/cpp/wide-char-and-library-functions-in-c/
> 
> 
> This was it!!!  Instead of 256 ASCII values we could now have 65536.
> That would rule the world! Please read point 2 at the top of that.
> wchar_t could be 2 or 4 bytes DEPENDING ON COMPILER USED. Data
> exchange was basically impossible.
> 
> Microsoft, in its infinite wisdom, cough cough hack hack, basically
> got trapped here. They are still trapped here today. Under the hood
> they went with the first cut of UTF-16 to avoid having to do multiple
> value characters like UTF-8 forced. In theory it was faster. Keep in
> mind Windows 3.10 was running no 286 computers so 16-bit at the time.
> 
> https://www.betaarchive.com/forum/viewtopic.php?t=38718
> 
> Still we could not get the population to engage in global nuclear
> warfare and force it to use the one true language, American English,
> where we could make do with good ole ASCII and those wonderful code
> pages. Especially since IBM still thwarts the universe today with
> EBCDIC
> 
> https://en.wikipedia.org/wiki/Code_page
> 
> Guess what?
> 
> Instead of subjugating all others via global warfare, they chose to
> promote peace and love, forming a committee churning out an ever
> larger elephant when the world wanted a mouse. Like all committees, it
> lacked any real industry knowledge. All they ever had was an x86 so
> that must be all that exists.
> 
> Read up on surrogates
> 
> https://en.wikipedia.org/wiki/UTF-16#U+D800_to_U+DFFF_(surrogates)
> 
> Pay attention to the BE (Big Endian) and LE (Little Endian) columns.
> IBM and AMDAL (sp?) are Big Endian. Despite Unisys switching to Intel
> processors they are still ones complement.
> 
> Now, we had a fine fine pickle brine.
> 
> The x86 and ARM world needed to support itty bitty embedded systems
> having 512MB or less of RAM (think universal remote control for your
> TV)
> 
> __AND__
> 
> we now had to be able to indicate the width of a constant.
> 
> The one true world where everything fit into a single 16-bit box was
> gone!
> 
> There is oceans of documentation and legacy code examples out there
> where \u is always used for unicode.
> 
> So now, C programmers, who've never touched a shift key in their life,
> had to use \U
> 
> Just wait for the hack they come up with when the benevolent committee
> lacking industry knowledge bloats UTF past 32.
> 
> UTF-64 is already taken.
> 
> https://utf64.moreplease.com/

Thanks for this wonderful background.  32-bit wide characters would
indeed incur enormous bloat, but thankfully, it seems UTF8 encoding
is brilliantly leaving most european langauges very close to 1-byte
per characters; even people in Korea, Japan, and China, UTF8 is never
bigger than 32-bit wide characters, but all punctuation, numbers, etc.
is mercifully as short as 1 byte.

Now RAM and DISK space is cheaper than ever, but the biggest problem
was always software.  UTF8 also makes software *mostly* able to deal
with wide characters w/o undue pain and suffering.

UTF8 is very clever: you can start a character walk from any point in
a string, as the begin of a character is always recognizable as such;
thus, you can also walk backwards through UTF8 very easily.

Various other encodings of 32-bit wide characters are not nearly as
clever.  So UTF8 is winning and all those who gambled on 16-bit
characters are having the worst of both worlds now: not as compact
as UTF8, while still having variable-sized characters.

So, UTF8 is the way to go.  For those who don't interpret the
characters, just store them, you'll never need to know anything other
than 8-bit safe strings of bytes.  In a few cases, you need to traverse
a character, not a byte at a time, you can look for the magic 
lead-character:

    (ch&0xC0)!=0x80

this takes only two clock cycles!



    -- JVZ

Re: [Foxgui-users] unicode character has 5 digits

[<je...@fo...>]

On 2025-07-08 03:41, Enno Rehling wrote:
> I believe the \u escape sequence is strictly defined for 16-bit
> unicode characters only. try using \U:
> 
> 	char *emoji = "\U0001F92A";
> 
> Enno.

Be aware that FXString::unescape(), at this time, does not interpret 
\UXXXXXXXX,
only \uXXXX.  But it does know about surrogate pairs, so it will convert 
a pair
of escaped surrogate pairs into the proper UTF8 representation.

unescape keeps prior unescaped character, so if it processes a follower 
of a
surrogate pair, and the prior was a leader of a surrogate pair, then the
converted utf8 will be the unpacked wide character.

Maybe I should add the \UXXXXXXXX very wide character decode capability 
as well,
since it makes sense to add it now...


    -- JVZ

Re: [Foxgui-users] unicode character has 5 digits

[John S. <joh...@ja...>]

I try this:

 

const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL = unescape("\U0001E05F");

 

and 

 

const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL = \U0001E05F";

 

 

IN both cases I get this warning on compiling in VS2022:

 

“warning C4566: character represented by universal-character-name '\U0001E05F' cannot be represented in the current code page (1252)”

 

and it displays as ‘??’ in all fonts I try.

 

 

 

 

 

 

From: Roland Hughes via Foxgui-users <fox...@li...> 
Sent: Tuesday, July 8, 2025 4:53 AM
To: fox...@li...
Subject: Re: [Foxgui-users] unicode character has 5 digits

 

Please define "Does not work."

Do you get a compilation error?

Just not see the character?

What OS are you on?

I haven't coded with Fox in years, but . . . when it comes to Unicode, the first thing you have to do is ensure the font you are using actually has the character represented. Most fonts only have a tiny subset.

Here is an ancient discussion about finding which fonts have what character

https://graphicdesign.stackexchange.com/questions/63283/how-to-find-browse-fonts-that-include-certain-rare-characters-unicode-internat

a 4 year old discussion

https://www.reddit.com/r/Unicode/comments/l3a3t8/what_font_renders_all_unicode_characters/

 

A bit of barefoot in the snow for you

We should have forced all countries to use American English just so software developers would have an easier life. Internationalization is where it all went to Hell. Those who are long in the tooth (or now toothless) will remember wide characters.

https://www.geeksforgeeks.org/cpp/wide-char-and-library-functions-in-c/

This was it!!!  Instead of 256 ASCII values we could now have 65536. That would rule the world! Please read point 2 at the top of that.  wchar_t could be 2 or 4 bytes DEPENDING ON COMPILER USED. Data exchange was basically impossible.

Microsoft, in its infinite wisdom, cough cough hack hack, basically got trapped here. They are still trapped here today. Under the hood they went with the first cut of UTF-16 to avoid having to do multiple value characters like UTF-8 forced. In theory it was faster. Keep in mind Windows 3.10 was running no 286 computers so 16-bit at the time.

https://www.betaarchive.com/forum/viewtopic.php?t=38718

Still we could not get the population to engage in global nuclear warfare and force it to use the one true language, American English, where we could make do with good ole ASCII and those wonderful code pages. Especially since IBM still thwarts the universe today with EBCDIC

https://en.wikipedia.org/wiki/Code_page

Guess what?

Instead of subjugating all others via global warfare, they chose to promote peace and love, forming a committee churning out an ever larger elephant when the world wanted a mouse. Like all committees, it lacked any real industry knowledge. All they ever had was an x86 so that must be all that exists.

Read up on surrogates

https://en.wikipedia.org/wiki/UTF-16#U+D800_to_U+DFFF_(surrogates)

Pay attention to the BE (Big Endian) and LE (Little Endian) columns. IBM and AMDAL (sp?) are Big Endian. Despite Unisys switching to Intel processors they are still ones complement.

Now, we had a fine fine pickle brine.

The x86 and ARM world needed to support itty bitty embedded systems having 512MB or less of RAM (think universal remote control for your TV)  

__AND__ 

we now had to be able to indicate the width of a constant.

The one true world where everything fit into a single 16-bit box was gone!

There is oceans of documentation and legacy code examples out there where \u is always used for unicode.

So now, C programmers, who've never touched a shift key in their life, had to use \U

Just wait for the hack they come up with when the benevolent committee lacking industry knowledge bloats UTF past 32.

UTF-64 is already taken.

https://utf64.moreplease.com/

On 7/7/2025 8:27 PM, John Selverian wrote:



I’ve used Unicode successfully in the past. For instance for a subscripted ‘t’ I used:

 

UNICODE_SUBSCRIPT_t_SYMBOL = unescape("\\u209c <file://u209c> ");

 

 

I want to now use a subscripted ‘y’ and found this:

 

IE05F

CYRILLIC SUBSCRIPT SMALL LETTER U

<sub> 0443 y

 

 

But this code: 

 

unescape(\\u1E05F <file://u1E05F> )

 

Does not work. How do I encode a Unicode character with a 5 digit code?

 

 

Kind regards,

 

js






_______________________________________________
Foxgui-users mailing list
Fox...@li... <mailto:Fox...@li...> 
https://lists.sourceforge.net/lists/listinfo/foxgui-users

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

Re: [Foxgui-users] unicode character has 5 digits

[<je...@fo...>]

On 2025-07-07 20:27, John Selverian wrote:
> I've used Unicode successfully in the past. For instance for a
> subscripted 't' I used:
> 
> UNICODE_SUBSCRIPT_t_SYMBOL = unescape("\\u209c");
> 
> I want to now use a subscripted 'y' and found this:
> 
> IE05F
> 
> CYRILLIC SUBSCRIPT SMALL LETTER U
> 
> <sub> 0443 y
> 
> But this code:
> 
> unescape(\\u1E05F [1])
> 
> Does not work. How do I encode a Unicode character with a 5 digit
> code?

Unescape needs to take in a so-called surrogate pair.  A surrogate
pair is two 16-bit wide characters encoding for a 32-bit wide character.

For historic reasons, unicode started out as 16-bit wide characters, but
as these things go, the number of code-points eventually outgrew the 
16-bit
space, and surrogate pairs were needed to encode characters > 16-bit.



32-bit (UCS32) character -> 16-bit (UCS16):

   CH = (U >> 10) + 0xD800
   CL = (U & 0x03FF) + 0xDC00

16-bit UCS16 -> 32-bit UCS32:

   U = (0x10000-(0xD800<<10)-0xDC00) + (CH<<10) + CL

The magic term in the above is to compensate for the fact that two 
constants
were added for CL and CH to package the 32-bit character into the at the 
time
not yet assigned code space of the 16-bit Unicode system.


   -- JVZ

Re: [Foxgui-users] unicode character has 5 digits

[Roland H. <ro...@lo...>]

Please define "Does not work."

Do you get a compilation error?

Just not see the character?

What OS are you on?

I haven't coded with Fox in years, but . . . when it comes to Unicode, 
the first thing you have to do is ensure the font you are using actually 
has the character represented. Most fonts only have a tiny subset.

Here is an ancient discussion about finding which fonts have what character

https://graphicdesign.stackexchange.com/questions/63283/how-to-find-browse-fonts-that-include-certain-rare-characters-unicode-internat

a 4 year old discussion

https://www.reddit.com/r/Unicode/comments/l3a3t8/what_font_renders_all_unicode_characters/


A bit of barefoot in the snow for you

We should have forced all countries to use American English just so 
software developers would have an easier life. Internationalization is 
where it all went to Hell. Those who are long in the tooth (or now 
toothless) will remember wide characters.

https://www.geeksforgeeks.org/cpp/wide-char-and-library-functions-in-c/

This was it!!!  Instead of 256 ASCII values we could now have 65536. 
That would rule the world! Please read point 2 at the top of that.  
wchar_t could be 2 or 4 bytes DEPENDING ON COMPILER USED. Data exchange 
was basically impossible.

Microsoft, in its infinite wisdom, cough cough hack hack, basically got 
trapped here. They are still trapped here today. Under the hood they 
went with the first cut of UTF-16 to avoid having to do multiple value 
characters like UTF-8 forced. In theory it was faster. Keep in mind 
Windows 3.10 was running no 286 computers so 16-bit at the time.

https://www.betaarchive.com/forum/viewtopic.php?t=38718

Still we could not get the population to engage in global nuclear 
warfare and force it to use the one true language, American English, 
where we could make do with good ole ASCII and those wonderful code 
pages. Especially since IBM still thwarts the universe today with EBCDIC

https://en.wikipedia.org/wiki/Code_page

Guess what?

Instead of subjugating all others via global warfare, they chose to 
promote peace and love, forming a committee churning out an ever larger 
elephant when the world wanted a mouse. Like all committees, it lacked 
any real industry knowledge. All they ever had was an x86 so that must 
be all that exists.

Read up on surrogates

https://en.wikipedia.org/wiki/UTF-16#U+D800_to_U+DFFF_(surrogates)

Pay attention to the BE (Big Endian) and LE (Little Endian) columns. IBM 
and AMDAL (sp?) are Big Endian. Despite Unisys switching to Intel 
processors they are still ones complement.

Now, we had a fine fine pickle brine.

The x86 and ARM world needed to support itty bitty embedded systems 
having 512MB or less of RAM (think universal remote control for your TV)

__AND__

we now had to be able to indicate the width of a constant.

The one true world where everything fit into a single 16-bit box was gone!

There is oceans of documentation and legacy code examples out there 
where \u is always used for unicode.

So now, C programmers, who've never touched a shift key in their life, 
had to use \U

Just wait for the hack they come up with when the benevolent committee 
lacking industry knowledge bloats UTF past 32.

UTF-64 is already taken.

https://utf64.moreplease.com/

On 7/7/2025 8:27 PM, John Selverian wrote:
>
> I’ve used Unicode successfully in the past. For instance for a 
> subscripted ‘t’ I used:
>
> UNICODE_SUBSCRIPT_t_SYMBOL = unescape("\\u209c");
>
> I want to now use a subscripted ‘y’ and found this:
>
> IE05F
>
> CYRILLIC SUBSCRIPT SMALL LETTER U
>
> <sub> 0443 y
>
> But this code:
>
> unescape(\\u1E05F <file://u1E05F>)
>
> Does not work. How do I encode a Unicode character with a 5 digit code?
>
> Kind regards,
>
> js
>
>
>
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

Re: [Foxgui-users] unicode character has 5 digits

[Enno R. <enn...@gm...>]

I believe the \u escape sequence is strictly defined for 16-bit unicode 
characters only. try using \U:

	char *emoji = "\U0001F92A";

Enno.

On 7/8/2025 03:27, John Selverian wrote:
> I’ve used Unicode successfully in the past. For instance for a 
> subscripted ‘t’ I used:
> 
> UNICODE_SUBSCRIPT_t_SYMBOL = unescape("\\u209c");
> 
> I want to now use a subscripted ‘y’ and found this:
> 
> IE05F
> 
> CYRILLIC SUBSCRIPT SMALL LETTER U
> 
> <sub> 0443 y
> 
> But this code:
> 
> unescape(\\u1E05F <file://u1E05F>)
> 
> Does not work. How do I encode a Unicode character with a 5 digit code?
> 
> Kind regards,
> 
> js
> 
> 
> 
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Foxgui-users] unicode character has 5 digits

[John S. <joh...@ja...>]

I've used Unicode successfully in the past. For instance for a
subscripted 't' I used:

 

UNICODE_SUBSCRIPT_t_SYMBOL = unescape("\\u209c");

 

 

I want to now use a subscripted 'y' and found this:

 

IE05F

CYRILLIC SUBSCRIPT SMALL LETTER U

<sub> 0443 y

 

 

But this code: 

 

unescape(\\u1E05F <file://u1E05F> )

 

Does not work. How do I encode a Unicode character with a 5 digit
code?

 

 

Kind regards,

 

js

Re: [Foxgui-users] features wishes for FOX (1.7.87 or newer) on Linux

[JVZ <je...@fo...>]

On Tue, 01 Jul 2025 12:42:08 +0200
Basile Starynkevitch <ba...@st...> wrote:

>Hello all
>
>On my Debian/Trixie/x86-64 desktop I did configure FOX 1.7.87 (ie the 
>fox-snapshot.tar.gz2 fetched today near Jul  1 12:00 PM CEST 2025, whose md5sum
>is e250a287d6902ef21b39513a8da3f833) with
>
>     './configure'  '--with-x' '--enable-release' \
>     'CFLAGS=-Dmoncflagsici -O2 -g2' \
>     'CXXFLAGS=-Dmoncxxflagsla -O2 -g2' 'CXX=/usr/local/bin/g++-15'
>
>The G++-15 compiler has been compiled by myself.
>

I suggest:

    export CXX="c++ -Dmoncxxflagsla"

because configure blasts over CXXFLAGS

>The -Dmoncflagsici and -Dmoncxxflagsla preprocessor flags are totally useless,
>but I am adding them to ensure that they are passed. 
>
>Surprisingly make output don't show them.
>
>
>My suggestions (or wishes) are:
>
>1) have the FOX build infrastructure generate some _fox-configure_.h file
>containing all the -DHAVE_* preprocessor flags. This ensure that the compilation
>commands remain short and human readable.
>
>2) provide some API (or generated preprocessor string) containing the
>configuration options. As far as I know GNU autoconf knows how to do that.
>
>3) provide some API to query the (many) optional features (wayland support,
>opengl support, X11 support) and the build time.

That would be useful; we have it in the "About" panel of the FOX projects
like Adie and Pathfinder, but no reason we wouldn't have a published compiled
in string or version number of some kind in the library.

One thing we should check is if shared library and header files "belong to-
gether", i.e. if you're linking to the same library as what you're compiling
to.  It can get confusing if you're working both on applications and on the
library itself.


>4) I have no idea if FOX can be compiled and linked with link-time-optimization
>options. If that is the case please document so.

So, we don't.  I've tried -O3 and obviously, this is faster.  But I feel its
overkill for most code, and highly bloated binary is often generated, where
compiler goes all-out on things which won't matter in terms of user-experience.

Don't forget, we're more influenced by the quality of e.g. device driver
libraries and hardware graphics cards than by our own methods of generating 
the drawing commands.

There's new macros for performance counting [in FOX but also useful for
user generated source code].  It exercises CPU tick counter to measure
time spent in a scope, its great for micro-benchmarking things.

You can also look at google perf [not to be confused with gperf] which makes 
nice call graphs letting you know where the time goes.  This is not 100% useful 
since your typical GUI sits there waiting for a user to do something, but if you
have a few large activities to measure it can be handy.

The design of the public-facing header files in FOX is such that most of
the time, user programs don't need to know the gory platform details [except
that they *are* on Windows vs Linux, for example.  Other special #define's
are set by your compiler automatically, e.g. architecture, o.s. types, etc.

>Regards from near Paris in France (it is terribly hot here).

Hot here too, but that's expected for the Heart of Dixie; I (barely) survived
a heat-stroke last saterday...


   -- JVZ




-- 
+----------------------------------------------------------------------------+
| Copyright (C) 18:50 07/ 1/2025 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

[Foxgui-users] features wishes for FOX (1.7.87 or newer) on Linux

[Basile S. <ba...@st...>]

Hello all

On my Debian/Trixie/x86-64 desktop I did configure FOX 1.7.87 (ie the 
fox-snapshot.tar.gz2 fetched today near Jul  1 12:00 PM CEST 2025, whose md5sum
is e250a287d6902ef21b39513a8da3f833) with

     './configure'  '--with-x' '--enable-release' \
     'CFLAGS=-Dmoncflagsici -O2 -g2' \
     'CXXFLAGS=-Dmoncxxflagsla -O2 -g2' 'CXX=/usr/local/bin/g++-15'

The G++-15 compiler has been compiled by myself.

The -Dmoncflagsici and -Dmoncxxflagsla preprocessor flags are totally useless,
but I am adding them to ensure that they are passed. 

Surprisingly make output don't show them.


My suggestions (or wishes) are:

1) have the FOX build infrastructure generate some _fox-configure_.h file
containing all the -DHAVE_* preprocessor flags. This ensure that the compilation
commands remain short and human readable.

2) provide some API (or generated preprocessor string) containing the
configuration options. As far as I know GNU autoconf knows how to do that.

3) provide some API to query the (many) optional features (wayland support,
opengl support, X11 support) and the build time.

4) I have no idea if FOX can be compiled and linked with link-time-optimization
options. If that is the case please document so.

Thanks for reading.

Regards from near Paris in France (it is terribly hot here).
-- 
Basile STARYNKEVITCH                            <ba...@st...>
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys

Re: [Foxgui-users] Mouse Wheel scrolling in Multiple FXText widgets

[JVZ <je...@fo...>]

On Fri, 16 May 2025 14:25:48 -0400
"John Selverian" <joh...@ja...> wrote:

>I had a similar problem.
>
> 
>
>I have several nested containers/frames/FXScrollWindow/FXTreeList
>
> 
>
>It turns out the FXTreeList was always handling the mousewheel event. I wound up subclassing FXTreeList and capturing the mousewheel there. Maybe you could so the same with the FXText.


I dropped an updated version of FOX this morning [1.7.86]. It fixes the issue
of the SEL_MOUSEWHEEL messages not being routed as a "first-shot" chance to
the target.  So, most widgets will bounce SEL_MOUSEWHEEL to target first;
if target does not handle them [which is of course most of the time], the
regular processing resumes.

A list of other improvements:


   - SEL_MOUSEWHEEL now bounced to target, similarly to other GUI events.

   - New implementation of FXQuatf and FXQuatd setAxes() API. This one is singularity-free.

   - New fastlerp() API in FXQuatf and FXQuatd implements trig-free quaternion interpolation.

   - Improved pow() implementation in FXQuatf and FXQuatd.

   - FOX Calculator fixes.

   - Use argv[0] in adie as name of program in Registry. This means name of editor can be used to 
     provide alternate configuration databases.

   - FindInFiles shows file before reading it.

   - FXPath now assumes user name may contain other characters in tilde-expansion.

   - Missing fxstrcasestr() and fxstrstr() implementation added; needed for this and that.

   - FXText draws control-characters differently now.

   - FXString unicode escapes bug fixes.


 -- JVZ




-- 
+----------------------------------------------------------------------------+
| Copyright (C) 11:20 05/18/2025 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

Re: [Foxgui-users] Mouse Wheel scrolling in Multiple FXText widgets

[<je...@fo...>]

On 2025-05-16 13:25, John Selverian wrote:
> I had a similar problem.
> 
> 
> 
> I have several nested containers/frames/FXScrollWindow/FXTreeList
> 
> 
> 
> It turns out the FXTreeList was always handling the mousewheel event.
> I wound up subclassing FXTreeList and capturing the mousewheel there.
> Maybe you could so the same with the FXText.

Subclassing would work.  But the standard pattern is to bounce first, 
and
this isn't religiously done for SEL_MOUSEWHEEL events.  It should be, so 
I'll
go through stuff and make it so does, because I feel this was an 
unintended
omission.

Most ui events [keyboard, mouse, etc] get bounced first.

You can do beautiful things when you're able to conditionally handle 
mouse
events, so I feel like I'm leaving some nice functionality on the table
if it wasn't implemented.


   -- JVZ

Re: [Foxgui-users] Mouse Wheel scrolling in Multiple FXText widgets

[<je...@fo...>]

On 2025-05-16 11:32, Pasquale via Foxgui-users wrote:
> I have 3 FXText widgets and a vertical FXScrollbar in a 
> horizontalframe.
> 
> I have the code so the scrollbars in the three FXText are hidden, and
> the vertical scrollbar moves all three fxtext areas together when you
> left click on the scrollbar.
> 
> My issue is when you mousewheel scroll in 1 of the FXText. They get
> out of sync. I cannot figure out how to handle/capture the wheel mouse
> scroll in a FXText area so I can also code the movement for the other
> 2 FXText widgets and the FXScrollbar as well and stay synced.
> 
> Also, moving the mousewheel over the FXScrollbar moves the scrollbar
> but doesn't update the scrolling for the FXText widgets.
> 
> I have searched the forum for various phrases and found some
> information, but I was not able to figure it out or fully understand
> what was written. Any help would be greatly appreciated.


Perhaps we should bounce SEL_MOUSEWHEEL events to target prior to 
handling it
in the widget, just like we do with Button and Key events. This way,
you can intercept them to handle them differently.

FYI, for most widgets, the sequence of events upon a mouse or keyboard
event is to:

  (1) bounce to the widget's target (the message ID is the one from the
      widget, not 0 anymore).

  (2) if the target didn't handle it [i.e. target->handle() returned 0], 
then
      continue to handle it.

  (3) if the target *did* handle it, end the SEL_MOUSEWHEEL processing 
there.

It looks like for some reason the wheel event mostly doesn't get 
processed that
way, but this is mot how it works for the other events.  All other 
events get
bounced to the target first, so that target can override the processing 
w/o
having to subclass the widget.

Often, the bounce-processing is conditional; for example in the editor, 
the
mouse right-release is only processed if there was no mouse movement 
since the
mouse right-press.  Then a popup is brought up.  If there was a 
movement, then
its not intercepted.


   -- JVZ