Currently, the project handles all GUI control state management and rendering within a single monolithic file: InForm.ui. This design leads to duplicated control logic across different sections of the file, making the codebase harder to maintain, debug, and extend.
To improve modularity and maintainability, we should refactor the control logic into separate files, each dedicated to a specific control type. The InForm.ui file will remain, but its role will be limited to housing generic logic that doesn't belong to any specific control and to including headers or modules for individual controls.
For example:
InForm.ui
├── TextBox.bm
├── ListBox.bm
├── Button.bm
└── ...
Each .bm file will encapsulate the logic and rendering for its respective control, reducing duplication and improving clarity.
Currently, the project handles all GUI control state management and rendering within a single monolithic file:
InForm.ui. This design leads to duplicated control logic across different sections of the file, making the codebase harder to maintain, debug, and extend.To improve modularity and maintainability, we should refactor the control logic into separate files, each dedicated to a specific control type. The
InForm.uifile will remain, but its role will be limited to housing generic logic that doesn't belong to any specific control and to including headers or modules for individual controls.For example:
Each
.bmfile will encapsulate the logic and rendering for its respective control, reducing duplication and improving clarity.