#PB_ANY for MenuItem

Shannara · Post by **Shannara** » Mon Oct 18, 2004 7:29 pm

However, enumerations are worthless for what you previously mentioned. You still have to hard code the constants to be enumerated. Which effectively limits your "visual designer" software to a hard coded number, which is... useless

The reason for #PB_ANY for menuitem is for people like us creating visual designers and the like (as well as skin makers). The user can create how ever many number of menu items w/o having to worry about clashes and errors.

My visual designer creates dynamic code, as it assumes people wants to be able to easily extend the code w/o being statically limited by enumerations, and the like.

Every time I end up creating a forum or any kind of project with PV, I end up spending another 30mins to 1 hour fixing up the generated code to be dynamic.

I guess it could be considered a matter of taste. But for most of the projects I work on, requires to be easily extensable after a certain amount of time, so why not have that support in from th beginning?

Paul · Post by **Paul** » Mon Oct 18, 2004 8:35 pm

Every time I end up creating a forum or any kind of project with PV, I end up spending another 30mins to 1 hour fixing up the generated code to be dynamic.

Hmm, we have written quite a number of professional commercial applications using PV and PB and have never been limited by the code produced. In fact it has allowed us more flexability than anything, not to mention the huge speed increase in the design process!

I guess difference here is the coding skills and knowledge

Shannara · Post by **Shannara** » Mon Oct 18, 2004 8:59 pm

exactly

blueznl · Post by **blueznl** » Mon Oct 18, 2004 9:04 pm

i'm totally in the enumeration camp... shanarra, could you give an example? (or did i overlook it?)

Shannara · Post by **Shannara** » Mon Oct 18, 2004 9:35 pm

Ok, an exerpt from a visual designer (the same situation applies to all scripting applications).. (Please note, this is for all use of #PB_ANY and not just menu items, even though it certainly applies here!)

With enumerations, I would need to set aside so many place holders and hope that this will not over flow or be under used (impossible). So I set asside 100 enumerations just for "dynamic" controls needed for designing.

Code: Select all

  Enumeration
    #MaybeUse0 ; Will be 0
    #MaybeUse1 ; Will be 1
    #MaybeUse2   ; Will be 2
    .....
    #MaybeUse100
  EndEnumeration

Now with any wide spread, professional commercial application, 100 gadgets will not be enough (luckily, we have a partial implimentation of #PB_ANY available to fix this problem). Now with the problem above, we must first type out each and every single constant to use. For dynamic reasons, enumerations are worthless, as you must GUESS how many # of enumerations the user (or scripter, or designer, etc) will use, effectively either creating a hard cap on how many they can use, OR wasting memory & hard drive space (application bloat).

The dynamic use of #PB_ANY actually prevents bloat

Back to the issue. Not only do you have to create tons of enumerations, you must also reference these constants individually through out the code. It can be a painfull experience to say the least.

With the use of #PB_ANY... you can use the following

Code: Select all

Structure strDynGadget
DynGadget.l
EndStructure

Newlist DynGadget.strDynGadget()

AddElement(DynGadget())
DynGadget()\DynGadget = ButtonGadget(#PB_ANY, 10, 10, 200, 20, "Standard Button")

Want to look it up? Grab it from the link list. This is 100% dynamic. No bloat, no wasted hard drive space, nor ram. This is all a consideration when creating commercial software. If there was two programs, one coded the old way (enumerations), and one coded the #PB_ANY way, and they both do the same thing, except the old way inheritally uses way more resources. Which one would you choose? Commercially? Regular users usually dont care about these things, but companies do.

blueznl · Post by **blueznl** » Mon Oct 18, 2004 10:44 pm

well, i'm not so sure more resources are actually used, to be honest

constants are only inserted when used

the current solution indeed has the problem that external (include) files may use the same numbers for gadgets as your main code

on the other hand, how difficult is it to write a 'unique id' procedure that returns unique / free numbers?

so codewise it could be easily circumvented, perhaps slightly less comfortable, but still...

or am i suffering from a lack of sleep and too much farscape?

Paul · Post by **Paul** » Mon Oct 18, 2004 11:59 pm

LOL @ Shanarra !!!

After seeing your logic and how you assume things must work, I can better understand why you have such a hard time coding.

Enjoy

Shannara · Post by **Shannara** » Tue Oct 19, 2004 5:10 am

Heh, well, at first I thought you accidently mispelled my name, but seeing how you have done it twice now... insulting me on purpose?

As for assuming how things work... what are you talking about? I know its not in the commercial aspect, been there done that. As for the coding part.. I use the PB manual...if that is wrong.. how about you enlighten us concerning your assumption of me assuming...

Seymour Clufley · Post by **Seymour Clufley** » Sat Feb 16, 2008 10:16 pm

I know this is an old thread but I really want #PB_Any for the MenuItem command, so just adding my voice. :