You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(195) |
Jun
(105) |
Jul
(146) |
Aug
(283) |
Sep
(151) |
Oct
(143) |
Nov
(204) |
Dec
(359) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(213) |
Feb
(366) |
Mar
(423) |
Apr
(226) |
May
(195) |
Jun
(270) |
Jul
(282) |
Aug
(255) |
Sep
(218) |
Oct
(328) |
Nov
(261) |
Dec
(358) |
2002 |
Jan
(366) |
Feb
(321) |
Mar
(360) |
Apr
(219) |
May
(284) |
Jun
(227) |
Jul
(592) |
Aug
(432) |
Sep
(530) |
Oct
(307) |
Nov
(320) |
Dec
(177) |
2003 |
Jan
(253) |
Feb
(164) |
Mar
(216) |
Apr
(295) |
May
(260) |
Jun
(297) |
Jul
(438) |
Aug
(339) |
Sep
(169) |
Oct
(174) |
Nov
(225) |
Dec
(221) |
2004 |
Jan
(517) |
Feb
(613) |
Mar
(320) |
Apr
(193) |
May
(165) |
Jun
(358) |
Jul
(502) |
Aug
(386) |
Sep
(474) |
Oct
(298) |
Nov
(305) |
Dec
(403) |
2005 |
Jan
(274) |
Feb
(409) |
Mar
(282) |
Apr
(430) |
May
(329) |
Jun
(309) |
Jul
(380) |
Aug
(363) |
Sep
(440) |
Oct
(271) |
Nov
(270) |
Dec
(173) |
2006 |
Jan
(185) |
Feb
(187) |
Mar
(213) |
Apr
(253) |
May
(204) |
Jun
(230) |
Jul
(155) |
Aug
(211) |
Sep
(159) |
Oct
(127) |
Nov
(162) |
Dec
(84) |
2007 |
Jan
(98) |
Feb
(105) |
Mar
(137) |
Apr
(88) |
May
(142) |
Jun
(174) |
Jul
(159) |
Aug
(107) |
Sep
(41) |
Oct
(84) |
Nov
(77) |
Dec
(43) |
2008 |
Jan
(106) |
Feb
(80) |
Mar
(78) |
Apr
(182) |
May
(79) |
Jun
(105) |
Jul
(51) |
Aug
(69) |
Sep
(79) |
Oct
(47) |
Nov
(42) |
Dec
(32) |
2009 |
Jan
(64) |
Feb
(41) |
Mar
(42) |
Apr
(40) |
May
(47) |
Jun
(86) |
Jul
(32) |
Aug
(57) |
Sep
(52) |
Oct
(38) |
Nov
(89) |
Dec
(32) |
2010 |
Jan
(30) |
Feb
(34) |
Mar
(23) |
Apr
(24) |
May
(17) |
Jun
(20) |
Jul
(49) |
Aug
(30) |
Sep
(77) |
Oct
(41) |
Nov
(66) |
Dec
(31) |
2011 |
Jan
(36) |
Feb
(34) |
Mar
(10) |
Apr
(55) |
May
(21) |
Jun
(21) |
Jul
(29) |
Aug
(55) |
Sep
(33) |
Oct
(8) |
Nov
(17) |
Dec
(17) |
2012 |
Jan
(7) |
Feb
(15) |
Mar
(23) |
Apr
(14) |
May
(20) |
Jun
(36) |
Jul
(35) |
Aug
(35) |
Sep
(9) |
Oct
(6) |
Nov
(29) |
Dec
(30) |
2013 |
Jan
(36) |
Feb
(19) |
Mar
(5) |
Apr
(15) |
May
(21) |
Jun
(12) |
Jul
(7) |
Aug
(18) |
Sep
(30) |
Oct
(5) |
Nov
(7) |
Dec
(9) |
2014 |
Jan
(11) |
Feb
(15) |
Mar
|
Apr
(1) |
May
(10) |
Jun
(16) |
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(17) |
Dec
(21) |
2015 |
Jan
(15) |
Feb
(8) |
Mar
(1) |
Apr
(7) |
May
(3) |
Jun
(22) |
Jul
(10) |
Aug
(37) |
Sep
(8) |
Oct
(2) |
Nov
(18) |
Dec
(8) |
2016 |
Jan
(3) |
Feb
(1) |
Mar
(7) |
Apr
(14) |
May
(4) |
Jun
(13) |
Jul
(19) |
Aug
(21) |
Sep
(6) |
Oct
(1) |
Nov
(3) |
Dec
(9) |
2017 |
Jan
(17) |
Feb
(9) |
Mar
(30) |
Apr
(17) |
May
(7) |
Jun
(55) |
Jul
(1) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(4) |
2018 |
Jan
(21) |
Feb
(5) |
Mar
(9) |
Apr
(6) |
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
(3) |
2019 |
Jan
(2) |
Feb
(6) |
Mar
(9) |
Apr
|
May
(9) |
Jun
(3) |
Jul
(7) |
Aug
(2) |
Sep
(22) |
Oct
|
Nov
(10) |
Dec
(11) |
2020 |
Jan
(10) |
Feb
(6) |
Mar
(31) |
Apr
(27) |
May
(6) |
Jun
(4) |
Jul
(34) |
Aug
(3) |
Sep
|
Oct
(4) |
Nov
(51) |
Dec
(27) |
2021 |
Jan
(5) |
Feb
(3) |
Mar
(9) |
Apr
(18) |
May
(2) |
Jun
|
Jul
(12) |
Aug
(32) |
Sep
(16) |
Oct
(16) |
Nov
(1) |
Dec
(4) |
2022 |
Jan
(2) |
Feb
(12) |
Mar
(10) |
Apr
(17) |
May
|
Jun
(3) |
Jul
(4) |
Aug
|
Sep
(7) |
Oct
(23) |
Nov
(26) |
Dec
(1) |
2023 |
Jan
(7) |
Feb
(9) |
Mar
(4) |
Apr
(18) |
May
(17) |
Jun
(26) |
Jul
(24) |
Aug
(2) |
Sep
(10) |
Oct
(3) |
Nov
(11) |
Dec
(4) |
2024 |
Jan
(2) |
Feb
(13) |
Mar
(2) |
Apr
(14) |
May
(22) |
Jun
|
Jul
(16) |
Aug
(3) |
Sep
(3) |
Oct
(38) |
Nov
(3) |
Dec
(13) |
2025 |
Jan
(10) |
Feb
|
Mar
(2) |
Apr
|
May
(5) |
Jun
|
Jul
(17) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Pasquale <pjr...@pr...> - 2025-07-24 23:24:25
|
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 |
From: <je...@fo...> - 2025-07-24 17:24:38
|
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 |
From: <je...@fo...> - 2025-07-24 17:20:43
|
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 |
From: Roland H. <ro...@lo...> - 2025-07-24 17:18:50
|
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 |
From: Pasquale <pjr...@pr...> - 2025-07-24 16:44:53
|
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 |
From: Roland H. <ro...@lo...> - 2025-07-08 14:14:05
|
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 |
From: <je...@fo...> - 2025-07-08 13:16:12
|
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 |
From: <je...@fo...> - 2025-07-08 13:06:04
|
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 |
From: <je...@fo...> - 2025-07-08 12:58:09
|
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 |
From: <je...@fo...> - 2025-07-08 12:42:46
|
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 |
From: John S. <joh...@ja...> - 2025-07-08 12:41:10
|
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 |
From: <je...@fo...> - 2025-07-08 12:33:00
|
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 |
From: Roland H. <ro...@lo...> - 2025-07-08 09:15:14
|
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 |
From: Enno R. <enn...@gm...> - 2025-07-08 08:41:36
|
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 |
From: John S. <joh...@ja...> - 2025-07-08 04:57:24
|
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 |
From: JVZ <je...@fo...> - 2025-07-02 05:53:13
|
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. | +----------------------------------------------------------------------------+ |
From: Basile S. <ba...@st...> - 2025-07-01 11:48:02
|
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 |
From: JVZ <je...@fo...> - 2025-05-18 16:28:02
|
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. | +----------------------------------------------------------------------------+ |
From: <je...@fo...> - 2025-05-16 20:27:06
|
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 |
From: <je...@fo...> - 2025-05-16 20:08:12
|
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 |
From: John S. <joh...@ja...> - 2025-05-16 19:43:39
|
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. https://sourceforge.net/p/foxgui/mailman/message/58831015/ js From: Pasquale via Foxgui-users <fox...@li...> Sent: Friday, May 16, 2025 12:33 PM To: FOX Users <fox...@li...> Subject: [Foxgui-users] Mouse Wheel scrolling in Multiple FXText widgets 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. Pasquale |
From: Pasquale <pjr...@pr...> - 2025-05-16 16:33:14
|
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. Pasquale |
From: <je...@fo...> - 2025-03-10 15:07:58
|
On 2025-03-10 08:38, David Vereb wrote: > Good Morning, > > It seems fox-toolkit.org isn't responding for me. Is anyone else > having the same issue? Perhaps something's up with the hosting? It looks like there's an issue. Trying to find out what caused it. -- JVZ |
From: David V. <de...@er...> - 2025-03-10 14:18:10
|
Good Morning, It seems fox-toolkit.org isn't responding for me. Is anyone else having the same issue? Perhaps something's up with the hosting? Thanks, Dave -- David Vereb /Lead Software Developer/ Office: 814.464.1525 1851 Rudolph Avenue Erie, PA 16502 www.eriestrayer.com <http://www.eriestrayer.com/> Erie Strayer Company Logo & Social Media Icons |
From: Jeroen v. d. Z. <je...@fo...> - 2025-01-31 23:20:34
|
On Fri, 31 Jan 2025 19:01:06 +0000 levan shoshiashvili <sh...@ho...> wrote: > Hello Jeroen > System windows 10 64bit; > VS2022; > Static lib compiles and links fine. > For dll I got those errors: > > 1>imageviewer.cpp > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(104,25): warning C4251: 'FX::FXXML::startDocumentCB': class 'FX::FXCallback<FX::FXXML::Error (void)>' needs to have dll-interface to be used by clients of class 'FX::FXXML' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(104,3): message : see declaration of 'FX::FXCallback<FX::FXXML::Error (void)>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(107,66): warning C4251: 'FX::FXXML::startElementCB': class 'FX::FXCallback<FX::FXXML::Error (const FX::FXString &,const FX::FXStringDictionary &)>' needs to have dll-interface to be used by clients of class 'FX::FXXML' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(107,3): message : see declaration of 'FX::FXCallback<FX::FXXML::Error (const FX::FXString &,const FX::FXStringDictionary &)>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(110,40): warning C4251: 'FX::FXXML::charactersCB': class 'FX::FXCallback<FX::FXXML::Error (const FX::FXString &)>' needs to have dll-interface to be used by clients of class 'FX::FXXML' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(110,3): message : see declaration of 'FX::FXCallback<FX::FXXML::Error (const FX::FXString &)>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(113,40): warning C4251: 'FX::FXXML::commentCB': class 'FX::FXCallback<FX::FXXML::Error (const FX::FXString &)>' needs to have dll-interface to be used by clients of class 'FX::FXXML' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(110,3): message : see declaration of 'FX::FXCallback<FX::FXXML::Error (const FX::FXString &)>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(116,56): warning C4251: 'FX::FXXML::processingCB': class 'FX::FXCallback<FX::FXXML::Error (const FX::FXString &,const FX::FXString &)>' needs to have dll-interface to be used by clients of class 'FX::FXXML' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(116,3): message : see declaration of 'FX::FXCallback<FX::FXXML::Error (const FX::FXString &,const FX::FXString &)>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(119,40): warning C4251: 'FX::FXXML::endElementCB': class 'FX::FXCallback<FX::FXXML::Error (const FX::FXString &)>' needs to have dll-interface to be used by clients of class 'FX::FXXML' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(110,3): message : see declaration of 'FX::FXCallback<FX::FXXML::Error (const FX::FXString &)>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(122,25): warning C4251: 'FX::FXXML::endDocumentCB': class 'FX::FXCallback<FX::FXXML::Error (void)>' needs to have dll-interface to be used by clients of class 'FX::FXXML' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXXML.h(104,3): message : see declaration of 'FX::FXCallback<FX::FXXML::Error (void)>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXThreadPool.h(70,19): warning C4251: 'FX::FXThreadPool::queue': class 'FX::FXLFQueueOf<FX::FXRunnable>' needs to have dll-interface to be used by clients of class 'FX::FXThreadPool' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXThreadPool.h(34,9): message : see declaration of 'FX::FXLFQueueOf<FX::FXRunnable>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXIconCache.h(58,21): warning C4251: 'FX::FXIconCache::dict': class 'FX::FXDictionaryOf<FX::FXIcon>' needs to have dll-interface to be used by clients of class 'FX::FXIconCache' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXIconCache.h(37,9): message : see declaration of 'FX::FXDictionaryOf<FX::FXIcon>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXFileAssociations.h(104,26): warning C4251: 'FX::FXFileAssociations::bindings': class 'FX::FXDictionaryOf<FX::FXFileAssoc>' needs to have dll-interface to be used by clients of class 'FX::FXFileAssociations' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXFileAssociations.h(50,9): message : see declaration of 'FX::FXDictionaryOf<FX::FXFileAssoc>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXList.h(172,18): warning C4251: 'FX::FXList::items': class 'FX::FXObjectListOf<FX::FXListItem>' needs to have dll-interface to be used by clients of class 'FX::FXList' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXList.h(153,9): message : see declaration of 'FX::FXObjectListOf<FX::FXListItem>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXHeader.h(201,20): warning C4251: 'FX::FXHeader::items': class 'FX::FXObjectListOf<FX::FXHeaderItem>' needs to have dll-interface to be used by clients of class 'FX::FXHeader' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXHeader.h(176,9): message : see declaration of 'FX::FXObjectListOf<FX::FXHeaderItem>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXIconList.h(204,22): warning C4251: 'FX::FXIconList::items': class 'FX::FXObjectListOf<FX::FXIconItem>' needs to have dll-interface to be used by clients of class 'FX::FXIconList' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXIconList.h(172,9): message : see declaration of 'FX::FXObjectListOf<FX::FXIconItem>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXUndoList.h(158,19): warning C4251: 'FX::FXCommandGroup::command': class 'FX::FXArray<FX::FXCommandPtr>' needs to have dll-interface to be used by clients of class 'FX::FXCommandGroup' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXUndoList.h(133,9): message : see declaration of 'FX::FXArray<FX::FXCommandPtr>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXConsole.h(56,18): warning C4251: 'FX::FXConsole::contents': class 'FX::FXArray<FX::FXString>' needs to have dll-interface to be used by clients of class 'FX::FXConsole' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXConsole.h(45,9): message : see declaration of 'FX::FXArray<FX::FXString>' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXConsole.h(57,18): warning C4251: 'FX::FXConsole::style': class 'FX::FXArray<FX::FXString>' needs to have dll-interface to be used by clients of class 'FX::FXConsole' > 1>F:\Users\LAE\levan\work\fox-1.7.85\include\FXConsole.h(45,9): message : see declaration of 'FX::FXArray<FX::FXString>' > 1> Creating library F:\Users\LAE\levan\work\fox-1.7.85\windows\x64\Release\ImageViewer.lib and object F:\Users\LAE\levan\work\fox-1.7.85\windows\x64\Release\ImageViewer.exp > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static class FX::FXMetaClass const FX::FXMainWindow::metaClass" (?metaClass@FXMainWindow@FX@@2VFXMetaClass@2@B) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static unsigned short const * const FX::FXhalf::fhb" (?fhb@FXhalf@FX@@0QBGB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static unsigned char const * const FX::FXhalf::fhs" (?fhs@FXhalf@FX@@0QBEB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static unsigned int const * const FX::FXhalf::hfm" (?hfm@FXhalf@FX@@0QBIB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static unsigned int const * const FX::FXhalf::hfe" (?hfe@FXhalf@FX@@0QBIB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static unsigned short const * const FX::FXhalf::hfw" (?hfw@FXhalf@FX@@0QBGB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXException::exceptionName" (?exceptionName@FXException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXFatalException::exceptionName" (?exceptionName@FXFatalException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXErrorException::exceptionName" (?exceptionName@FXErrorException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXRangeException::exceptionName" (?exceptionName@FXRangeException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXPointerException::exceptionName" (?exceptionName@FXPointerException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXResourceException::exceptionName" (?exceptionName@FXResourceException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXMemoryException::exceptionName" (?exceptionName@FXMemoryException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXWindowException::exceptionName" (?exceptionName@FXWindowException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXImageException::exceptionName" (?exceptionName@FXImageException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXFontException::exceptionName" (?exceptionName@FXFontException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXThreadException::exceptionName" (?exceptionName@FXThreadException@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "public: static char const * const FX::FXString::null" (?null@FXString@FX@@2QBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static char const (* FX::FXDate::shortMonthName)[4]" (?shortMonthName@FXDate@FX@@0QAY03$$CBDA) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static char const (* FX::FXDate::longMonthName)[10]" (?longMonthName@FXDate@FX@@0QAY09$$CBDA) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static char const (* FX::FXDate::shortWeekDay)[4]" (?shortWeekDay@FXDate@FX@@0QAY03$$CBDA) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static char const (* FX::FXDate::longWeekDay)[10]" (?longWeekDay@FXDate@FX@@0QAY09$$CBDA) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "protected: static char const * const * const FX::FXJSON::errors" (?errors@FXJSON@FX@@1QBQEBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static char const * const * const FX::FXINI::errors" (?errors@FXINI@FX@@0QBQEBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static char const * const * const FX::FXXML::errors" (?errors@FXXML@FX@@0QBQEBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static class FX::FXApp * FX::FXApp::app" (?app@FXApp@FX@@0PEAV12@EA) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static char const * const * const FX::FXRex::errors" (?errors@FXRex@FX@@0QBQEBDB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static unsigned char const * const FX::FXExpression::initial" (?initial@FXExpression@FX@@0QBEB) > 1>imageviewer.obj : error LNK2001: unresolved external symbol "private: static char const * const * const FX::FXExpression::errors" (?errors@FXExpression@FX@@0QBQEBDB) > 1>F:\Users\LAE\levan\work\fox-1.7.85\windows\x64\Release\ImageViewer.exe : fatal error LNK1120: 29 unresolved externals > > Yes I have set -DFOXDLL in imageviewer project options. You might need -DFOX_DLL -DFOXDLL_EXPORTS when *compiling* the library, and just -DFOX_DLL when *using* the library. FYI, project files for VC++ were missing some files; new snapshot cover this. -- JVZ |