Ability to use more than 1 form (non-conflicting)

[Keya]

I love the Visual Designer but it seems useless for creating an app with more than one re-editable form due to various conflicts. And unless you're creating an extremely tiny app you need more than one form.

The main reason is because when you create another form everything created with it conflicts with other forms... for example, if you create Form1 and Form2, each with two editor controls (Form1Edit1 & Form1Edit2, and Form2Edit1 & Form2Edit2), it results in the following::

Form1.PBF:

Code: Select all

Enumeration FormGadget
 #Form1Edit1
 #Form1Edit2

Form2.PBF:

Code: Select all

Enumeration FormGadget
 #Form2Edit1
 #Form2Edit2

... both #Form2Edit1 and #Form1Edit1 = 0, and both #Form2Edit2 and #Form1Edit2 are both = 1 ... so we can't actually use #Form1Edit2 or #Form2Edit2 at all due to the conflict.

You can use #PB_Any instead and have them all as Globals, but then you can't do things like "FOR i = #Control1 TO #Control9" (very important when you have 'arrays' of controls), because as i found out the order isn't guaranteed like it is in Enumeration. That doesn't address the actual conflict though anyway.

The same is also true with Menus... you can't have a menu on a second form, because it just corrupts/conflicts with the menu on the first form. And for example, both Form1 and Form2 have IDE-generated "Enumeration FormMenu", where "FormMenu" is never unique... whereas it actually must be unique per form.

I know you can save PBF files to PB files and then modify them (basically going against the one main "rule" of PBFs), but you then cannot take it back to the Visual Designer later because it will simply overwrite all your changes.

SUGGESTION #1:
I don't know what the best solution is, but one seemingly easy-to-implement solution would be to have the Form Designer REMEMBER THE BASE of Enumerations.

For example:

Code: Select all

Enumeration FormGadget 200
 #Form1Edit1
 #Form1Edit2

In this case I've based all controls on the form from 200 instead of 0 - great, conflict resolved!
And that would essentially fix the problem ... BUT the only problem is that when you currently switch back and forth from Code<>Design view it forgets the Enumeration base (200 in this case), defaulting it back to 0.

SUGGESTION #2:
In regards to "FormGadget" and "FormMenu" not having a unqiue name, it seems an easy solution is "Enumeration <FormVariableName>_FormGadget" ?

So Fred I hope you'll consider this, and maybe you have better solutions, but it seems like one heck of a limitation at the moment! ... yet with a possibly very simple solution? or have i just got it all wrong?

[Demivec]

... both #Form2Edit1 and #Form1Edit1 = 0, and both #Form2Edit2 and #Form1Edit2 are both = 1 ... so we can't actually use #Form1Edit2 or #Form2Edit2 at all due to the conflict.

This doesn't actually work this way with named enumerations.

Code: Select all

;Form1.PBF
Enumeration FormGadget
 #Form1Edit1
 #Form1Edit2
EndEnumeration

;Form2.PBF:
Enumeration FormGadget
 #Form2Edit1
 #Form2Edit2
EndEnumeration

Debug #Form1Edit1 ;displays 0
Debug #Form1Edit2 ;displays 1
Debug #Form2Edit1 ;displays 2
Debug #Form2Edit2 ;displays 3

[Fred]

I don't think it's true. We use named enumeration, so it will not be the same number as the enumeration continue:

Code: Select all

Enumeration FormGadget
 #Form1Edit1
 #Form1Edit2
EndEnumeration
 
Enumeration FormGadget
 #Form2Edit1
 #Form2Edit2
EndEnumeration

Debug #Form1Edit1
Debug #Form1Edit2
Debug #Form2Edit1
Debug #Form2Edit2

edit: too slow

[Keya]

Thankyou for explanation and please forgive me for my oversight!
Part of the reason im a bit confused is because I thought all enumerations without a specified base were always base=0, the "named enumerations" thing is new to me - back to the helpfile i go heehee

But what about Menus? http://www.purebasic.fr/english/viewtop ... 13&t=62778