foxgui-users

Re: [Foxgui-users] FOX development version updated

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

Well, it is was created with a different set of libraries . . . 😳 . . . 
but I modeled RedDiamond after EDT

https://sourceforge.net/projects/reddiamond/

Things are compiled in debug, even in the AppImage. I'm kind of locked 
into Scintilla undo-redo but, one of the many places RedDiamond shines 
is backups. I came from OpenVMS where we had Files-11 with file 
versioning. You could have 32767 versions of a file. Every time you save 
it creates a new backup version. I think I had a timer too. Under Tools 
you can "show backups" and get a list of all the backup versions with 
timestamps. You can then choose one to open. What I haven't gotten to 
because I'm too busy with other things like novels

https://twentyoftwo.com

is adding Meld/Diff capability so one could compare the backup version 
and just move stuff across as Meld allows you to do.


On 11/20/25 9:03 AM, je...@fo... wrote:
>
> With alternate history on, the "redo list" is placed as into the undo
> list, first in reverse, then again forwardly.
>
> So you can undo, undo the redo, then redo the undo, and so on. 
>
-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

Re: [Foxgui-users] FOX development version updated

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

On 2025-11-20 04:03, Roland Hughes via Foxgui-users wrote:
> Yeah!!!!
> 
> I haven't been using Adie 😲 but externally modified warnings on most
> text editors are annoying as all Hell. I don't know if you have access
> to one, but TerraMaster F4-210

Yes, it can be.  But also useful if you do a git pull and other files
than you expect are changed, like the one you were editing.

Here's the check button [see image].

The "Alternate History" was also nice addition; in case people have not
yet discovered it, it keeps alternate history.  When you enter a bunch
of new code, decide to undo it, then do something else.  After doing
this, you decide the part you undid has some value and you want to
get it back.

With alternate history on, the "redo list" is placed as into the undo
list, first in reverse, then again forwardly.

So you can undo, undo the redo, then redo the undo, and so on.


My implementation is super efficient in that the undo records are only
stored once.  Even so, doing this doubling can build up exponentially;
thus keeping the records only once is a major win.  Only the pointers
to the undo-records are doubled... ;-)


               -- JVZ

Re: [Foxgui-users] FOX development version updated

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

Yeah!!!!

I haven't been using Adie 😲 but externally modified warnings on most 
text editors are annoying as all Hell. I don't know if you have access 
to one, but TerraMaster F4-210

https://www.bhphotovideo.com/c/product/1501786-REG/terramaster_f4_210_4_bay_nas_quad.html?kws=000000&csid=f7a50c5f-1086-48e7-bca9-ef6829f9b2e0

basically any NAS configured for RAID 10 will throw these in most 
monitoring editors. Part of it has to do with "lock tricks" Linux based 
editors want to use that the storage format doesn't support. The other 
part is RAID 10 itself, and the real kick to the crotch is the 
"performance boosting." Currently used files can get "moved" into a RAM 
disk type contraption which is great if one is using the devices as a 
media server for movies. Duth sucketh if you a using a text editor 
monitoring for externally changed file as the Cylon eye timer 
periodically sweeps changes back to disk.

Kudos!

You should test Adie on one of those. Have to find them on the second 
hand market now though. I know, you are going to tell me to test it for 
you 😂

Been contemplating, and dreading, upgrading to one of these.

https://www.terra-master.com/products/f6-424-max

Dual M.2 lightning caching or whatever they call it, plus the RAM disk 
stuff. Not necessarily this one, but some of the newer NAS are like IBM 
mainframe storage. Hierarchical. They have the RAM disk for super 
critical caching, M.2 for larger caching, then they allow you to 
segregate SSD and HDD. That's a lot of sweeping and "externally 
modified" warnings when all that happened is the storage system 
refreshed the media and RAID pieces.

On 11/19/2025 8:29 PM, JVZ wrote:
> A new option can now be used to avoid future popups if some process repeatedly changes the file. Also, when exiting Adie, if file was changed externally, you get one more chance to save text buffer contents.

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

[Foxgui-users] FOX development version updated

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

November 19 - FOX DEVELOPMENT 1.7.87

    Updated implementation of __sscanf(), __strtod(), __strtof() using Lemire's algorithm.
    New closestAlongRay() API in FXVec3f, FXVec3d calculates closest point bewteen two 3D line segments.
    Fast, square-rootless and division-less approximate vector fastnormalize(); plus, inlined normalize().
    FXText drawing fix that will remove drawing limitations.
    Inlined character classifications in fxascii.h.
    Experimental FXPathBox replacing FXDirBox in FXFileDialog.
    FXFileDialog not listing ".." anymore; always caused problems.
    FXString wide-character unicode escaping sequences interpreted "\Uxxxxxxxx".
    Out-of-bounds read in FXString fixed.
    Super-accurate, branch-free setAxes() API in Quaternion classes.
    Quaternion setAxisAngle() API replaced by setRotate().
    Simplified (faster) setXRotate(), setYRotate(), setZRotate() APIs on Quaternion for quicker setup rotations about principle axes.
    FXPath improvements for dealing with Windows pathname idiosyncracies.
    FXDir listing files in a directory can return some extra information w/o need for a call to FXStat API, on filesystems where this is supported.
    FXPath pathname conversion from "foreign" to "local" operating system conventions.
    WIN32_LEAN_AND_MEAN prior to including windows.h.
    Slightly more accurate conversions between FXVec4f, FXVec4d and FXColor.
    List filename before context, and folder at the end in Adie FindInFiles.
    FXExpression can now have constants as well as variables.
    FXRex quick check for empty string.
    Adie text editor syntax pattern for YAML added.
    Syntax highlighting for Rust programming language added.
    When file being editor by Adie is changed outside of editor, or removed, a message is popped. A new option can now be used to avoid future popups if some process repeatedly changes the file. Also, when exiting Adie, if file was changed externally, you get one more chance to save text buffer contents.
    Added options to FXMessageBox.
    ControlPanel now has control to set display resolution (dpi).
    Fallback code for 64-bit leading zero count, trailing zero count on Windows.
    Ability to parse hexadecimal floats added.

    ... and much more...


 -- JVZ


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

Re: [Foxgui-users] copy FXTable

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

Hopefully I won't confuse anything here.

http://www.fox-toolkit.org/ref/classFX_1_1FXTable.html

virtual long 	tryHandle 
<http://www.fox-toolkit.org/ref/classFX_1_1FXObject.html#a23f54e2d9e11157a8da0ad1d4da7291f>(FXObject 
<http://www.fox-toolkit.org/ref/classFX_1_1FXObject.html>*sender, 
FXSelector sel, void *ptr)
	Try handle message safely, catching certain exceptions.


https://learn.microsoft.com/en-us/answers/questions/4103694/clipboard-problems-(can-not-copy-paste)-in-windows

Didn't read through all of it, but appears Windows 11 has problems with 
clipboard ownership and serious problems when clipboard history is enabled.

On 10/17/2025 6:56 AM, John Selverian wrote:
>
> I have the following code which is called when the user clicks a 
> button, it copies data in a table and puts it on the clip board. It 
> was working fine. After some recent Win11 updates it fails about 1/3 
> of the time. When I click the button then paste into Excel I get a 
> “cannot paste” error in Excel or if I just paste it into a text editor 
> nothing is pasted. So it seems like the copy command in my code is 
> failing. I have to click the button 1 or 2 times then it works. Is 
> there a way to know if the copy command worked? The code below always 
> return a result of 1, even when the copy does not work.
>
> void* ptr = nullptr;
>
> long result = table->handle(this, FXSEL(SEL_COMMAND, 
> FXTable::ID_COPY_SEL), ptr);
>
> if (result == 0)
>
> {
>
> FXMessageBox::warning(this, MBOX_OK, "Copy problem", "Could not copy 
> the table.");
>
> }
>
> 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

[Foxgui-users] copy FXTable

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

I have the following code which is called when the user clicks a
button, it copies data in a table and puts it on the clip board.
It was working fine. After some recent Win11 updates it fails
about 1/3 of the time. When I click the button then paste into
Excel I get a "cannot paste" error in Excel or if I just paste it
into a text editor nothing is pasted. So it seems like the copy
command in my code is failing. I have to click the button 1 or 2
times then it works. Is there a way to know if the copy command
worked? The code below always return a result of 1, even when the
copy does not work.

 

 

                                void* ptr = nullptr;

 

                                long result = table->handle(this,
FXSEL(SEL_COMMAND, FXTable::ID_COPY_SEL), ptr);

 

                                if (result == 0)

                                {

 
FXMessageBox::warning(this, MBOX_OK, "Copy problem", "Could not
copy the table.");

                                }

 

 

Kind regards,

 

js

 

 

Re: [Foxgui-users] passing FXArray by reference

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

On 10/2/2025 7:51 AM, Enno Rehling wrote:
>
>
> As to what the C (and C++) standards say, leading underscores aren't 
> allowed in GLOBAL identifiers: 
> https://rgambord.github.io/c99-doc/sections/7/1/3/index.html
>
>
I work in embedded systems, specifically medial devices.

c. No variable shall have a name that begins with an underscore

The Barr Group coding standard keeps you out of prison.

https://barrgroup.com/sites/default/files/barr_c_coding_standard_2018.pdf

Re: [Foxgui-users] passing FXArray by reference

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

Actually, I can use the "const" keyword.

I just had to change:

FXArray<Test>*  arrayPtr;

To 

const FXArray<Test>*  arrayPtr;





-----Original Message-----
From: John Selverian <joh...@ja...> 
Sent: Thursday, October 2, 2025 6:04 PM
To: je...@fo...
Cc: fox...@li...
Subject: Re: [Foxgui-users] passing FXArray by reference

That did it, save me about 2 seconds but it was tying up the UI so it's nicer now. 

I had to use:

	arrayPtr ->at(i)

Instead of this:

           arrayPtr->[i]



I also had to get rid of the "const" keyword. That is what was messing me up before when I tried this.



thanks,



-----Original Message-----
From: je...@fo... <je...@fo...>
Sent: Thursday, October 2, 2025 11:13 AM
To: joh...@ja...
Cc: fox...@li...
Subject: Re: [Foxgui-users] passing FXArray by reference

On 2025-10-02 09:18, John Selverian wrote:
> I understand pass-by-reference (usually).
> 
> However, this this case it seems my variable is complicated and I 
> can't get the calling/declaration correct.
> 
> Passing it the way I'm doing it now works without a copy until I get 
> to the line "_testArray = testArray;" in class I'm passing it to.
> 
> I don’t see how to assign the passed pointer to a pointer in the 
> class...or how to declare the testArray variable in the class I'm 
> passing it to so it is a pointer to an FXArray< Test >.
> 
> 
> 
> 
> In my main program I declare it like this:
> 
>                 FXArray<Test> _testArrayMain;
> 
> And I pass it like this:
> 
> 	Search search (_testArrayMain);
> 
> 
> 
> In the class I’m passing it to I have this:
> 
> In the header:
> 
> Search (const FXArray< Test >&);
> FXArray<Test> _testArray; // I don’t know what this declaration should 
> be so only the pointers are assigned without a copy
> 
> In the class source:
> 
> Search::Search(const FXArray< Test >& testArray) {
> 	_testArray = testArray; // this line triggers the copy of all of the 
> data }

OK, now we see your problem.  But at least know this, passing by reference parameter has halved the number of copies, at least.

Consider maybe declaring things in terms of pointers, instead:


   member variable:

   FXArray<Test>*  arrayPtr;

then

   setTheArray(FXArray<Test>* ptr){

     arrayPtr=ptr;

   }



Then access array i as:

           arrayPtr->[i]


This accomplishes the whole enchilada with zero copying [thus, very fast].  Now you just need to remember who actually "owns" the array i.e. where in the s/w the array will eventually get deleted.

This could be FXAutoPtr<FXArray> so you can't forget deleting stuff when it goes out of scope.

         -- JVZ



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

Re: [Foxgui-users] passing FXArray by reference

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

That did it, save me about 2 seconds but it was tying up the UI so it's nicer now. 

I had to use:

	arrayPtr ->at(i)

Instead of this:

           arrayPtr->[i]



I also had to get rid of the "const" keyword. That is what was messing me up before when I tried this.



thanks,



-----Original Message-----
From: je...@fo... <je...@fo...> 
Sent: Thursday, October 2, 2025 11:13 AM
To: joh...@ja...
Cc: fox...@li...
Subject: Re: [Foxgui-users] passing FXArray by reference

On 2025-10-02 09:18, John Selverian wrote:
> I understand pass-by-reference (usually).
> 
> However, this this case it seems my variable is complicated and I 
> can't get the calling/declaration correct.
> 
> Passing it the way I'm doing it now works without a copy until I get 
> to the line "_testArray = testArray;" in class I'm passing it to.
> 
> I don’t see how to assign the passed pointer to a pointer in the 
> class...or how to declare the testArray variable in the class I'm 
> passing it to so it is a pointer to an FXArray< Test >.
> 
> 
> 
> 
> In my main program I declare it like this:
> 
>                 FXArray<Test> _testArrayMain;
> 
> And I pass it like this:
> 
> 	Search search (_testArrayMain);
> 
> 
> 
> In the class I’m passing it to I have this:
> 
> In the header:
> 
> Search (const FXArray< Test >&);
> FXArray<Test> _testArray; // I don’t know what this declaration should 
> be so only the pointers are assigned without a copy
> 
> In the class source:
> 
> Search::Search(const FXArray< Test >& testArray) {
> 	_testArray = testArray; // this line triggers the copy of all of the 
> data }

OK, now we see your problem.  But at least know this, passing by reference parameter has halved the number of copies, at least.

Consider maybe declaring things in terms of pointers, instead:


   member variable:

   FXArray<Test>*  arrayPtr;

then

   setTheArray(FXArray<Test>* ptr){

     arrayPtr=ptr;

   }



Then access array i as:

           arrayPtr->[i]


This accomplishes the whole enchilada with zero copying [thus, very fast].  Now you just need to remember who actually "owns" the array i.e. where in the s/w the array will eventually get deleted.

This could be FXAutoPtr<FXArray> so you can't forget deleting stuff when it goes out of scope.

         -- JVZ

Re: [Foxgui-users] passing FXArray by reference

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

On 2025-10-02 09:18, John Selverian wrote:
> I understand pass-by-reference (usually).
> 
> However, this this case it seems my variable is complicated and I
> can't get the calling/declaration correct.
> 
> Passing it the way I'm doing it now works without a copy until I get
> to the line "_testArray = testArray;" in class I'm passing it to.
> 
> I don’t see how to assign the passed pointer to a pointer in the
> class...or how to declare the testArray variable in the class I'm
> passing it to so it is a pointer to an FXArray< Test >.
> 
> 
> 
> 
> In my main program I declare it like this:
> 
>                 FXArray<Test> _testArrayMain;
> 
> And I pass it like this:
> 
> 	Search search (_testArrayMain);
> 
> 
> 
> In the class I’m passing it to I have this:
> 
> In the header:
> 
> Search (const FXArray< Test >&);
> FXArray<Test> _testArray; // I don’t know what this declaration should
> be so only the pointers are assigned without a copy
> 
> In the class source:
> 
> Search::Search(const FXArray< Test >& testArray)
> {
> 	_testArray = testArray; // this line triggers the copy of all of the 
> data
> }

OK, now we see your problem.  But at least know this, passing by 
reference parameter
has halved the number of copies, at least.

Consider maybe declaring things in terms of pointers, instead:


   member variable:

   FXArray<Test>*  arrayPtr;

then

   setTheArray(FXArray<Test>* ptr){

     arrayPtr=ptr;

   }



Then access array i as:

           arrayPtr->[i]


This accomplishes the whole enchilada with zero copying [thus, very 
fast].  Now you
just need to remember who actually "owns" the array i.e. where in the 
s/w the array
will eventually get deleted.

This could be FXAutoPtr<FXArray> so you can't forget deleting stuff when 
it goes
out of scope.

         -- JVZ

Re: [Foxgui-users] passing FXArray by reference

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

I understand pass-by-reference (usually).

However, this this case it seems my variable is complicated and I can't get the calling/declaration correct.

Passing it the way I'm doing it now works without a copy until I get to the line "_testArray = testArray;" in class I'm passing it to.

I don’t see how to assign the passed pointer to a pointer in the class...or how to declare the testArray variable in the class I'm passing it to so it is a pointer to an FXArray< Test >.




In my main program I declare it like this:

                FXArray<Test> _testArrayMain;

And I pass it like this:

	Search search (_testArrayMain);



In the class I’m passing it to I have this:

In the header:

Search (const FXArray< Test >&);
FXArray<Test> _testArray; // I don’t know what this declaration should be so only the pointers are assigned without a copy

In the class source:

Search::Search(const FXArray< Test >& testArray)
{
	_testArray = testArray; // this line triggers the copy of all of the data
}






js

-----Original Message-----
From: Enno Rehling <enn...@gm...> 
Sent: Thursday, October 2, 2025 8:52 AM
To: fox...@li...
Subject: Re: [Foxgui-users] passing FXArray by reference


>> 1. C++ developers are never supposed to declare variables that start
>>    with "_" because that is reserved for internal compiler and 
>> library
>>    things.
> 
> Its C++ you're working with, it mangles names.  So you're probably not 
> clashing with anything.
> Plus, [even though I personally don't like the habit], its common for 
> member variables to be prefixed with "_" or "m_" and if this were to 
> break things, then a LOT of c++ code would have been broken.

The underscore for member variables is a C#-ism. It's also used in some languages (Python) to denote a private member variable.

As to what the C (and C++) standards say, leading underscores aren't allowed in GLOBAL identifiers: 
https://rgambord.github.io/c99-doc/sections/7/1/3/index.html

>> 2. That assignment statement in the above snippet is making a copy. 
>> If
>>    you pass by reference, there is no need to make a copy. Simply use
>>    the variable as if it were local.
> 
> Yes, but that's where you could use the adopt() call. Of course you'd 
> lose the original at that point, but if this is a hand-over then 
> that's what you want. If its not a hand-over, one must make a copy.
> 
> But passing by reference would at least avoid a 2nd copy.
> 
> Just FYI, I have seen C++'s humble "reference &" gone AWOL, and if its 
> missing YUGE performance hit results.  Everything continues to work, 
> but a giant copy can result.

I'm also seeing more and more new developers who don't seem to know the importance of pass-by-reference. But I think educating them is outside the scope of this mailing list. That's what you pay your college for, and if they didn't teach it, you should ask for your money back.

>> SELECT FROM WHERE <https://www.sqlitetutorial.net/sqlite-where/>.  
>> You can even ORDER BY.
> 
> Yes, somewhere between big array and huge array you can switch to 
> sqlite or mysql [mariadb].  A full-on database will give you 
> replication and all sorts of other wonderful stuff.

There are still situations where you want all your data in memory for performance. You wouldn't do large matrix multiplications or A* path finding on data stored in MySQL, for example. The problem occurs when you're (accidentally) copying lots of that data around.

Enno.



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

Re: [Foxgui-users] passing FXArray by reference

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

>> 1. C++ developers are never supposed to declare variables that start
>>    with "_" because that is reserved for internal compiler and library
>>    things.
> 
> Its C++ you're working with, it mangles names.  So you're probably not
> clashing with anything.
> Plus, [even though I personally don't like the habit], its common for
> member variables to be prefixed with "_" or "m_" and if this were to
> break things, then a LOT of c++ code would have been broken.

The underscore for member variables is a C#-ism. It's also used in some 
languages (Python) to denote a private member variable.

As to what the C (and C++) standards say, leading underscores aren't 
allowed in GLOBAL identifiers: 
https://rgambord.github.io/c99-doc/sections/7/1/3/index.html

>> 2. That assignment statement in the above snippet is making a copy. If
>>    you pass by reference, there is no need to make a copy. Simply use
>>    the variable as if it were local.
> 
> Yes, but that's where you could use the adopt() call. Of course you'd
> lose the original at that point, but if this is a hand-over then that's
> what you want. If its not a hand-over, one must make a copy.
> 
> But passing by reference would at least avoid a 2nd copy.
> 
> Just FYI, I have seen C++'s humble "reference &" gone AWOL, and if its
> missing YUGE performance hit results.  Everything continues to work,
> but a giant copy can result.

I'm also seeing more and more new developers who don't seem to know the 
importance of pass-by-reference. But I think educating them is outside 
the scope of this mailing list. That's what you pay your college for, 
and if they didn't teach it, you should ask for your money back.

>> SELECT FROM WHERE <https://www.sqlitetutorial.net/sqlite-where/>.  You
>> can even ORDER BY.
> 
> Yes, somewhere between big array and huge array you can switch to sqlite
> or mysql [mariadb].  A full-on database will give you replication and
> all sorts of other wonderful stuff.

There are still situations where you want all your data in memory for 
performance. You wouldn't do large matrix multiplications or A* path 
finding on data stored in MySQL, for example. The problem occurs when 
you're (accidentally) copying lots of that data around.

Enno.

Re: [Foxgui-users] passing FXArray by reference

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

On 2025-10-02 05:04, Roland Hughes via Foxgui-users wrote:
> Granted, I've never used Fox in production for anything, but, I do try
> to help out here from time to time.
> 
> Search::Search(const FXArray< Test >& testArray)
> 
> {
> 
> _testArray = testArray;
> 
> }
> 
> Unless I just got up too early:
> 
> 1. C++ developers are never supposed to declare variables that start
>    with "_" because that is reserved for internal compiler and library
>    things.

Its C++ you're working with, it mangles names.  So you're probably not
clashing with anything.
Plus, [even though I personally don't like the habit], its common for
member variables to be prefixed with "_" or "m_" and if this were to
break things, then a LOT of c++ code would have been broken.

> 2. That assignment statement in the above snippet is making a copy. If
>    you pass by reference, there is no need to make a copy. Simply use
>    the variable as if it were local.

Yes, but that's where you could use the adopt() call. Of course you'd
lose the original at that point, but if this is a hand-over then that's
what you want. If its not a hand-over, one must make a copy.

But passing by reference would at least avoid a 2nd copy.

Just FYI, I have seen C++'s humble "reference &" gone AWOL, and if its
missing YUGE performance hit results.  Everything continues to work,
but a giant copy can result.

I have seen 1000 x 1000 arrays being "accidentally" copied due to one 
missing
'&' and needless to say, that is a lot of data to be copying if you 
didn't
mean to.



> *Note:* when passing a variable by reference (or pointer) any changes
> you make will be permanent. If you are trying to manipulate the data
> without making changes to the actual data, you /have/ to make copy.

Yes, when you do this often, I recommend const-reference whenever 
possible,
unless the variable is an output or in-out variable.

> *Note 2:* "very large" I know colleges have a really bad habit of
> teaching kids to do everything with arrays in memory, but large data
> needs to be in large storage. Sadly, they don't teach students to use
> databases. SQLite3 <https://sqlite.org/index.html> is free and
> available everywhere. I don't know if Fox has a front end for it or
> not. Yes, if you absolutely must, you can make in-memory databases
> instead of ones on disk.


> SELECT FROM WHERE <https://www.sqlitetutorial.net/sqlite-where/>.  You
> can even ORDER BY.

Yes, somewhere between big array and huge array you can switch to sqlite
or mysql [mariadb].  A full-on database will give you replication and
all sorts of other wonderful stuff.

That said, what was big 20 years ago is now called insignificant in the
64 bit world where even micro-controllers have moved up from 8-bit to
32-bit.



           -- JVZ

Re: [Foxgui-users] passing FXArray by reference

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

Granted, I've never used Fox in production for anything, but, I do try 
to help out here from time to time.

Search::Search(const FXArray< Test >& testArray)

{

_testArray = testArray;

}

Unless I just got up too early:

 1. C++ developers are never supposed to declare variables that start
    with "_" because that is reserved for internal compiler and library
    things.
 2. That assignment statement in the above snippet is making a copy. If
    you pass by reference, there is no need to make a copy. Simply use
    the variable as if it were local.

*Note:* when passing a variable by reference (or pointer) any changes 
you make will be permanent. If you are trying to manipulate the data 
without making changes to the actual data, you /have/ to make copy.

*Note 2:* "very large" I know colleges have a really bad habit of 
teaching kids to do everything with arrays in memory, but large data 
needs to be in large storage. Sadly, they don't teach students to use 
databases. SQLite3 <https://sqlite.org/index.html> is free and available 
everywhere. I don't know if Fox has a front end for it or not. Yes, if 
you absolutely must, you can make in-memory databases instead of ones on 
disk.

SELECT FROM WHERE <https://www.sqlitetutorial.net/sqlite-where/>.  You 
can even ORDER BY.

I'm old, so I hate re-inventing the wheel.



On 10/1/2025 7:45 PM, John Selverian wrote:
>
> I’m currently passing an FXArray by value. I’d like to pass it by 
> reference since it is very large but I can’t seem to get it right.
>
> In my main program I declare it like this:
>
> FXArray<Test> _testArrayMain;
>
> And I pass it like this:
>
> Search search (_testArrayMain);
>
> In the routine I’m passing it to I have this:
>
> In the header:
>
> FXArray<Test> _testArray;
>
> Search (const FXArray< Test >&);
>
> In the source:
>
> Search::Search(const FXArray< Test >& testArray)
>
> {
>
> _testArray = testArray;
>
> }
>
> It gets passed fine but it takes awhile since it is so big. I’ve tried 
> many different ways but I always get many compiler errors.
>
> How would I pass it by reference?
>
> 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] passing FXArray by reference

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

On Wed, 1 Oct 2025 20:45:02 -0400
"John Selverian" <joh...@ja...> wrote:

>I'm currently passing an FXArray by value. I'd like to pass it by
>reference since it is very large but I can't seem to get it
>right.


void someFunction(FXArray<Test>& by_ref){ ... }

or:

void someFunction(const FXArray<Test>& by_const_ref){ ... }


We also have an alternative:


	FXArray<Test> oldplace;

	FXArray<Test> newplace;

	newplace.adopt(oldplace);

This leaves oldplace empty, newplace with the data of
the oldplace.  This is just a pointer manipulation 
and should take barely any time at all....







         -- JVZ





-- 
+----------------------------------------------------------------------------+
| Copyright (C) 21:30 10/ 1/2025 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

[Foxgui-users] passing FXArray by reference

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

I'm currently passing an FXArray by value. I'd like to pass it by
reference since it is very large but I can't seem to get it
right.

 

 

In my main program I declare it like this:

 

                FXArray<Test> _testArrayMain;

 

And I pass it like this:

 

Search search (_testArrayMain);

 

 

 

In the routine I'm passing it to I have this:

 

In the header:

 

FXArray<Test> _testArray;

Search (const FXArray< Test >&);

 

 

In the source:

 

Search::Search(const FXArray< Test >& testArray)

{

_testArray = testArray;

}

 

 

 

 

It gets passed fine but it takes awhile since it is so big. I've
tried many different ways but I always get many compiler errors.

 

How would I pass it by reference?

 

 

 

 

Kind regards,

 

js

Re: [Foxgui-users] FXText setSelection

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

On 2025-09-22 13:13, John Selverian wrote:
> I have an FXText control and I use the following to select all of
> the text:
> 
> 
> 
> 
> 
>                 // select all
> 
>                 text->setSelection(0, text->getLength(), false);
> 
> 
> 
> 
> 
> it works fine but what I run "Code Analysis" in MSVS I get the
> following warning:
> 
> 
> 
> 
> 
> warning C6385: Reading invalid data from 'this->text':  the
> readable size is '8' bytes, but '261864' bytes may be read.
> 
> 
> 
> 
> 
> I get a similar warning:
> 
> 
> 
> warning C6386: Buffer overrun while writing to '_x_orig[iCurve]':
> the writable size is 'numDataPoints*8' bytes, but '16' bytes
> might be written.
> 
> 
> 
> 
> 
> With the code below:
> 
> 
> 
> 
> 
> 
> 
>                 // copy data to local arrays
> 
>                 for (int iCurve = 0; iCurve < _numCurves;
> iCurve++)
> 
>                 {
> 
>                                 for (int i = 0; i <
> _numDataPoints[iCurve]; i++)
> 
>                                 {
> 
>                                                 _x[iCurve][i] =
> _x_orig[iCurve][i] = plotDataArray[iCurve].x[i];
> 
>                                                 _y[iCurve][i] =
> _y_orig[iCurve][i] = plotDataArray[iCurve].y[i];
> 
>                                 }
> 
>                 }
> 
> 
> 
> 
> 
> 
> 
> 
> 
> What does this mean?

------

Possibility is that analyzer gets confused.  The array access to 
FXString's
buffer, and FXArray's buffer starts PAST the pointer returned by malloc, 
on account
of the fact that I keep the size of the arrays inside the array as the 
1st element;
[and before you ask, yes, stuff *does* pay attention to possible 
alignment issues].

Simple-minded code analysis may be thinking that array should start at 
pointer
returned to malloc.

On top of that, array sizes are allocated to the nearest multiple of 
ROUNDVAL,
[16 bytes in case of FXString].  Rationale is that you can't *really* 
allocate
anything smaller than that [first, malloc keeps some bookkeeping info 
around
the block, and needs to keep more bookkeeping info INSIDE the block 
after
its freed [so it can potentially merge with neighboring blocks once they
get freed].

Plus, minimum alignment size on 64-bit cpu is 8 bytes, possibly longer 
if
allocation routines are set up to be "SSE friendly".  SSE and AVX like
accesses to be 128 or 256-byte aligned, and you could set up malloc()
to make the alignment bigger than stock 64 bytes.

Botton line, if you ask for smaller buffers, the system will still round
them up to bigger sizes so you might as well ask for bigger size to 
begin
with, and thus grow your buffer up to that size w/o data movement.


            -- JVZ

[Foxgui-users] FXText setSelection

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

I have an FXText control and I use the following to select all of
the text:

 

 

                // select all

                text->setSelection(0, text->getLength(), false);

 

 

it works fine but what I run "Code Analysis" in MSVS I get the
following warning:

 

 

warning C6385: Reading invalid data from 'this->text':  the
readable size is '8' bytes, but '261864' bytes may be read.

 

 

I get a similar warning:

 

warning C6386: Buffer overrun while writing to '_x_orig[iCurve]':
the writable size is 'numDataPoints*8' bytes, but '16' bytes
might be written.

 

 

With the code below:

 

 

 

                // copy data to local arrays

                for (int iCurve = 0; iCurve < _numCurves;
iCurve++)

                {

                                for (int i = 0; i <
_numDataPoints[iCurve]; i++)

                                {

                                                _x[iCurve][i] =
_x_orig[iCurve][i] = plotDataArray[iCurve].x[i];

                                                _y[iCurve][i] =
_y_orig[iCurve][i] = plotDataArray[iCurve].y[i];

                                }

                }

 

 

 

 

What does this mean?

 

 

 

 

Kind regards,

 

js

Re: [Foxgui-users] [EXTERNAL] Re: Grab observation

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

On 2025-09-04 12:07, Dav...@am... wrote:
> Thanks, Jeroen.  While that’s good to know, on the other hand, on
> Windows, Enter/Leave events will *not* be generated with [un]grab.
> 
> This kind of asymmetry makes it more difficult to implement
> cross-platform controls.  In my perfect world, FOX would handle this
> for me – either FXApp would suppress spurious enter/leave events due
> to [un]grab, or synthesize such events on Windows.  After all, I’m
> writing a control for FOX, not for Xlib or Microsoft.
> 
> But beggars can’t be choosers, so “almost” cross-platform
> control behavior is better than nothing ;)

Yes, problem is we have been relying on X11 [GDI] "state machine"
for keyboard and mouse events.

Its probably better to have internal state-machine and drive it
from external events, and synthesize events which are not provided
by underlying platform.

Needless to say, this is a major undertaking and would probably have
to wait for the FXReactor / FXDispatcher event handling revamp.

     -- 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.

So, some background about the problem:

1) On Linux, we use Xft [XLFD still works, but looks really ugly].  
Fonts
    in Xft can be measured a character at a time, so we can avoid 
overflowing.

    Measuring character at a time was necessary because 
XftTextExtentsUtf8() was
    using a 16-bit short, which overflows too quickly.

2) Due to fixes in FXTextField, we no longer draw invisible text, just 
visible
    text.  Buffer limits or client-server transfer limits less likely to 
be a
    problem.  Of course this should also be faster.

3) On Windows, I've split text measurement and drawing into two 
branches; the fixed-
    buffer version, which lives on the stack, is used for short strings.

    In the rare case we have a large string, we allocate variable size 
buffer and
    use it for the utf8->utf16 conversion, then free it immediately.

    Alloc/free overhead can  be a lot, so we prefer to do it only when 
needed.


Either way, for drawing purposes, strings are transferred between your 
FOX program
and the drawing system [X11 or GDI] and if you have a large string, 
trouble MAY
still ensue.  FOX widgets which may have very long strings [FXText and 
FXTextField]
are now safe against this, since drawing has been limited to the part of 
the text
that's visible, which by definition is much less than the whole screen.
Most other widgets won't have very long strings and should be OK.

I recommend custom widgets that deal with really long strings should be 
looked at
and potentially updated to draw only the visible fragments; this would 
avoid
these problems, and at the same time, significantly speed up drawing.


              -- JVZ

Re: [Foxgui-users] Grab observation

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

On 2025-09-02 15:13, Dav...@am... wrote:
> Hi Jeroen,
> 
> I have an observation wrt the grab function.  When a control calls
> this on Linux (e.g., in response to a left click), LeaveNotify and
> EnterNotify events will be generated when XGrabPointer [1] is called,
> which means that onLeave and onEnter will be called on the control,
> even though the control was already "entered".  This is different
> behavior than on Windows, where no leave/enter sequence will occur.
> 
> In my case, this exposed a bug in my code, so it was a happy
> coincidence.  But I wonder if it would be better to somehow suppress
> these events on Linux or to synthesize them on Windows, so that the
> same call sequence would occur on both platforms from the perspective
> of the control?  This would help to avoid platform-specific bugs when
> writing a new FOX control.

David,

When in response to [un]grab, the FXEvent "code" field will be set to
CROSSINGGRAB or CROSSINGUNGRAB.  Otherwise, this will be set to
CROSSINGNORMAL.

When needed, you can look at this field.

   -- JVZ

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