Undependeable Gadget Handle
Re: Undependeable Gadget Handle
It's a good idea, I modified the permissions, it should now work with the link.
Re: Undependeable Gadget Handle
Very nice, thank you Fred ! 

"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
-
- Always Here
- Posts: 6426
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: Undependeable Gadget Handle
That is a geat idea 

IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
Re: Undependeable Gadget Handle
Thank you.Fred wrote:It's a good idea, I modified the permissions, it should now work with the link.
Is this new 32k-limit true only for ScrollAreaGadget?Fred wrote:I tried on OS X and it works for 32k as well, so I raised to limit to that.

Re: Undependeable Gadget Handle
for all gadgets
Re: Undependeable Gadget Handle
So a CanvasGadget can have up to 32kx32k as long as theFred wrote:for all gadgets
mentioned 2GB limit is not hit and has always a trustable handle?

Re: Undependeable Gadget Handle
Should be.
Re: Undependeable Gadget Handle
That sounds great!Fred wrote:Should be.

May I ask what the reason was why it didn't work before?

Re: Undependeable Gadget Handle
Hi Fred!
How do you define 32k?
In my opinion it should be 32768 or $8000.
It looks like you defined 32767 or $7FFF.
Why? Is it because a ScrollAresGadget is
limited to 32767 by Windows for what ever
the reason is for that? You know, a Canvas
can have 32768 width without problems.
A nice feature is now, if you disable Debugger, you can
really test wether a Canvas was succsessful created or
not. If a handle is delieverd, the Canvas is useable. Even
if you start with 65536 down to what ever your memory
allows.
Thanks for this "bugfix" in LTS 5.21b1.
Lord wrote:...Is this new 32k-limit true only for ScrollAreaGadget?Fred wrote:I tried on OS X and it works for 32k as well, so I raised to limit to that.
Lord wrote:So a CanvasGadget can have up to 32kx32k as long as theFred wrote:for all gadgets
mentioned 2GB limit is not hit and has always a trustable handle?
May I ask another question?Fred wrote:Should be.
How do you define 32k?
In my opinion it should be 32768 or $8000.
It looks like you defined 32767 or $7FFF.
Why? Is it because a ScrollAresGadget is
limited to 32767 by Windows for what ever
the reason is for that? You know, a Canvas
can have 32768 width without problems.
A nice feature is now, if you disable Debugger, you can
really test wether a Canvas was succsessful created or
not. If a handle is delieverd, the Canvas is useable. Even
if you start with 65536 down to what ever your memory
allows.
Thanks for this "bugfix" in LTS 5.21b1.

Re: Undependeable Gadget Handle
The question above is still not answered, even after PureBasic 5.21 LTS.

Re: Undependeable Gadget Handle
Yes, it's $7FFF
Re: Undependeable Gadget Handle
Usually, word limited range is from 0 to $7FFF (32768 values), that's why we set this maximum value, for consitency. It's a PB limit, and if you want to remove it, just disable the debugger.
Re: Undependeable Gadget Handle
I don't see an consistency here.Fred wrote:Usually, word limited range is from 0 to $7FFF (32768 values), that's why we set this maximum value, for consitency. It's a PB limit, and if you want to remove it, just disable the debugger.
If it should be consistent, you should also set the limits
for color to 254, 254, 254. That would be a range of 255 ($FF).
And it is also inconsistent to a CanvasGadget with its $ 3E80
limits.
Another example: CatchImage works for 8192x8192 ($2000x$2000)
from 0 to 8191 ($1FFFF)
I think it should be the other way around:
Range = $8000 (32768), Limits: 0 and $7FFF (32767)
[also for Canvas ($4000, 0 to $3FFF), but this is another story]
So you can keep color settings from 0 to $FF (Range of $100)
for consistency.
