Re: [dabo-users] Event processing runtime error
Paul McNett wrote: > Not coding to exceptions, but adding something perhaps overlooked. The > fact that Nate is calling moveToPK() *from the UI* tells me that we > have a candidate for a UI wrapper. I was going to get around to wrapping this eventually so that the TreeView can accept a DataSource, DataField, and a parent field. The parent field is so that you can represent a flat dataset in a tree structure (tasks with subtasks for example). Only with the parent field does using a tree view as a data aware object make sense. > It wouldn't know about PK's, any more than it knows about row numbers, > as in the moveToRowNumber() function. I am not sure moveToRowNumber would work here, because I am not mapping the bizobj dataSet in a flat array. It's in a Tree structure. I could always store the row number in the node to row dictionary instead of the PK. I will look into rewriting it. I didn't know that moveToRowNumber method existed. Regards, Nate ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4a8b3b4b.4030...@gmail.com
Re: [dabo-users] Event processing runtime error
Ed Leafe wrote: > I think that we shouldn't code to exceptions. The only reason > that the call to activeControlValid() was needed is because of the > order of event firing didn't match what we needed. Most of the time, > though, it works just fine. > > I also don't think that controls on a form should know about PKs, > datasets, and the like. They should at most call a form method to > handle their being clicked or typed in or whatever. They shouldn't > have to know that their node contains a PK and that when they are > clicked they need to talk to a bizobj, etc. They should simply call a > form method in their handler, and let the form take it from there. > I would argue that that works reasonably well for Data Aware controls. However, I am using the TreeView as a Data Control because of it's nested hierarchy. It is perfect for things like projects/tasks and parts/assemblies because I can create a tree structure representation from flat data. To do this, I needed to be able to update the bizobj current field pointer when a new node was selected, so I went with an implementation specific solution that required the PK to be a field called "ID". It is definitely not the best way. How do you update the bizobj current record within a dGrid object? Maybe I could model off of that and create a generic data aware TreeView object. Regards, Nate ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4a8b3b0f.6040...@gmail.com
Re: [dabo-users] Event processing runtime error
On Aug 18, 2009, at 5:57 PM, Paul McNett wrote: > Not coding to exceptions, but adding something perhaps overlooked. The > fact that Nate is calling moveToPK() *from the UI* tells me that we > have > a candidate for a UI wrapper. I guess that I disagree with having that much knowledge in the controls. -- Ed Leafe ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dd79dc55-687d-46bf-a2a8-03e27ac4a...@leafe.com
Re: [dabo-users] Event processing runtime error
Ed Leafe wrote: > I think that we shouldn't code to exceptions. The only reason that > the call to activeControlValid() was needed is because of the order of > event firing didn't match what we needed. Most of the time, though, it > works just fine. Not coding to exceptions, but adding something perhaps overlooked. The fact that Nate is calling moveToPK() *from the UI* tells me that we have a candidate for a UI wrapper. > I also don't think that controls on a form should know about PKs, > datasets, and the like. It wouldn't know about PK's, any more than it knows about row numbers, as in the moveToRowNumber() function. > They should at most call a form method to > handle their being clicked or typed in or whatever. They shouldn't > have to know that their node contains a PK and that when they are > clicked they need to talk to a bizobj, etc. They should simply call a > form method in their handler, and let the form take it from there. Right, by calling self.moveToPK(). Paul ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4a8b23de.7020...@ulmcnett.com
Re: [dabo-users] Event processing runtime error
On Aug 18, 2009, at 4:20 PM, Paul McNett wrote: > Ed, what's your opinion of adding dForm.moveToPK(), and having that > function call activeControlValid()? -1 > Not that I'm against users calling activeControlValid() explicitly, > but > moveToPK() seems to me to be one of the places where it would likely > be > the desired behavior, and it would be consistent with the other > navigation functions in dForm. I think that we shouldn't code to exceptions. The only reason that the call to activeControlValid() was needed is because of the order of event firing didn't match what we needed. Most of the time, though, it works just fine. I also don't think that controls on a form should know about PKs, datasets, and the like. They should at most call a form method to handle their being clicked or typed in or whatever. They shouldn't have to know that their node contains a PK and that when they are clicked they need to talk to a bizobj, etc. They should simply call a form method in their handler, and let the form take it from there. -- Ed Leafe ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/d82cf4d8-c279-4e80-9762-deb3b7368...@leafe.com
Re: [dabo-users] Event processing runtime error
Ed Leafe wrote: > On Aug 18, 2009, at 4:06 PM, Nate Lowrie wrote: > >>> The question is: are you getting bitten by a quirk of dTreeView, or >>> by >>> calling biz.moveToPK() directly, the biz being unaware that there are >>> pending changes yet. >> Not sure. I'll see about doing some more testing this weekend one to >> see. Am I not supposed to call biz.moveToPK() directly? > > > You can call it directly; the issue is simply that the events are not > firing in the order you need. For situations like this, a call to the > form's activeControlValid() is the preferred approach. Ed, what's your opinion of adding dForm.moveToPK(), and having that function call activeControlValid()? Not that I'm against users calling activeControlValid() explicitly, but moveToPK() seems to me to be one of the places where it would likely be the desired behavior, and it would be consistent with the other navigation functions in dForm. Paul ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4a8b0cf7.40...@ulmcnett.com
Re: [dabo-users] Event processing runtime error
On Aug 18, 2009, at 4:06 PM, Nate Lowrie wrote: >> The question is: are you getting bitten by a quirk of dTreeView, or >> by >> calling biz.moveToPK() directly, the biz being unaware that there are >> pending changes yet. > > Not sure. I'll see about doing some more testing this weekend one to > see. Am I not supposed to call biz.moveToPK() directly? You can call it directly; the issue is simply that the events are not firing in the order you need. For situations like this, a call to the form's activeControlValid() is the preferred approach. -- Ed Leafe ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/37633a55-0d6b-400b-b95c-18173d025...@leafe.com
Re: [dabo-users] Event processing runtime error
Paul McNett wrote: > The question is: are you getting bitten by a quirk of dTreeView, or by > calling biz.moveToPK() directly, the biz being unaware that there are > pending changes yet. Not sure. I'll see about doing some more testing this weekend one to see. Am I not supposed to call biz.moveToPK() directly? Regards, Nate ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4a8b09c0.9030...@gmail.com
Re: [dabo-users] Event processing runtime error
Nate Lowrie wrote: > Ed Leafe wrote: >> On Aug 18, 2009, at 2:25 PM, Nate Lowrie wrote: >> >> Try adding the following line: >> >> >>>def updateBizobj(self, evt): >>> >> self.Form.activeControlValid() > It works. Maybe we should consider calling this in > dTreeView.__onTreeSel before we raise the event. +0 Not sure if we should do that, or add a dForm.moveToPK() function that calls self.activeControlValid() before moving the pointer, like dForm does in other places such as from next(), prior(), etc. The question is: are you getting bitten by a quirk of dTreeView, or by calling biz.moveToPK() directly, the biz being unaware that there are pending changes yet. Paul ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4a8b0066.1060...@ulmcnett.com
Re: [dabo-users] Event processing runtime error
On Aug 18, 2009, at 2:57 PM, Nate Lowrie wrote: > It works. Maybe we should consider calling this in > dTreeView.__onTreeSel before we raise the event. I don't think that this is common enough to warrant firing this every time a tree node is selected. In your case, you're using the tree as a record navigation control, which IMO is not a common enough paradigm. -- Ed Leafe ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/1e102587-07f3-4417-85e7-bf2b8d5d5...@leafe.com
Re: [dabo-users] Event processing runtime error
Ed Leafe wrote: > On Aug 18, 2009, at 2:25 PM, Nate Lowrie wrote: > > Try adding the following line: > > >>def updateBizobj(self, evt): >> > > self.Form.activeControlValid() > > >>if self.taskBizobj.isChanged(): >>print "saving bizobj" >>self.taskBizobj.save() >> >>print "moving to PK" >>self.taskBizobj.moveToPK(self.taskNodeDic[self.Selection]) >>self.Form.update() >> Ed, It works. Maybe we should consider calling this in dTreeView.__onTreeSel before we raise the event. Regards, Nate ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4a8af98c.7090...@gmail.com
Re: [dabo-users] Event processing runtime error
On Aug 18, 2009, at 2:25 PM, Nate Lowrie wrote: > I moved the save into the TreeSelection menu. However, I am still > having a problem. I have the following code that fires on the Tree > Selection bizobj: Try adding the following line: >def updateBizobj(self, evt): self.Form.activeControlValid() >if self.taskBizobj.isChanged(): >print "saving bizobj" >self.taskBizobj.save() > >print "moving to PK" >self.taskBizobj.moveToPK(self.taskNodeDic[self.Selection]) >self.Form.update() -- Ed Leafe ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/036d94b0-7049-4c59-b700-c42428f75...@leafe.com
Re: [dabo-users] Event processing runtime error
John wrote: > Correct me if I'm wrong. You are saying that the tree event is firing > before the bizobj realizes that a field was changed. Did you by chance > check old.value vs. new.value (not sure what the real code should be) > in the onNodeChange method? > I would have thought the lostfocus would have fired first. > John, Yes, I am saying that the TreeSelection event is firing before the bizobj realizes that a field was changed. isChanged() is reporting false and I just checked the bizobj value through getFieldVal and it doesn't have the update information. As Ed explained before, a control must get focus before another control loses focus, which makes sense. However, in this case I would expect the bizobj to be updated and the ValueChanged event on the dEditBox be fired before the TreeSelection event. Regards, Nate ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4a8af6b7.5020...@gmail.com
Re: [dabo-users] Event processing runtime error
On Tuesday 18 August 2009 11:25:35 am Nate Lowrie wrote: > Ed Leafe wrote: > > Since you are moving the bizobj record pointer when you select nodes > > on the tree, it probably would make sense to check for pending changes > > before doing the seek. > > I moved the save into the TreeSelection menu. However, I am still > having a problem. I have the following code that fires on the Tree > Selection bizobj: > > def updateBizobj(self, evt): > if self.taskBizobj.isChanged(): > print "saving bizobj" > self.taskBizobj.save() > > print "moving to PK" > self.taskBizobj.moveToPK(self.taskNodeDic[self.Selection]) > self.Form.update() > > > I make a change to the dEditBox and click directly on another node in > the tree. The event fires and isChanged() is returning false, then we > move to the new PK. Now, if I go click on another node, isChanged > returns true and the bizobj is saved. However, the value in dEditBox > gets attached to the second node and not the first node like it should. > I bound a method to the ValueChanged event on the dEditBox that had a > print statement in it to see if the ValueChanged event was being > recognized and fired before or after the TreeSelection selection event. > It is firing after the TreeSelection event, which leads me to believe > that the code that updates the bizobj is not being fired until that > event is called. If this is the case, I think that this is a bug in the > events system, though I don't know what we can do about it. > > This has not been a show stopper. I simply changed my code above to the > following below and everything worked. However, I still think that this > should be fixed. > > def onNodeChange(self, evt): > dabo.ui.callAfter(self.updateBizobj) > > def updateBizobj(self): > if self.taskBizobj.isChanged(): > print "saving bizobj" > self.taskBizobj.save() > > print "moving to PK" > self.taskBizobj.moveToPK(self.taskNodeDic[self.Selection]) > self.Form.update() > > Regards, > > Nate Correct me if I'm wrong. You are saying that the tree event is firing before the bizobj realizes that a field was changed. Did you by chance check old.value vs. new.value (not sure what the real code should be) in the onNodeChange method? I would have thought the lostfocus would have fired first. Johnf ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/200908181134.55985.jfabi...@yolo.com
Re: [dabo-users] Event processing runtime error
Ed Leafe wrote: > Since you are moving the bizobj record pointer when you select nodes > on the tree, it probably would make sense to check for pending changes > before doing the seek. > I moved the save into the TreeSelection menu. However, I am still having a problem. I have the following code that fires on the Tree Selection bizobj: def updateBizobj(self, evt): if self.taskBizobj.isChanged(): print "saving bizobj" self.taskBizobj.save() print "moving to PK" self.taskBizobj.moveToPK(self.taskNodeDic[self.Selection]) self.Form.update() I make a change to the dEditBox and click directly on another node in the tree. The event fires and isChanged() is returning false, then we move to the new PK. Now, if I go click on another node, isChanged returns true and the bizobj is saved. However, the value in dEditBox gets attached to the second node and not the first node like it should. I bound a method to the ValueChanged event on the dEditBox that had a print statement in it to see if the ValueChanged event was being recognized and fired before or after the TreeSelection selection event. It is firing after the TreeSelection event, which leads me to believe that the code that updates the bizobj is not being fired until that event is called. If this is the case, I think that this is a bug in the events system, though I don't know what we can do about it. This has not been a show stopper. I simply changed my code above to the following below and everything worked. However, I still think that this should be fixed. def onNodeChange(self, evt): dabo.ui.callAfter(self.updateBizobj) def updateBizobj(self): if self.taskBizobj.isChanged(): print "saving bizobj" self.taskBizobj.save() print "moving to PK" self.taskBizobj.moveToPK(self.taskNodeDic[self.Selection]) self.Form.update() Regards, Nate ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4a8af21f.4020...@gmail.com
Re: [dabo-users] Event processing runtime error
Ed Leafe wrote: > On Aug 17, 2009, at 12:30 PM, John wrote: > >> I don't recall what it is called but is there an order that events >> fire? IOW >> is there a list of the order. > > > I don't know about a formal list, but the names "GotFocus" and > "LostFocus" are past tense, implying that the change in focus has > already been made before they fire. We've discussed this in the past > when you were looking for an equivalent to the When event in VFP, > which fires when the UI is attempting to change focus and can prevent > that change by returning False. There is no such 'ask permission to > lose focus' event in wx. Yep there's no formal order; events can be caught in arbitrary sequence, although in practice they tend to occur in predictable order, at least on a given platform. Paul ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4a89e65a.2080...@ulmcnett.com
Re: [dabo-users] Event processing runtime error
On Monday 17 August 2009 10:49:48 am Ed Leafe wrote: > On Aug 17, 2009, at 12:51 PM, John wrote: > > Yes I recall the discussion. I was hoping there might be something > > I could > > count on some order. The other day I ran across an instance where I > > wanted > > to bind two events to a click. But it became apparent that I could > > not count > > on the order the methods would fire. > > Usually when you find yourself in a situation like that in which > things don't work, it's best to step back and re-think the approach. > In your case, it would be smarter to bind to the click event, and then > have your handler raise the subsequent events in the order you need > them. > > > -- Ed Leafe Thanks Ed that's exactly what we did. Johnf ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/200908171051.33596.jfabi...@yolo.com
Re: [dabo-users] Event processing runtime error
On Aug 17, 2009, at 12:51 PM, John wrote: > Yes I recall the discussion. I was hoping there might be something > I could > count on some order. The other day I ran across an instance where I > wanted > to bind two events to a click. But it became apparent that I could > not count > on the order the methods would fire. Usually when you find yourself in a situation like that in which things don't work, it's best to step back and re-think the approach. In your case, it would be smarter to bind to the click event, and then have your handler raise the subsequent events in the order you need them. -- Ed Leafe ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/2f3841cc-9d26-4398-b78a-c753f80a2...@leafe.com
Re: [dabo-users] Event processing runtime error
On Monday 17 August 2009 09:43:21 am Ed Leafe wrote: > On Aug 17, 2009, at 12:30 PM, John wrote: > > I don't recall what it is called but is there an order that events > > fire? IOW > > is there a list of the order. > > I don't know about a formal list, but the names "GotFocus" and > "LostFocus" are past tense, implying that the change in focus has > already been made before they fire. We've discussed this in the past > when you were looking for an equivalent to the When event in VFP, > which fires when the UI is attempting to change focus and can prevent > that change by returning False. There is no such 'ask permission to > lose focus' event in wx. > > > -- Ed Leafe Yes I recall the discussion. I was hoping there might be something I could count on some order. The other day I ran across an instance where I wanted to bind two events to a click. But it became apparent that I could not count on the order the methods would fire. Thanks anyway, Johnf ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/200908170951.01305.jfabi...@yolo.com
Re: [dabo-users] Event processing runtime error
On Aug 17, 2009, at 12:30 PM, John wrote: > I don't recall what it is called but is there an order that events > fire? IOW > is there a list of the order. I don't know about a formal list, but the names "GotFocus" and "LostFocus" are past tense, implying that the change in focus has already been made before they fire. We've discussed this in the past when you were looking for an equivalent to the When event in VFP, which fires when the UI is attempting to change focus and can prevent that change by returning False. There is no such 'ask permission to lose focus' event in wx. -- Ed Leafe ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/2dbb553c-8eaf-43ad-8b1e-e9fb2fff7...@leafe.com
Re: [dabo-users] Event processing runtime error
On Monday 17 August 2009 09:13:23 am Nate Lowrie wrote: > On Mon, Aug 17, 2009 at 10:37, Ed Leafe wrote: > > That sounds like correct behavior to me. Something else has to get > > focus before a control can lose focus. > > I guess that makes sense. I was thinking that the event firing would > go like GotFocus, LostFocus, other events on control with new focus. > > > Since you are moving the bizobj record pointer when you select > > nodes on the tree, it probably would make sense to check for pending > > changes before doing the seek. > > Sounds like a good idea. I will investigate doing that. > > Regards, > > Nate I don't recall what it is called but is there an order that events fire? IOW is there a list of the order. Johnf ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/200908170930.20381.jfabi...@yolo.com
Re: [dabo-users] Event processing runtime error
On Mon, Aug 17, 2009 at 10:37, Ed Leafe wrote: > That sounds like correct behavior to me. Something else has to get > focus before a control can lose focus. I guess that makes sense. I was thinking that the event firing would go like GotFocus, LostFocus, other events on control with new focus. > Since you are moving the bizobj record pointer when you select nodes > on the tree, it probably would make sense to check for pending changes > before doing the seek. Sounds like a good idea. I will investigate doing that. Regards, Nate ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4bef56240908170913j15ba27b0u5dceaa7be201d...@mail.gmail.com
Re: [dabo-users] Event processing runtime error
On Aug 17, 2009, at 10:32 AM, Nate Lowrie wrote: > I am having a curious issue. I am using a dTreeView to display a > bizobj output in a tree parent form. I also have a an editbox set to > the same bizobj as a DataSource. I have two events set. The first is > a lost focus event on the edit box, in which the Form.save method is > called. The second is a TreeSelection event on the dTreeView, in > which a bizobj.moveToPK method is being called. Now, I have a > situation where if I edit the edit box and then click on a node that > is not selected, the TreeSelection event is fired first, which > performs the seek. The lost focus event is fired next, which performs > the save. The result is that the change in the edit box that should > have been applied to the old record are applied and saved on the new > record. That sounds like correct behavior to me. Something else has to get focus before a control can lose focus. Since you are moving the bizobj record pointer when you select nodes on the tree, it probably would make sense to check for pending changes before doing the seek. -- Ed Leafe ___ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/98c139da-7c2e-484a-b3a6-7ddd1478e...@leafe.com
