On Mar 8, 2007, at 11:24 AM, womble wrote:
> * Error messages- go to stdout/stderr of terminal, rather than
> being displayed in a form.
> This is confusing:
> - is it my app, or the tool that's having problems
> - different than when you 'run' your form and bring up the
> dShell, where errors/output, etc are displayed as part of the
> dShell form.
Messages are written anywhere you like; by default they go to stdout/
stderr. You can set the LogObject of dabo.infoLog and/or
dabo.errorLog to any object you want, so long as it has a write()
method.
As mentioned before, it is likely that an IDE would have its own
output window for such messages, as does the Command Window.
For fun, run a form and open the Command Window. Right-click on the
interpreter area (top half), and select 'Unsplit'. Now type something
like 'print 7' - note that the output is not inline with the
interpreter commands. Now rclick again, and select 'Split'. The
output area returns, and output is once again directed there.
> * Autoadds KeyField definition for bizObj even if no PK in table
> (good), but should add a comment that this needs to be defined.
> (I'm no db expert, but even I recognise it's better to have a PK...
> but I didn't design the db I have to work with ;-) )
This is a bit more problematic. If you are setting up a bizobj
without a PK defined, it *should* be throwing errors or at least
warnings. I'm not sure where the line between making things easy and
coddling should be drawn.
> * Suggestion: run should really run the form as a new subprocess/
> clean interpreter.
> Some initial confusion (and I'm sure later bugs) were caused/
> hidden because things were defined/created by the ClassEditor in
> the running interpreter instance.
> These errors would be clear if 'run' used a clean/new
> interpreter instance
This may be possible, but won't happen until the IDE is being
developed. Please add a tracker issue for it.
> * ClassEditor: if you select a method, it adds "def xxxx(self):" in
> the editor; if you change the text in anyway (even delete
> everything except the def line, ie return it back to what it
> started with) it will cause the code autogenerator to include the
> text.
> This leads to 'invalid indentation' errors when you run the
> form, which are not at all clear to understand where they're coming
> from to start with.
> I think on save/run, any methods that are flagged as user
> edited, but contain only the auto-generated 'def xxxx(self):' line
> + whitespace should be automatically removed.
Here's the current code:
mb = self._getMethodBase(mthd, None)
isEmpty = (txt.strip() == "") or (txt in mb)
What this is saying is that if the text in an editor window is
either empty, or is a subset of the base method text that
automatically is placed in the window, it is considered an empty
method, and the text is not included. If you *add* anything to the
base text, or edit the base text, then the editor considers the
editor contents as being something you want to save.
> * form.showmodal()
> -should throw exception until supported by underlying wxPython
> -currently 'looks like' it's working, but doesn't stop event
> processing for the rest of the app; now know this is documented on
> the wiki, but it's not obvious when you're in an editor ;-)
Good idea. Done.
> * Help/documentation
> -could include static copy of wiki docs (e.g. captured via wget)
Where? As a separate download?
> -api doc generated with something like epydoc with graphviz
You mean like http://paul.dabodev.com/doc/api/dabodoc/ ?
> -in ClassEditor help- introspect dabo libraries and present doc
> strings in a tree widget-like thing?
Not sure what you mean. Example?
> * Better code round-trip support with external editors
> -include needed/used imports in the generated code (so editors
> can auto-complete based on imports.)
Import statements are indeed included in the code file.
> -would be useful if generated code from form was runnable,
> without needing extra wrapper script.
The wrapper is for the .cdxml, which is what is getting run. The
separate .py file is an artifact designed to make it possible to edit
the code in your favorite Python editor instead of having it inside
the XML. I guess it would be possible to add some code inside an 'if
__name__ == "__main__":' block, but that would take some testing.
Please add a tracker issue for this.
> e.g. dApp instance is in wrapper, so again, editors can't do full
> autocompletion
Again, I'm not sure what you mean here.
> -dabo editor should detect when the code file has been changed
> by an external editor, and ask the user if it should be reloaded.
Probably not going to happen until the IDE project, and even then it
will be iffy. But you can add it as an issue.
> Also, should be possible to save class ui data seperately from
> code. Eg so class editor can be used to tweak ui positioning,
> labels, etc, and an external editor can be more easily integrated.
That's exactly what is being done now.
> * Some documentation re what can be saved as a re-useable custom
> class, what can't (eg forms can't, panels can,...),
Ummm... forms *are* custom, re-usable classes. They just can't be
added to other forms, since, well, they're both forms.
> and if the custom class is created with code, if that code will be
> also be imported when inserted into another form (I believe not?),
Of course it will. What good is a custom class if you can't save
behaviors?
> and if it is, wheiter edits are local to this instance, or affect
> all instances in the application into which it's inserted.
This is more complex, and depends on inheritance. If you edit
anything in the instance of a custom class, that changed value is
preserved. Otherwise, the class definition will determine what is in
the instance, and if that changes, so will the instance the next time
it is run.
Example: you create a custom panel-based class, and set the panel
background to red. In your new form, you add two instances of the
panel-based class, and change the BackColor of one to blue. Now let's
save your new class, then open the custom panel class and change its
BackColor to green. Save the panel class, and then re-open your new
class. The instance that you had changed to blue is still blue, but
the one that you hadn't changed is now green, just like the superclass.
> * Insertfrom DE in Class Editor- would be nice to have an 'insert
> in table order' option, not just alpha-order
The order of columns in a table is undefined in SQL. I know that
several backends do preserve column order, but it really is
meaningless. Alpha sort just helps you find the ones you want easier;
you then arrange them the way you want.
> * dialog classes- confusing to have both show and Show methods
All of the underlying wxPython atts/methods are exposed. Nothing
much we can do about it.
> * Sizers in class editor- after deleting content from a slot, keeps
> size of last contents. Might be better if it repacked/
> redistributed the sizes.
It might in some cases; in others it would be annoying.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
