Ability to use more than 1 form (non-conflicting)
Posted: Mon Aug 17, 2015 6:21 am
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:
Form2.PBF:
... 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:
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?

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
Code: Select all
Enumeration FormGadget
#Form2Edit1
#Form2Edit2
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
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?
