Hi Treeview :-)
Basically there is no real "wrong" or "right" project structure, it always depends on your needs and especially the project size (feature set, amount of bricks ...).
However, if you have chosen the "best" one for your project, you will be way more efficient.
In a very small project
it makes sense to put everything into one unit, but nicely separated with annotations (which is always a good idea):
In smaller projects
it is recommended to use a simple structure similar to yours:
In bigger projects
you tend to use one unit where you have used "bigger" annotations previously.
Just because you want to keep the overview. Example:
GUI units:
- Application
- Components (e.g. Widgets)
- Screens (e.g. full-screen components that contains several view/widgets)
- Popups (if you have a lot, otherwise could be part of Screens)
- Menu (especially if you have a bigger one)
Resource units:
- Bitmaps
- Fonts
- Colors
- Constants
Data units:
- Data (non visual components, e.g. linked-list implementation)
- Device (everything that belongs to the device interface, communication with "middleware")
- Global (e.g. could contain global helper functions or temp. data)
- Strings
- StringsInstructions... (further String units, because you want to have different Strings Excel files)
Further units:
- Simulation
- Tests
- ...
In big projects
in addition you also make use of "generic" units that are sharable between several projects:
Two things are interesting in the image above:
1. Use a directory for an unit, which can be used as an external (own repository): you fix a bug there and it is fixed for all projects
2. Use the Split: it creates not one ewu file, but one ewu folder with ewui files (now collaboration makes fun again!)
Overall the units should be self-explanatory and as soon as you get frustrated (being inefficient) by scrolling all day long up and down or even searching for something, it is recommended to break this unit down into more: Instead of unit "Settings" -> use unit "SettingsSound", "SettingsVideo" ...
In some projects we even create one unit per feature. This looks good and could make it easier to enable/disable entire features. Apart from that this is really nice if you work with several people on the same project where everyone is responsible for another feature/unit.
Many customers also generate ewu files nowadays. So, not only the String.ewu is generated, but also e.g. an Enum.ewu or an unit with all the data points/bindings. Having one source is the main advantage of the generation (e.g. one Excel file generates an ewu file + header file for middleware). Don't activate the Split here of course :-)
However, please don't start with too many units. I would start with something reasonable and then think about a refactoring of some parts every 20% of the project. For example: At beginning you have one unit "Res" with all Fonts and Bitmaps, later on refactore this to two. Thanks to Embedded Wizards refactoring ability, this takes only some less minutes (re-position bricks), but you will feel way better :-)
Hope this helps a bit :-)
Chris
