PureBasic Forums - English

Tiny issue.

If you have a Gadget number that is deemed to be high, the compiler halts with an error message:

Error #Gadget object number is very high (over 10000) are You sure of that?

Certainly will be times when the developers answer to that question is 'yes'.

It would be much better to report (a) the actual gadget number and (b) the maximum number allowed.

Certainly will be times when the developers answer to that question is 'yes'.

Why would anyone want to create 10000 gadgets?

I recollect getting a similar problem when using the debugger - except it was a warning, not an error - when the gadget number I was using had been 'generated' by #PB_Any. I changed my code to use my own gadget numbers.

Why would anyone want to create 10000 gadgets?

No doubt somebody will, but it's not about the actual quantity of gadgets, its about using 'smart' Gadget ID systems where inter-related gadgets are recorded as such by their ID being a member of a number group.

Hey!

I'd recommend using the #PB_Any feature.
You can group your gadget "numbers" in Linked Lists or arrays or some other data structures,
which are perfectly if you need to iterate through them and when you are
going to create them dynamically.

First I always used "hardcoded" Gadget IDs and it worked OK, but at some point
when you get a lot of other Gadgets and Windows, it's just going to be confusing
and I also got that error because I tried to do it in a smart way.

IdeasVacuum wrote:

Why would anyone want to create 10000 gadgets?

No doubt somebody will [...]

Hehe, 10k Gadgets would be quite the overkill.
IIRC, there is a window / control limit set by Windows (and probably other operating systems, too).
I don't think you're actually allowed to create that many controls.


Greetings

IdeasVacuum wrote:

Why would anyone want to create 10000 gadgets?

No doubt somebody will, but it's not about the actual quantity of gadgets, its about using 'smart' Gadget ID systems where inter-related gadgets are recorded as such by their ID being a member of a number group.

Don't do that. All the unused numbers in-between are still allocated, so you're wasting a ton of memory.

Don't do that. All the unused numbers in-between are still allocated, so you're wasting a ton of memory.

That seems strange, why are unspecified IDs allocated?

Because apparently PureBasic creates an array to hold all Gadget numbers,
no matter if they are actually used or not.

http://www.purebasic.com/documentation/reference/handles.html wrote: Handles and Numbers
Also, most of the functions that create these objects also return this handle as a result, if they were successful. This is only the case if #PB_Any was not used to create the object. If #PB_Any is used, these commands return the object number that was assigned by PB for them, not the handle.

I use #PB_Any almost always, but don't understand the difference between object numbers assigned automatically vs those assigned by a user constant?

Why is more memory consumed when a user assigns an arbitrary constant of 10000 for a gadget?
Yet, the #PB_Any object number is just as high?
Couldn't the compiler just sort and reassign constants to eliminate gaps?
I assume the use of #PB_Any is not wasting memory.

The #PB_Any numbers are direct pointers to memory. While the normal numbers are indexes in an array.

Documented in PB-Helpfile
In Overview under "Various Topics" click on "PureBasic objects overview"

MFG PMV

skywalk wrote: I use #PB_Any almost always, but don't understand the difference between object numbers assigned automatically vs those assigned by a user constant?

As Trond pointed out correctly, #PB_Any values are actually pointers that store the necessary information about the gadgets, the OS handle for example.

skywalk wrote: Why is more memory consumed when a user assigns an arbitrary constant of 10000 for a gadget?

I just said that one post above yours. PB allocates an array with (at least) the size of the largest gadget number.
If you're creating a gadget with the ID 10'000, PB creates an array with the size of 10'000 fields and stores the information about
that gadget at position 10'000 in order to directly access them. All the other elements are empty until you create gadgets with those numbers.
(If that's not what PB does, please tell me).

skywalk wrote: Yet, the #PB_Any object number is just as high?
Couldn't the compiler just sort and reassign constants to eliminate gaps?

Sure the gadget list could be optimized for size but that would prevent PB from directly accessing the information
via the array index and thus slow down the process of acquiring that information since the correct number has to be searched.
Although I think that would be a more efficient way...but then again you could just use #PB_Any which is way more flexible anyway.

skywalk wrote: I assume the use of #PB_Any is not wasting memory.

Nope. If you use #PB_Any, PB can access the information directly since it is a pointer.

There are times I think when PB_Any is going to complicate matters too much in the code. So, my approach will now ensure my code is 'ID array aware' and reduce logical numbering. Not a huge sacrifice, just that I like to keep my code minimal and as easy as possible for me to understand if I have to go back to it months or years later

Thanks Shield, I saw your earlier post after mine.

@IdeasVacuum, I actually find the enumerated gadgets harder to deal with, unless it is a very small app/utility. Otherwise, I have a structured array of all my windows/gadgets/menus/etc. and the properties I automate.
With AutoComplete and the '\' key, the properties jump right out so there's not much to remember.