I have been banging my head against this one all afternoon so maybe somebody can help.
I have a Root object which has a collection of children, which each have a collection of Grandchildren. I have 3 bindingsources on my form (Root, Child, Grandchildren)
I can save the object fine and rebind the UI, all edit levels work great with Rocky's latest fix. However, if I call CancelEdit() I get an editlevel mismatch. One of the grandchildren stays at an elevated edit level.
This does NOT occur when using a Janus grid, or when using two windows grids on the same object base. So this has to be something to do with Infragistics. If anybody has seen this before please let me know. I am also posting this on the infragistics site.
Thanks,
Ryan
Yes, I am handling Current Change on the Child binding source. In fact I replaced the two grids in the RootChildGrandchild with an Infragistics grid to get the error.
I suppose the next question is whether the event is firing? It
seems that their grid must be doing something different from the standard grid –
either in its interaction with the bindingsource or the object itself.
Rocky
I am having a simillar issue while using Infragistics WinGrid. for a child object.
When i call the BeginEdit() the edit level is incremented and On ApplyEdit It is properly decremented. But any call to CancelEdit() or EndEdit() the editlevel is not decremented
What I have is a RootObject with Child Object on a Form. I am using 2 Bindingsources. One for root and the other for child.
I have the functionality that whenver a user double clicks on the Grid the child object is opened in its own seperate window. where in the Child Forms constructer I bind it to a bindingsource and Call BeginEdit(). On Ok button on the form I Call ApplyEdit() and on Cancel Button I call CancelEdit() on child objects.
Just something to try… Try to call grid’s ExitEditMode(?I
do not remember exact name) before calling end / cancel edit on data sources.
Sergey Barskiy
Senior Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: rkelley
[mailto:cslanet@lhotka.net]
Sent: Tuesday, May 27, 2008 10:40 PM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] OT: Infragistics Grid EditLevel Help!
Yes, I am handling Current Change on the Child binding source. In fact I
replaced the two grids in the RootChildGrandchild with an Infragistics grid to
get the error.
Thanks for the suggestion, I did :
ultragrid1.PerformAction(UltraGridAction.ExitEditMode);
but it didn't change anything.
Well, I tried L.
Did you also try to add UpdateData call after PerfomAction?
Sergey Barskiy
Senior Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: rkelley
[mailto:cslanet@lhotka.net]
Sent: Wednesday, May 28, 2008 9:17 AM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] RE: OT: Infragistics Grid EditLevel Help!
Thanks for the suggestion, I did :
ultragrid1.PerformAction(UltraGridAction.ExitEditMode);
but it didn't change anything.
If a data source is still bound to a bindingsource, the
bindingsource will call BeginEdit() on the current row of the data source. As
long as your object is data bound, it will have an elevated edit level, that’s
the rule.
So it is interesting to consider that your code works with the
.NET grid, and not the UltraGrid. Perhaps the UG is directly interacting with
your object, bypassing the bindingsource behavior?
Because the code in PTWin (which I assume you are doing too)
detaches the grandchild from the bindingsource, then resets the edit level on
what was the current row. And then it repeats for the child, etc.
But if the UG somehow maintained its own reference to the
object, the fact that you detached it from the bindingsource might not help?
Rocky
I have passed along all of our troubles and findings to the kind folks over at Infragistics. They are now looking into the problem as well, since I believe it is definitly an infragistics problem.
Will let you know what I find out, when I find it out.
Ryan
Rocky,
Just got this response back from Infragistics:
We aren't familiar with CSLA .NET, nor do we support the use of third party software with our WinGrid.
Our hierarchical grid does not work the same way as two flat Microsoft grids would, it's structured very differently, and that could be part of the problem, but we have no way of knowing that.
That being said, we need some explanation of what an EditLevel is. We may be able to progress with this if we have that. Still, our only way of moving forward with this is with .NET objects alone, as that is all we support. For instance, depending on what an EditLevel is, if there is a .NET equivalent, we could test that and see if it does the same thing.
Can you give me a quick and dirty explanation of editlevels? If I am not mistaken it all has to do with the n-level undo capablity. So what the edit level tracks is the version of changes or better yet what has changed so that the object can be "undone" to its previous state. Is there a .net equivalent?
I am not surprised by that response :)
The ultimate issue is their use of
System.ComponentModel.IEditableObject, which may be operating in a slightly
non-standard manner. Or may be operating in a way they have found works with
the DataSet through trial and error.
CSLA imposes some restrictions that the DataSet does not –
specifically requiring that the calls to IEditableObject.BeginEdit() are
balanced by a later call to CancelEdit() or EndEdit(). The DataSet doesn’t
care if there’s a subsequent call – from what I can tell, it defaults
to “EndEdit()” behavior if the calls are unbalanced.
So the term “edit level” in this context refers to
the tracking CSLA does to ensure that every BeginEdit() call is balanced by a
CancelEdit()/EndEdit() call.
Rocky
Still no word from Infragistics but in the mean time I have found a workaround.
If I set base.DisableIEditableObject = true; in each of my business objects constructor, then everything works as it should. All edit levels match, N-level undo works, etc...
I am assuming this only works because I have balanced the calls to BeginEdit with calls to either ApplyEdit or CancelEdit.
Yes, that should be a decent workaround. The only issue you may
find is that pressing ESC while editing a row may not reset that row to its
previous values – that’s really what IEditableObject provides
within the grid context.
Rocky
I will have to investigate but I think there is a grid event that i could implement to handle that scenario as well. Will let you know if Infragistics comes up with anything.
After a quick glance, this seems similar to what BindingSourceNode gets you. Does that not work, but this one does for Infragistics?
I ask because I sitll have odd problems on some of my grids, but it could be I'm not binding them proplery... but on the ones that work I think BSN takes care of it.
Copyright (c) Marimer LLC