I agree!
Having played around with a few of IDE / programming environments / GUI libraries I realize that Servoy’s database-centric design established a “Field is linked to a dataprovider” paradigm, having the “text property available only at design time”. I can’t see the reason why (from a users perspective)!
Actually this paradigm isn’t air-tight. We can link the field to a global variable! If so, why not use it on a form without actually being linked to a dataprovider? This is a bit like having a local variable displayed on a form (more on this later).
I’ve stumbled on this just a few days ago. But, being just a newbie, have been waiting to learn Servoy better. But since you mention this, I must say I agree completly with you Thertzler!
Another issue that I think relates to this is form variables.
Because of this I include the following thoughts.
Why not having form variables (instead of poluting global namespace)?
This way you could even get/set the text property from/to a form variable. I’m aware that we can use
globals.varX = 'example'
in a method without “declaring” the global in the dataproviders list (this is a good thing). But, naturally, the var will live on after the form is closed/destroyed.
It would make sense (for many situations) to have something like:
forms.['form name'].globals.['myVar']
or
forms.['form name'].vars.['myVar']
And the variable would be destroyed after form closing!
One recurrent situation these “variables scoped to a form” would be perfect at is when one is using a global variable to test whether or not the user can exit the current form (compulsive fileds have been filled per example).
After writting this I did a search on the forums (I know I should search first!) and found the same request in a few posts that are worth reading! And learned a little:
http://forum.servoy.com/viewtopic.php?t … baab70880c
http://forum.servoy.com/viewtopic.php?t … baab70880c
http://forum.servoy.com/viewtopic.php?t … ables+form
Still for now I think it makes sense to have locally scoped form vars. instead of assigning null or risking namespace pollution using the same (unlisted as a global provider) global var!
Best,
mjekl