I dunno, it'll prolly make a good GUI editor for those who require a GUI editor. I for one am not not sure about all these GUI-editors in the first place. Somehow I don't feel this is how proper apps are being made. One-shot apps perhaps, apps that don't grow too big.. but for large apps otoh I'd usually say a large part of a GUI (if not all) can or should be dynamically created based on whether or not you're using a related component.
It's a different way of thinking. I can only speak for myself ofcourse, but with GUI-builders I usually get the impression one starts with a GUI concept to later fill in the code, while I prefer to start with a functionality concept, no GUI whatsoever. Usually, an app is made out of various smaller parts and each part should have its own private GUI rather than tuning in on a globally designed GUI. Because a private GUI should imho be part of each individual component, you'll get to the point of dynamically generated gadgets, or to a point where it doesn't pay off to use a GUI editor at all. I mean, everyone can type a gadget-create command, right? Gadget-dimensions usually depend on technical limits/properties/functionality rather than human influences or even art! (e.g. where you need a form editor to resize all gadgets until you see the perfect layout)
Now, when every part of the app has its own private functionality and GUI you can assume that every bit and byte is local. If every part has a button to update itself (just assume it), called "Updatebutton" then you can create as many different parts as you like, no interference whatsoever.
When I see all those gadget globals in your source (they're generated output from your form-editor I guess?) then this will create the usual problems with globals if you intend to have similar functions per part. That's why I'd put a GUI into an instance, everything nice 'n private.
Ohwell, perhaps I shouldn't have mentioned it at all.. :P Somewhere I can see how a form-editor can help beginners, esp. if they've no former GUI experience. So, just go on and please them, and ignore my monologue. (orso :P)
It's a different way of thinking. I can only speak for myself ofcourse, but with GUI-builders I usually get the impression one starts with a GUI concept to later fill in the code, while I prefer to start with a functionality concept, no GUI whatsoever. Usually, an app is made out of various smaller parts and each part should have its own private GUI rather than tuning in on a globally designed GUI. Because a private GUI should imho be part of each individual component, you'll get to the point of dynamically generated gadgets, or to a point where it doesn't pay off to use a GUI editor at all. I mean, everyone can type a gadget-create command, right? Gadget-dimensions usually depend on technical limits/properties/functionality rather than human influences or even art! (e.g. where you need a form editor to resize all gadgets until you see the perfect layout)
Now, when every part of the app has its own private functionality and GUI you can assume that every bit and byte is local. If every part has a button to update itself (just assume it), called "Updatebutton" then you can create as many different parts as you like, no interference whatsoever.
When I see all those gadget globals in your source (they're generated output from your form-editor I guess?) then this will create the usual problems with globals if you intend to have similar functions per part. That's why I'd put a GUI into an instance, everything nice 'n private.
Ohwell, perhaps I shouldn't have mentioned it at all.. :P Somewhere I can see how a form-editor can help beginners, esp. if they've no former GUI experience. So, just go on and please them, and ignore my monologue. (orso :P)