#PB_Compiler_EnumerationValue

[IdeasVacuum]

The form designer appends an Enumeration list with the flag #PB_Compiler_EnumerationValue.

I hadn't come across this flag before and potentially have hit an issue with it:

Code: Select all

[ERROR] #Image object number is very high (over 100000), are You sure of that ?

The error is referring to constant number 14 in an Enumeration of 69

[TI-994A]

The form designer appends an Enumeration list with the flag #PB_Compiler_EnumerationValue.
I hadn't come across this flag before and potentially have hit an issue with it:

Code: Select all

[ERROR] #Image object number is very high (over 100000), are You sure of that ?

Hi IdeasVacuum. As you know, the #PB_Compiler_EnumerationValue is a continuity flag to chain constant enumerations from a previous block. Perhaps you could check the assigned constant values with Debug, or post the Enumeration block here for us to counter check on other versions/platforms.

Thanks.

[jassing]

The form designer appends an Enumeration list with the flag #PB_Compiler_EnumerationValue.
I hadn't come across this flag before and potentially have hit an issue with it:

Code: Select all

[ERROR] #Image object number is very high (over 100000), are You sure of that ?

Hi IdeasVacuum. As you know, the #PB_Compiler_EnumerationValue is a continuity flag to chain constant enumerations from a previous block. Perhaps you could check the assigned constant values with Debug, or post the Enumeration block here for us to counter check on other versions/platforms.

Thanks.

Is there a way to get the last value? Let's suppose you're using a form designer and you get:

Enumeration ; Gadgets
#text1
#string1
#progressbar
endenumeration

Then later, you want to 'continue' the gadget list, but had other enumerations in between -- is there a way to say "Continue Gadget Enumerations"

[IdeasVacuum]

#PB_Compiler_EnumerationValue is a continuity flag to chain constant enumerations from a previous block

I didn't know that, but if that is the case, perhaps it shouldn't be assigned to an Enumeration block if there is only one block? Any how, I simply removed the flag and all is well.

[Polo]

This flag is very important when your project includes several .pbf files, as well as code that use enumeration as well, so that there are no duplicates.

[ts-soft]

@Polo

but is not the best way. Numerates all objectstypes in one, this waste memory.

[Polo]

@Polo

but is not the best way. Numerates all objectstypes in one, this waste memory.

I can't think of a better way, though.

[ts-soft]

Creation of more than one window per source could help, or the option to merge some
designerfiles, to make a one output.

[nospam]

this waste memory.

Seriously, with the amount of memory available on machines sold in the last decade, and considering that all mainstrean OSen released in that time, have large anounts of memory and support paging, is wasting small amounts of memory for efficiency's sake really a problem?

[Polo]

Creation of more than one window per source could help, or the option to merge some
designerfiles, to make a one output.

No, as it will still duplicate with the constant created outside .pbf files.
As nospam said I don't think there's so much memory wasted, too!

[ts-soft]

If i create a window with 100 gadgets and 50 picture, the second windows
requires memory for 151 windowobjects in the list.

And if you use the constant for the first enumeration and i have a large enumeration before
...

Memory is not a big problem, but i do not like to waste it useless

I think, it is a good idea to find another solution.

Greetings - Thomas

[Polo]

I think, it is a good idea to find another solution.

Please do! There's no other solutions that will take into account previously created gadget constants

[ts-soft]

simple add a export function to merging all open designs, enumerations outside should not have any sideeffect, if the don`t used for windows, gadgets or images.

If i have to change it by hand, i can never enhance the form at a later time

[Demivec]

Creation of more than one window per source could help, or the option to merge some
designerfiles, to make a one output.

No, as it will still duplicate with the constant created outside .pbf files.
As nospam said I don't think there's so much memory wasted, too!

The enumerations are listed in the order of windows, gadgets, menu items, images, fonts. I have an application with 31 windows, 633 gadgets, 23 images, 180 menus, and 6 fonts. If I add one more window with a menu, an ImageGadget and a TextGadget, with the way you have set up the enumerations would mean that I would be using resources for 874 windows 877 gadgets, 878 menus, 879 images, and 880 fonts. That's a total of 4388 PB resources instead of 878. That means you are wasting memory resources exponentially not linearly.

Fred's advice is that it is better to avoid doing this.

You have to group the enum per object type for optimal performance: ie, one enum for window, one for gadget, one for toolbar etc. Using only one enum for every object will lead to holes into the internal arrays for each objects.

You put evety different object in the same enumeration. While it does work, on a big program it can be unefficient. Better use an enum per object type (one for Menu, Gadget, Window etc.). Each PB library has it's own object range.

When windows are designed for a project and they are going to be included together I would think that you could include the separate enumerations for gadgets for instance into a single enumeration. Another way that would keep the enumerations grouped separately is to simply start each enumeration with a literal value representing the count of all the previous enumerations of the same type (i.e. Enumeration 0; Enumeration 6; Enumeration 22, etc.). If the worry is that the source code for a window won't be included as part of a group then a tool that would look over the source and make modifications may help.

Freak suggested an option using macros but I think it would fall in the category of having to be customized also.


The link above is in a thread for a feature request for named enumerations. Fred said it was a good idea but we are still waiting since 2004

This is a situation that cries out for named enumerations.

[Polo]

I get your point, but still don't see a better way to do it.
If I use enumeration for windows/gadgets before including a .pbf file then it won't work if I don't add the flag.