class dDesignerMixin:
"""
The purpose of this mixin class is to add the features to the native
controls so that they will work in the dabo form design surface.
"""
stdProps = {
"wxButton": {
"name" : "",
"label" : "",
"default": False
I was twiddling with the thought of making a PropertyMixin for both
designtime and runtime, for all the properties anyone would care about.
Top, left, width, height, name, baseclass, parentclass, enabled, etc.
etc. At designtime, you'd be interacting with the dControls and not wx
controls, and setting the properties as we define them. Setting Top=13
would do a behind-the-scenes SetPosition((-1,13)), etc.
So the design-time editor would be reading from and saving to actual
python files that represent the class being edited. The property mixin
would handle loading/saving the properties to the class for proper
behavior both at runtime and designtime. We'd just define a section
of the file that is semi-reserved, such as:
class txtLastName(dTextBox):
...
def dabo_properties(self):
return {"Top": 13, ... ...}
Somewhere in the init phase at runtime, we'd run through the property
list and where the control knows how to take action (it recognizes the
property) it would do the right thing. Also, user code could say things like
"self.Top = 13" and Dabo would do the "self.SetPosition()" code.
The more I think about this, the more I believe that we don't need
intermediary XML files. We will need conventions for defining things like
containership and parent classes. In VFP, if you put a command button
on a form, and edit the click() method, you are actually editing a method
of the form, named command1.click. We'd want to have similar functionality
with Dabo, I think.
So in the Dabo Designer, you get to choose which class to edit, or to make
a new class. A class can be any subclass of any of the dControls (dForm,
dTextBox, etc.) A container class (dForm, dPanel, dPageFrame, dPage) can
hold any other relevant dControl, but it merely becomes a child of the parent
container and any PEM's get assigned to the container.
For instance, say I have a dForm, to which I add an empty dPanel subclass.
I then put a textbox inside that dPanel. While the textbox's runtime parent
will be the dPanel, any code defining dTextBox will happen at the dForm
level. The alternative would be to separately define that dPanel subclass,
and then in the blank dForm add the already populated dPanel.
I'm babbling, not making much sense. Choose to ignore if you wish. :)
--
Paul
©2004 Paul McNett |
