Looking at the examples … I see how to create several forms within my app. Usually … I create each new form on the same “level” as my start-up form. Then I follow the import rules so the main form can refer to the attributes and namespace of the other forms.
Here’s my question … when I create a new form as “sub-form” of the main form … I get all kinds of error messages. The system cant find the subform. I thought the subform became an attribute of the main form … but anvil doesn’t like that.
I may be using the wrong dot syntax, or incorrect import statements. But I cant seem to access the attributes to read/write attributes of the subform.
So I have learned to avoid this trap by making all forms on the same level.
Q: Why does anvil let me define a form as a subform of the main form?
What feature, or situation, or syntax is appropriate when I create a subform?
Why does the system let me do this? When should I create a subform of a form - instead of a a new form on the same level as the main form?
Just never do that ? or only do that when …?
and what is the syntax, or import protocol, to make it work?
When I “create” or “add” a new form as sub-form of the main form … what is the syntax or import code to manipulate …i.e. read/write attributes of the sub-form? From the docs it seems the sub-form is an attribute of the main fiorm … an attribute which is itself an object. But the syntax mainform.subform - which works with other main form attributes … doesn’t seem to work.
I know how to create a form … and then make it appear as a subform … but why does Anvil let me make a sub-form if I cant address it?
I think you may be confusing two different hierarchies. Referring to the diagram here:
The area labelled “5” gives you a visual rendering of your current form, and the objects that it initially contains.
To see its substructure, its hierarchy, click the pull-down list labelled “8”. There you will see the physical structure of your Form, as displayed visually in area “5”.
This has nothing to do with the area labelled “1”. In spite of it being prominently displayed next to area “5”, area “1” is purely a filing system. You can define what you call “subforms” here, and never use them. There is no (automatic) correspondence with the contents of area “5”.
This page goes into considerable detail as to how to
Add components to your Form (including other Forms)
Refer to those components in your code.
This topic covers overall project structure, and using import within that structure.
For taking the time to explain all this. I will double down on the doc sections you mention.
The heart of my confusion was when using the section labeled (1) in your diagram.
If you press the + next to “client code” you can add a form
to the project - which appears at the same level as Form1.
But if you press the down triangle right next to the Form1 title …
You have the option to add a new form, below Form1 - which then
seems to appear as a sub-object of Form1 - at a level below Form1 ?
I now avoid doing this now, since I can’t seem to figure why I would create the new form here.
Plus, I can get the result I want - adding the new form as a component of Form1 - in code
and by following the other examples in the doc.
I just wondered whether there was some situation it was useful to create a new form in this alternative way? Maybe I have read the docs without really understanding. Again Thanks. Onward.
Imagine that you have a Module X that will only, ever be used by Module Y. Then you might locate X “underneath” Y, simply to help organize your files, and make the top-level less cluttered.
Many installable Python libraries (packages of modules) are organized in exactly this fashion. It works very well with Python’s import machinery. This is one reason why Anvil adopted it as the default for new projects: it was familiar to many desktop Python app developers.
The same organization can be applied to Forms. One recurring pattern is that a Form uses a DataGrid, which uses a RepeatingPanel, which uses Custom Components, which are built out of Forms… It’s very handy to keep these inter-dependent files close together, outline fashion, where one can hide them when you’re looking at something else.
I have an old app that pre-dates this hierarchical structure, with literally hundreds of files. They’re all at the top level, because that is the only level that existed at the time. In this list, closely-related files are often very far apart, and can be hard to find.
I see your point. I need to learn more about “Python’s import machinery” which I fear is another hole in my knowledge. It’s a simple case to load a Standard Library module. But more attention is required with packages and sub packages. You have left me a cookie trail of hints. Yet again thanks.