This is my first real day of using the framework, so if I am off base here, feel free to throw something at me

Shouldn't the IsDirty flag get reset if I call an entities Refetch() method?

MarcoP wrote:

This is my first real day of using the framework, so if I am off base here, feel free to throw something at me

Shouldn't the IsDirty flag get reset if I call an entities Refetch() method?

Hmmm. Good point. Well, the flag is reset when a succesful save takes place. Normally you don't call Refetch(), it's a framework method that's called when the entity is out-of-sync after a save and you read a property: it will then first call Refetch() to refetch itself and then offer you the value.

In a whole year, you're the first who notices this though . I'll add it to the todo list, as I don't think it's a particular real bug and changing it will have some consequences I think, so these have to be sorted out first before a change can be applied.

[quotenick="Otis"]

MarcoP wrote:

In a whole year, you're the first who notices this though . I'll add it to the todo list, as I don't think it's a particular real bug and changing it will have some consequences I think, so these have to be sorted out first before a change can be applied.

Great, does that mean I can expect an LLBLGen Pro t-shirt in the mail soon

The screen I am working on is a customer edit screen, where they can change a customers's data, save, click the move next button, change the next customer, etc. I have a save and cancel button and when the user clicks the cancel button, I found the refetch method worked well for resyncing the entities data. Would it be wise for me to use the SaveFields() method instead?

MarcoP wrote:

Otis wrote:

In a whole year, you're the first who notices this though . I'll add it to the todo list, as I don't think it's a particular real bug and changing it will have some consequences I think, so these have to be sorted out first before a change can be applied.

Great, does that mean I can expect an LLBLGen Pro t-shirt in the mail soon

If we would have them, you would definitely get one

The screen I am working on is a customer edit screen, where they can change a customers's data, save, click the move next button, change the next customer, etc. I have a save and cancel button and when the user clicks the cancel button, I found the refetch method worked well for resyncing the entities data. Would it be wise for me to use the SaveFields() method instead?

SaveFields works on an individual entity. So it doesn't save the fields of a related entity. Your screen works on an individual entity, so the SaveFields() method is ideal for that purpose, saves you a trip to the DB

Hmmm...I dont think that would work in my scenario, because my screen allows the user to edit their phone #'s, which is 1:n relationship in my data model.

To try and give a better visual, my screen looks exactly like Microsoft Outlook 2003 (Contacts). Maybe I could call save fields on the CustomerEntity its self and then loop through the phone number collection and do the same for the phone number entities. Sound viable?

You run into trouble if the user adds/removes a phone entry and then clicks cancel. (either way you run into trouble: with the refetch or with the savefields). I'm not sure if you want to cancel edits on single entities or that the cancel cancels edits on all entities currently edited in a cycle. This is important as you could for example then simply decide to throw away the current customer instance and recreate a new one, which will load the phone numbers automatically.

Otis wrote:

I'm not sure if you want to cancel edits on single entities or that the cancel cancels edits on all entities currently edited in a cycle. This is important as you could for example then simply decide to throw away the current customer instance and recreate a new one, which will load the phone numbers automatically.

I dont mind re-creating the customer instance if the user clicks cancel (I thought the refetch would re-load the related entities as well). But the thing is, I have a grid bound to a collection of customers and when the user clicks a customer row, i bring up the edit screen. How could I kill the current customer instance and make sure the collection is in sync with this?

That was my whole premise with using the refetch, since I'm still dealing with the same instance, but I'm telling him to re-load himself. So let me make sure, the refetch only refetche's his data, not for example his phone #'s data if it changed? So if thats the case, when I called refetch, the customer data would be rolled back, but the customer would still have 'dirty' phone #'s?

MarcoP wrote:

Otis wrote:

I'm not sure if you want to cancel edits on single entities or that the cancel cancels edits on all entities currently edited in a cycle. This is important as you could for example then simply decide to throw away the current customer instance and recreate a new one, which will load the phone numbers automatically.

I dont mind re-creating the customer instance if the user clicks cancel (I thought the refetch would re-load the related entities as well). But the thing is, I have a grid bound to a collection of customers and when the user clicks a customer row, i bring up the edit screen. How could I kill the current customer instance and make sure the collection is in sync with this?

Then SaveFields() is a better option as that will signal the thread to refresh the row as well in the grid and you're not running into nasty databinding issues. Refetch doesn't fetch related entities, it just reloads the entity from the db so an out-of-sync entity is again up to date.

That was my whole premise with using the refetch, since I'm still dealing with the same instance, but I'm telling him to re-load himself. So let me make sure, the refetch only refetche's his data, not for example his phone #'s data if it changed?

Yes, it doesn't refetch any related data.

So if thats the case, when I called refetch, the customer data would be rolled back, but the customer would still have 'dirty' phone #'s?

Yes, so you have to implement some sort of rollback mechanism on the related collections as well.

There wasn't enough time to implement full collection state save/rollback and full entity state save/rollback, as it will cause a lot of confusion with some object graphs and it's not certain if it will be a viable feature (i.e.: more trouble than joy).

ok, this works perfectly for me! see any potential problems?

        private void btnCancel_Click(object sender, System.EventArgs e)
        {
            CustomersEntity c = (CustomersEntity)this.BindingContext[customers].Current;
            c.RollbackFields("SaveTest");
            foreach (OrdersEntity o in c.Orders)
            {
                o.RollbackFields("SaveOrders");
            }
            ((CurrencyManager)this.BindingContext[customers]).Refresh();
        }

        private void Form1_PositionChanged(object sender, EventArgs e)
        {
            CustomersEntity c = (CustomersEntity)this.BindingContext[customers].Current;
            c.SaveFields("SaveTest");
            foreach (OrdersEntity o in c.Orders)
            {
                o.SaveFields("SaveOrders");
            }
        }

No not at all

the databinding issues you had were related to IEditableObject and MS brilliance (that's sarcastic) in the databinding implementation: you have to call AcceptChanges() on the currency manager otherwise an object bound to textboxes can't update its data in some occasions...

Keep an eye on the situation in which the user removes / adds an order, but if that's not possible in the gui, don't worry