In that case, I suggest to create a temp layer that translates from EF
to datatable, use the grid, and trnanslate back to EF, assuming
DataTable would not have the same issue.
In above statement substitute X in place of DataTable where X could be
Linq Objects, BindingList of Business Object etc.
Hope that helps to side step the issue.
Regards
Arjang
On 28 March 2011 15:05, Stephen Price <step...@littlevoices.com> wrote:
> Yep, totally understand.
>
> Not using EF isn't an option for this project as it's already being used.
> That leaves finding a work around as the best option. Sort of like jumping
> off the cliff then having to deal with the fall on the way down. maybe not
> the best analogy. The sudden stop at the bottom has a similar amount of pain
> associated with it at times, so perhaps it is a good analogy. :)
>
> On Mon, Mar 28, 2011 at 11:43 AM, Arjang Assadi <arjang.ass...@gmail.com>
> wrote:
>>
>> Stephen,
>>
>> After having burned many hours with EF trying to understand "why"s, I
>> have come to the conclusion to find ( EF or non-EF ) workarounds
>> instead.
>>
>> I have even seen the champion of EF, Julie Lerman post to MS
>> newsgroups questioning the rational behind the very same behavior I
>> was trying to understand ( it was about using EF in an N-Tier
>> disconnected way).
>>
>> I guess the question one ends up asking themselves boils down to
>> whether they are trying to use EF to accomplish some task or doing EF
>> to understand EF itself.
>>
>> Having said that, EF does solve many problems but at the price of
>> introducing a different types of problems. Question is which problem
>> set one wishes rather be solving.
>>
>> Regards
>>
>> Arjang
>>
>>
>>
>> On 28 March 2011 14:24, Stephen Price <step...@littlevoices.com> wrote:
>> > Hey there,
>> >
>> > Are there any EF gurus about?
>> > This is a further email about the issue I posted recently where pressing
>> > escape to undo a new row on a RadGridView is throwing an exception on
>> > some
>> > entities but not others.
>> >
>> > I've tracked down a difference but can't seem to find anything about
>> > SourceSets.
>> >
>> >
>> >
>> > public void Remove(object value)
>> > {
>> > T entity = value as T;
>> > if (entity != null)
>> > {
>> > this.Source.Remove(entity);
>> > if (this._addedEntities.Contains(entity))
>> > {
>> > this._addedEntities.Remove(entity);
>> > this.Source.SourceSet.Remove(entity);
>> > }
>> > }
>> > }
>> >
>> >
>> > This is the code i've decompiled to see what's happening...
>> >
>> > the line with the sourceset.remove is throwing an exception because the
>> > sourceset is null. I guess you could say that's a bug? I mean it's
>> > checking
>> > if _addedEntities contains the entity before it removes it, but does not
>> > check if the SourceSet contains the entity before trying to remove it. I
>> > don't know enough about the EntityFramework to know what a SourceSet
>> > is...
>> > may just be an internal only structure or something else?
>> >
>> >
>> > int index = -1;
>> > if (entity.EntitySet == this)
>> > {
>> > index = this._list.IndexOf(entity);
>> > }
>> > if (index == -1)
>> > {
>> >
>> > throw new InvalidOperationException(Resource.EntitySet_EntityNotInSet);
>> > }
>> >
>> >
>> > Inside the remove (second code snippit above) it checks if the entity is
>> > not
>> > in the set and throws an InvalidOperationException.
>> >
>> > By that, I'm taking it that the entity not being in the SourceSet is an
>> > exceptional circumstance. Just can't figure out what that means, right
>> > now.
>> >
>> > Feel like i'm learning to firewalk here :)
>> >
>> > cheers,
>> > Stephen
>
>
