foxgui-users

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

Re: [Foxgui-users] Building latest snapshop

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

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

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

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

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

   -- JVZ

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

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

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

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

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

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

Thanks everyone for the help!

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

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

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

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

libpng-dev is no longer required.

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


    -- JVZ

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

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

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

Hi,

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

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

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

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

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

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

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

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



    -- JVZ