Jiwa

In particular of quotes, but I suppose generally.

User is in the habit of saving long quotes periodically. Sometimes they forget, or go on a break, or take a long phone call.

I can think of a few rules that one could come up with on 'when' to automatically save and order, and the choice would be user-dependent.

But assuming we want to auto-save, say every time a new line is added to a quote, I can trap LineAdded, LineChanged, LineRemoved OK, but is there anything I need to watch out for? Like calling save messing with the focus on the form?

pricerc wrote:But assuming we want to auto-save, say every time a new line is added to a quote, I can trap LineAdded, LineChanged, LineRemoved OK, but is there anything I need to watch out for? Like calling save messing with the focus on the form?

I have no doubt there will be some niggling issues you'll need to work around. Without actually doing what you're describing myself, I can't really tell you specifically, but preserving the field / cell which previously had the focus before the auto-save is one potential issue.

The other is calling the business logic save method triggers a read, and if the save was called whilst something was in the middle of doing something (perhaps another plugin, perhaps our code logic) then once control is returned the business logic will may be in an unexpected state.

To be a little more specific - and this doesn't apply to your use case, but to just illustrate potential issues - calling the Save method of the business logic whilst handling the OnAdded event of the quote line collection will cause issues especially when adding kits. This is why we have the AddInventoryItemEnd event - this is called at the very end of adding an item to the quote.

So - don't invoke save within a handler for OnAdded - use the AddInventoryItemEnd event instead. Any other issues as they emerge just bring it up here and we'll try to work out how to deal with it.

Mike

Thanks Mike.

They haven't asked for it yet, but I thought I'd get an idea of what's involved before suggesting it!

There is also the Properties changed collection to avoid unnecessary saves and I suppose you could add some sort of flag to the Generic Objects collection and set it in the events Mike described to avoid saving when you shouldn't which would also be a way of saving what control had focus before the save started.

After thinking about this some more, I think the appropriate flow is something which involves user alerts and/or confirmation.

Don't auto-save at all, but alert the user when a certain threshold has been reached so they can then decide when or if to save, and also after a period of inactivity of an unsaved quote, present a dialog stating a save will be performed due to in activity in 30...29...28 seconds - counting down with a cancel button on the dialog.

So, there are two aspects - one is an alert indicating they might want to save because they've "done a lot" since the last save (I'll call this an activity threshold - count of properties changed, lines added, removed or whatever), the other is a no activity modal dialog after a time threshold with unsaved changes pending (This I shall name the inactivity threshold - seconds or minutes since last time the user interacted with the quote form).

The activity threshold alert should not get in the way of the user so it shouldn't steal focus or anything - I've demonstrated desktop alerts on these forums before, and they would be ideal - just let them be aware of it so they can decide when to save.

The inactivity threshold alert should be a modal dialog and if that goes through to the keeper and auto-saves due to no response, a dialog then shown informing the user that you did that for them.

This way you don't have to worry about interrupting in an event handler some critical path of our code which may result in unwanted results.

This all now seems like it would be a good optional feature standard in the software that users could turn on.