On 5/9/13 5:48 PM, John Fabiani wrote:
> I believe I discovered some of the issues I'm having moving old code (0.9.4)
> to 0.9.10.
>
> I have a relative simple form that sets a few dates (dDateTextBox). A start
> date and
> end date. I associated an event "dEvents.ValueChanged" to the start date. In
> the
> event method I set the second date (the end date) to a value.
Just to eliminate any changes to dDateTextBox being the source of the change, I
did a
diff of dDateTextBox between 0.9.4 and 0.9.10:
$ git diff dabo-0.9.4..v0.9.10 dabo/ui/uiwx/dDateTextBox.py
diff --git a/dabo/ui/uiwx/dDateTextBox.py b/dabo/ui/uiwx/dDateTextBox.py
index 56f1803..fbdc431 100644
--- a/dabo/ui/uiwx/dDateTextBox.py
+++ b/dabo/ui/uiwx/dDateTextBox.py
@@ -3,6 +3,7 @@ import datetime
import wx
import dabo
if __name__ == "__main__":
+ import dabo.ui
dabo.ui.loadUI("wx")
import dDataControlMixin as dcm
import dabo.dEvents as dEvents
@@ -39,6 +40,7 @@ class CalPanel(dPanel):
self.Size = (wd+10, ht+10)
self.BackColor = (192, 192, 0)
self.cal.Visible = True
+ self.cal.setFocus()
def onCalSelection(self, evt):
@@ -469,4 +471,4 @@ C: Popup Calendar to Select
if __name__ == "__main__":
import test
- test.Test().runTest(dDateTextBox)
+ test.Test().runTest((dDateTextBox, dDateTextBox))
$
Nothing substantial there.
> Using the old Dabo 0.9.4 the event (dEvents.ValueChanged) fires immediately
> upon
> opening the form. I'll guess and say somewhere the "start date" value gets
> changed. I do not set the value in code - the event still fired. And of
> course the
> event method fires and sets the end date.
>
> In 0.9.10 the above does not happen. I have to set the value and then
> raiseEvent(dEvents.ValueChanged) for the start date to cause the correct
> method to
> fire (I set the value and raise the event in afterInitAll).
You shouldn't have to manually raise the ValueChanged event. Simply setting the
Value
should raise it implicitly.
> Yet, after the form
> opens, if I change the value in the start date control the correct event
> method fires.
What if you change it programatically after the form opens?
> I was able to prove the above now that I have both 0.9.4 and 0.9.10 running.
>
> So my question is: What is different in the way events fire (model?)?
My hunch is that this problem isn't to do with events in general, but with
ValueChanged in particular.
Since there wasn't anything substantial changed in dDateTextBox, I suspect
something
in dabo.ui.dDataControlMixinBase.py. I'm not going to print the diff here
because it
is long (but mostly contains things we can safely ignore). Here's the command:
$ git diff dabo-0.9.4..v0.9.10 dabo/ui/dDataControlMixinBase.py
There's a new self._from_flushValue flag which seems like a candidate for
investigation. When did that get added? :
$ git blame dabo/ui/dDataControlMixinBase.py | grep _from_flushValue
1891dcb8 dabo/ui/dDataControlMixinBase.py (Ed Leafe 2009-12-26
20:41:07
+0000 28) self._from_flushValue = False
e7511b44 dabo/ui/dDataControlMixinBase.py (Jacek Kalucki 2012-02-08
15:59:33
+0000 76) self._from_flushValue = False
e7511b44 dabo/ui/dDataControlMixinBase.py (Jacek Kalucki 2012-02-08
15:59:33
+0000 219) if self._from_flushValue:
e7511b44 dabo/ui/dDataControlMixinBase.py (Jacek Kalucki 2012-02-08
15:59:33
+0000 257) # To prevent such situation we have to check
the _from_flushValue
attribute at the beginning.
e7511b44 dabo/ui/dDataControlMixinBase.py (Jacek Kalucki 2012-02-08
15:59:33
+0000 258) self._from_flushValue = True
1891dcb8 dabo/ui/dDataControlMixinBase.py (Ed Leafe 2009-12-26
20:41:07
+0000 305) self._from_flushValue = False
dbbec152 dabo/ui/dDataControlMixinBase.py (Paul McNett 2010-02-05
14:28:49
+0000 388) if self._inDataUpdate or self._from_flushValue:
Ok, _from_flushValue has been there longer than 0.9.4, which was released in
Oct. of
2011, my change also precedes that, but it still could be Jacek's change in
2012-02-08. We could merge that commit out and test, or you know what? It could
be
something else entirely that we might not think about and we run the risk of
getting
lost in a quagmire for no reason if we proceed any further in
dDataControlMixinBase
at this point. git bisect will tell us exactly which commit broke this, and we
can
launch a sturdy investigation from there.
Do something like:
$ git bisect start
$ git bisect bad
$ git checkout dabo-0.9.4
Previous HEAD position was 63b4e41... Release v0.9.10
HEAD is now at 301cbde... Misnamed the 0.9.4 tag.
$ git bisect good
Bisecting: a merge base must be tested
[22cecf9ed76bcef83a8da3af7c5a32c77d95e5d6] auto-incrementing of revision
--- test here and report back to git with either 'bad' or 'good':
$ git bisect good
Bisecting: 220 revisions left to test after this (roughly 8 steps)
[4b6d44a190fb491fd0752aabce9858860025ce62] Trivial capitalization change made in
order to test doc generation.
--- test here and repeat with 'bad' and 'good' as appropriate until you and git
find
the commit that changed the behavior. Git will even anticipate your next
question and
show you the log message without you even asking for it.
> BTW thinking about this issue in a general way. I would suggest I was
> incorrectly
> taking advantage of framework and should have set the values explicitly in
> 0.9.4.
Whether or not you should have been setting the values explicitly, you should
not be
having to manually raise ValueChanged, unless the value didn't actually change
and
you have a special case. So I think this is a bug.
As always, I'd appreciate an attempt at small runnable code that shows the
issue, but
I'm confident that you and git bisect can find the commit that broke it, which
is
half the battle.
Hopefully the 'stream of consciousness' style of this post is appreciated. In
truth I
would have started out with 'git bisect' to begin with.
Paul
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message: http://leafe.com/archives/byMID/[email protected]
