Is there a way to increase the 10,000 gadget limit?

[alban]

Is there a way to increase the 10,000 gadget limit?

To explain: Its not that I have 10,000 actual gadgets, but I do have an application where I would like to use the gadget numbers sparsely to find the gadget that someone has clicked on. In the application I display a number of tabs with a scroll view containing a number of components. Each component is composed of 16 gadgets, I might have up to 16 components on a tab, I may have up to 32 tabs in the application.
This is working fine but it is running close to the 10,000 gadget limit.
The tabs are using 8192 potential gadget IDs without considering all the other gadgets that the application needs and without being able to expand the application very much.
In the event loop I use the gadget id number to locate the tab and the component that the user has just clicked on - this is the main reason I want to use specific numbers for the gadgets.

[Flype]

hi,

where did you see this '10 000' limit ?

i don't think there's such a limit in the Gadget Lib.

[Foz]

Is this the windows limitation you are referring to? 10,000 is the maximum number of GDI Objects that can be created and maintained by one app at any time.

I believe (and this will have to be checked) if you are not displaying them, then they don't count.

[alban]

No it is a purebasic compiler limit
The purebasic compiler displays an error message when you use a gadgetID greater than 10,000.
To see it do this:-

Code: Select all

; 
If OpenWindow(0, 0, 0, 230, 90, "Event handling example...", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)

   If CreateGadgetList(WindowID(0))
     ButtonGadget  (10001, 10, 10, 200, 30, "Click me")
   EndIf

   Repeat
     Event = WaitWindowEvent()
   Until Event = #PB_Event_CloseWindow
 EndIf

[Foz]

Ah, probably enforced by the compiler because of the windows limitation.

[Sparkie]

...find the gadget that someone has clicked on.

Maybe I'm still out to lunch, but how about using EventGadget() and EventType() to accomplish this task

[freak]

It is the debugger which displays this message. Its actually not a hard limit.

The IDs are allocated in an array, so using them sparsely is a waste of memory.
For such things, using #PB_Any to get a dynamic ID is probably the better solution.

[alban]

Thanks very much everyone for your help; that makes sense Freak, I assumed that the debugger warning was a fatal message when I encountered it in a real program that I was debugging, and I did some work to pair things down to fit into that limit.
I am using GadgetEvent() Sparkie its just that at the moment I get the x,y position (in my data) and the gadget number out of the gadget id that it returns. Now I know these IDs are using an array internally - I can gain some memory back by doing things another way.

[ABBKlaus]

The limit for such objects is 18.000 (per process)
http://msdn.microsoft.com/en-us/library ... S.85).aspx

[graves]

The IDs are allocated in an array, so using them sparsely is a waste of memory.

How many, exactly?.
It isn't the same thing 4 bytes (a pointer), or 1000 bytes (a fixed length structure), by every unused gadget.

I'm using gadgets from 1000 to 9999 and I like to know if I need to change my programs to reduce memory used.

EDIT:
Is this valid for the rest of objects?... as images, menus, shortcuts...

[Trond]

Yes, it's valid for images and other things as well.

PureBasic objects

Introduction

The purpose of this section is to describe the behaviour, creation, and handling of objects in PureBasic. For the demonstration, we will use the Image object, but the same logic applies to all other PureBasic objects. When creating an Image object, we can do it in two ways: indexed and dynamic.

I. Indexed numbering

The static, indexed way, allows you to reference an object by a predefined numeric value. The first available index number is 0 and subsequent indexes are allocated sequentially. This means that if you use the number 0 and then the number 1000, 1001 indexes will be allocated and 999 (from 1 to 999) will be unused, which is not an efficient way to use indexed objects. If you need a more flexible method, use the dynamic way of allocating objects, as described in section II. The indexed way offers several advantages:

- Easier handling, since no variables or arrays are required.
- 'Group' processing, without the need to use an intermediate array.
- Use the object in procedures without declaring anything in global (if using a constant or a number).
- An object that is associated with an index is automatically freed when re-using that index.

[graves]

Thanks, Trond

Unfortunately, I NEED static index on objects. Thus I will change my programs to reduce their index number.

[freak]

Its not that much actually. Currently every gadget takes up 32bytes, so if you start at 1000, you have 32k of unused memory.
Its the same for other object types. Every entry takes the space of a small data structure.

[Micko]

Its not that much actually. Currently every gadget takes up 32bytes, so if you start at 1000, you have 32k of unused memory.
Its the same for other object types. Every entry takes the space of a small data structure.

very clear
so it's recommend to use Enumeration /EndEnumeration or PB_Any i mean ?

[Seldon]

The IDs are allocated in an array, so using them sparsely is a waste of memory.

What do you mean exactly ?? If I do something like this:

Code: Select all

#ID_GADGET=2000
ButtonGadget(#ID_GADGET,9,9,33,33,"Button",#PB_Button_Toggle)

Does PB create an arrary of 2000 elements although I only use one gadget ?