So where can I read about #PB_any and other constants?

[oldefoxx]

i'm at a loss. I suddenly see discussions using #PB_any, and I can't find it in the help file - nor other constants either. Where are you people finding out about all this stuff? The help section is good as far as it goes, but that is the problem -- it does not go far enough on some topics.

[eddy]

Before:

Code: Select all

#ID=1
handle=CreateSOMETHING(#ID)

Now you can do this:

Code: Select all

#ID=1
handle=CreateSOMETHING(#ID)

or:

Code: Select all

ID=CreateSOMETHING(#PB_ANY)
handle=ThingID(ID)

But there's a compatibility problem

[oldefoxx]

Thing is, I still don't know where to get firsthand info on constants such as #PB_any. I don't even know what #PB_any is! Is it some kind of wild card?

[Dare2]

Hi oldefoxx,

#PB_Any generally has some information about it in the statements or commands that support it.

There is also some discussion on it throughout the boards, a search on #PB_Any might yield up some additional information.

#PB_Any provides a way to get a handle or identifier for a thing (gadget, file, etc) and then use that identifier to access the thing. The identifier is dynamically allocated.

IMO it is a good move, and in most cases it is an alternative, the "old method" (using an identifier value via your own constant or literal value) can still be used as well.

Most other #PB constants are covered in the help, they appear in the sections on gadgets, etc, where they are relevant (used as flags or whatever).

Hope that helps.

[HASO]

Oldefoxx,

From website purebasic news:

12th April 2004

PureBasic V3.90 (Windows)

- Added: #PB_Any support (dynamic numbering) for DataBase, File, Font, FileSystem, Gadget, Image,
Library, Module, Movie, Palette, Sprite, Sprite3D, SysTray, ToolBar, StatusBar and Window

I too have not been able to find any direct references to this topic in the help file...

I suppose only #PB_Any exists (not as a constant, but as a feature).

HTH,
Hans.

[Comtois]

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.

The maximum index number is limited to an upper bound, depending of the object type (usually from 5000 to 60000). Enumerations are strongly recommended if you plan to use sequential contants to identify your objects (which is also recommended).
Example 1

CreateImage(0, 640, 480) ; Create an image, the n°0
ResizeImage(0, 320, 240) ; Resize the n°0 image

Example 2

CreateImage(2, 640, 480) ; Create an image, the n°2
ResizeImage(2, 320, 240) ; Resize the n°2 image
CreateImage(2, 800, 800) ; Create a new image in the n°2 index, the old one is automatically free'ed

Example 3

For k = 0 To 9
CreateImage(k, 640, 480) ; Create 10 differents images, numbered from 0 to 9
ResizeImage(k, 320, 240) ; Create a new image in the n°2 index, the old one is automatically free'ed
Next

Example 4

#ImageBackground = 0
#ImageButton = 0

CreateImage(#ImageBackground, 640, 480) ; Create an image (n°0)
ResizeImage(#ImageBackground, 320, 240) ; Resize the background image
CreateImage(#ImageButton , 800, 800) ; Create an image (n°1)



II. Dynamic numbering

Sometimes, indexed numbering isn't very handy to handle dynamic situations where we need to deal with an unknown number of objects. PureBasic provides an easy and complementary way to create objects in a dynamic manner. Both methods (indexed and dynamic) can be used together at the same time without any conflict. To create a dynamic object, you just have to specify the #PB_Any constant instead of the indexed number, and the dynamic number will be returned as result of the function. Then just use this number with the other object functions in the place where you would use an indexed number. This way of object handling can be very useful when used in combination with a linked list, which is also a dynamic way of storage. A complete example of dynamic objects and linked lists can be found here: MDI ImageViewer.pb.
Example

DynamicImage1 = CreateImage(#PB_Any, 640, 480) ; Create a dynamic image
ResizeImage(DynamicImage1, 320, 240) ; Resize the DynamicImage1

[dmoc]

Excuse the hijacking but what's the impact of using high object numbers? I queried this a long time ago and was told if I used say 1000, and nothing before, then a list of 1000 entries would be created, ie, 999 redundant object list entries. I was also told this wouldn't be the case in future, which I assume to mean now that the ANY constant is available.

[oldefoxx]

What you seem to be saying is that #PB_any means that I am not specifying an ID, but rather I am asking the PB Compiler to assign a new ID to the object for me. So if I use #PB_any with an OpenFile() statement, it will return the fileID number for use in other statements.

But apparently this idea of using #PB_any in a universal manner to get an ObjectID has hit a snag with some instructions, as listed above. So I would presume that either the syntax checker will eventually block unacceptable use with an error, or that future revisions of PB will take care of these discrepancies.

Please continue to comment on these thoughts and provide other insights if you will.

[Dare2]

What you seem to be saying is that #PB_any means that I am not specifying an ID, but rather I am asking the PB Compiler to assign a new ID to the object for me. So if I use #PB_any with an OpenFile() statement, it will return the fileID number for use in other statements.

Seems like a good summation.

But apparently this idea of using #PB_any in a universal manner to get an ObjectID has hit a snag with some instructions, as listed above. So I would presume that either the syntax checker will eventually block unacceptable use with an error, or that future revisions of PB will take care of these discrepancies.

Seems like an observation.

Please continue to comment on these thoughts and provide other insights if you will.

Seems like you're setting a class assignment!

(or baiting a hook).


Did you get the answers and clarifications you requested with your original post?

[freak]

But apparently this idea of using #PB_any in a universal manner to get an ObjectID has hit a snag with some instructions, as listed above. So I would presume that either the syntax checker will eventually block unacceptable use with an error, or that future revisions of PB will take care of these discrepancies.

I'm sorry, but I don't quite understand what you talk about there.

Timo

[mdp]

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.

I would like to have some clarification on the 'real' drawbacks, the actual efficiency losses, involved in having a sparse indexing.
Is it just aesthetic
(ie it is 'ugly' to have those 999 unused indexes, but all we lose is 999x4 bytes of memory),
or does it cause slower code etc. ?
(ie perhaps internally we have conditions parsing every index 0..1000, or the OS uses resources on the 999 empty ones etc.)

[blueznl]

as far as i can tell it doesn't matter