Eros,
this looks really great, it would be big help in form intensive applications. The controls are intuitive, I like it very much!
My mind is already full of wild ideas:
Visual designer itself
- add support for RESIZE of controls (anchors)
- use Begin ControlID/End ControlID blocks in generated code for equates
- add option to generate code for dialog, which is not in TBMain (code for secondary dialog, for example to be placed to other thinBASIC Unit)
- add help label to the form, where you pick the styles - beginners are usually not familiar with Win32 styles
- something to think about - preserve style definition using Win32 styles, or go the route of "general" styles implemented via Win32 behind the curtains?
- define the format of forms in XML -> possible use by modules, see below
Module related to visual designer - classic conservative approach
- ability to save/load the forms from XML(or other format) to script.
So something like hDlg = Module_CreateForm( sPathToFile )
The benefit is that the code does get simpler, without 100 lines of dialog definition - the equates could be then defined from module via thinBASIC_AddEquate without need to be explicitly named in code
Module related to visual designer - OOP style
As ThinBASIC modules in 1.9.0.0 will have great power, I think it would be possible to design standalone module, allowing to handle forms via OOPish syntax. Imagine:
DIM myForm AS TBForm = new TBForm("Form1.bin") ' -- Constructor loads the form definition from file
myForm.ShowModal( EventProcedure ) ' -- Classic method call, passes callback function name as parameter, invokable internally using thinBasic_FunctionSimpleCall_ByPtr
...
myForm.Edit1.Text = "Hello" ' -- Now this is a bit more complex, but not that much - each control has its equate stored in the definition file, so via the approach which is used for method chains in Betas, when I find symbol, which is not method, I look if it is not name of the control (based on loaded data), and then behave accordingly
Petr
Bookmarks