On Aug 26, 2008, at 5:13 PM, Henning Hraban Ramm wrote:
Hello, please, if you implement something in this direction, think
about switching to standard logging - you can direct that to anything.
You will be pleased to find that the new debug output uses the
standard Python logging
Am 2008-08-27 um 18:26 schrieb Ed Leafe:
On Aug 26, 2008, at 5:13 PM, Henning Hraban Ramm wrote:
Hello, please, if you implement something in this direction, think
about switching to standard logging - you can direct that to
anything.
You will be pleased to find that the new debug
Am Montag, 25. August 2008 18:03:28 schrieb Uwe Grauer:
Sibylle Koczian wrote:
def afterRequery(self):
self.testlogID.Value += u\nRequery ausgeführt.
BTW, if you need this for logging only, use:
print Requery ausgeführt.
This will print to the command line window if you start your
Sibylle Koczian wrote:
Am Montag, 25. August 2008 18:03:28 schrieb Uwe Grauer:
Sibylle Koczian wrote:
def afterRequery(self):
self.testlogID.Value += u\nRequery ausgeführt.
BTW, if you need this for logging only, use:
print Requery ausgeführt.
This will print to the command line
On Aug 26, 2008, at 5:10 AM, Sibylle Koczian wrote:
Of course, but for learning Dabo I found a logging area in the main
window a
little more interesting.
Hey, I like that idea. Traditionally we print debug info to stdout,
but it would be handy to have a GUI option for this. I
On Aug 26, 2008, at 6:14 AM, Uwe Grauer wrote:
You will find out that even afterInitAll() isn't the right place for a
call to requery(). Most of my forms use onActivate() with some status
variables for this kind of work.
Why wouldn't afterInitAll() be a good time? All the controls
Ed Leafe wrote:
On Aug 26, 2008, at 6:14 AM, Uwe Grauer wrote:
You will find out that even afterInitAll() isn't the right place for a
call to requery(). Most of my forms use onActivate() with some status
variables for this kind of work.
Why wouldn't afterInitAll() be a good time?
Ed Leafe wrote:
On Aug 26, 2008, at 6:14 AM, Uwe Grauer wrote:
You will find out that even afterInitAll() isn't the right place for a
call to requery(). Most of my forms use onActivate() with some status
variables for this kind of work.
Why wouldn't afterInitAll() be a good time?
On Tue, Aug 26, 2008 at 7:10 AM, Paul McNett [EMAIL PROTECTED] wrote:
Putting too much stuff in the init phase makes forms feel like they are
loading sluggishly. Delaying the requery until the controls that need
the data are shown can make things feel snappier.
Why not just put it in a
Nate Lowrie wrote:
On Tue, Aug 26, 2008 at 7:10 AM, Paul McNett [EMAIL PROTECTED] wrote:
Putting too much stuff in the init phase makes forms feel like they are
loading sluggishly. Delaying the requery until the controls that need
the data are shown can make things feel snappier.
Why not
Ed Leafe wrote:
On Aug 26, 2008, at 8:10 AM, Paul McNett wrote:
Putting too much stuff in the init phase makes forms feel like they
are
loading sluggishly. Delaying the requery until the controls that need
the data are shown can make things feel snappier.
That's different than
On Aug 26, 2008, at 10:30 AM, Paul McNett wrote:
Hey, I was responding to *your* question.
Which was asking Uwe why he would tell a newcomer that referencing an
object in afterInitAll() might not work.
Even if someone posts something that is downright wrong, it tends to
be
more
Ed Leafe wrote:
On Aug 26, 2008, at 10:30 AM, Paul McNett wrote:
Hey, I was responding to *your* question.
Which was asking Uwe why he would tell a newcomer that referencing an
object in afterInitAll() might not work.
I didn't say that referencing an object in afterInitAll()
Am Dienstag, 26. August 2008 14:27:27 schrieb Ed Leafe:
On Aug 26, 2008, at 5:10 AM, Sibylle Koczian wrote:
Of course, but for learning Dabo I found a logging area in the main
window a
little more interesting.
Hey, I like that idea. Traditionally we print debug info to stdout,
but
On Tuesday 26 August 2008 05:27:27 am Ed Leafe wrote:
Of course, but for learning Dabo I found a logging area in the main
window a
little more interesting.
Hey, I like that idea. Traditionally we print debug info to stdout,
but it would be handy to have a GUI option for this.
On Aug 26, 2008, at 2:41 PM, johnf wrote:
Please may sure I can turn off the output to the GUI. I like the
fact that
tracebacks and print statement are directed to standard out.
There would be no output by the framework. It would be for debugging
that you yourself insert. Think
On Tuesday 26 August 2008 01:38:45 pm Ed Leafe wrote:
On Aug 26, 2008, at 2:41 PM, johnf wrote:
Please may sure I can turn off the output to the GUI. I like the
fact that
tracebacks and print statement are directed to standard out.
There would be no output by the framework. It
Am 2008-08-26 um 22:38 schrieb Ed Leafe:
On Aug 26, 2008, at 2:41 PM, johnf wrote:
Please may sure I can turn off the output to the GUI. I like the
fact that
tracebacks and print statement are directed to standard out.
There would be no output by the framework. It would be for
Hello,
in the afterInit method of my form I put a dGrid in with
testLog = dabo.ui.dEditBox(self, RegID=testlogID, ReadOnly=True)
testLog.Value = SQLite Feldtest
panel.Sizer.append1x(testLog)
and in the afterRequery method I want to put additional text in:
def afterRequery(self):
Sibylle Koczian wrote:
def afterRequery(self):
self.testlogID.Value += u\nRequery ausgeführt.
BTW, if you need this for logging only, use:
print Requery ausgeführt.
This will print to the command line window if you start your app from a
command line.
Uwe
20 matches
Mail list logo
