deprongmori wrote:binnerup wrote:Can I get one of you to clear the log just before doing this, and then post the log?
The list view should maintain the position, no doubt about that.
Is this a root title or a title that is a child of something else?
I’m still looking for a test case to capture for the “context shift while editing a child record of a box set and inserting a disc”. I’ve run into the problem maybe 3-4 times where the parent is updated with the disc info instead of the child after “Do you want to save your changes?” prompt. I’m updating a lot of records currently, so I should be able to find another test case soon.
Hopefully, the generic problem of lost context on top-level records after update from server is easily repro’d, especially with the log posted by Michael.
The other thing I would love to see fixed is the current record remaining in view in the sidebar after a delete or sort operation. Currently context (and sidebar view) always bounces to the top (rather than next or previous record) on a delete, and the sidebar view bounces to the top or bottom (rather than current record) although in this case the user context is retained — only the view of it is lost in the sidebar. Re-navigation becomes tedious in a local database of thousands of records.
OK, I found a related situation and captured it.
In this case, I have a top-level Title (barcode 715515011624, "The Lady Eve") which lacks Disc Chapters/Episodes (but does not lack Disc-ID). I edit the record to inherit Cast&Crew but do not Save it yet. I then insert the disc for the Title in order to read Chapters/Episodes. Once I insert the disc, I am prompted whether I want to Save my edits. When I reply "Yes", my user context is lost, and the sidebar jumps to the first record in the sorted database. I suspect that what is going on here is that the app is looking for a matching Disc structure (not Disc-ID, as that is already present on my current record before I started editing it). Not finding a match, it drops me at the head of my sorted database.
My speculation based on this is that in the case I described earlier where the child Title disc info edits are written to the parent Title instead is as follows (which is why I've been having such a hard time finding new cases to repro the problem):
1) In a box-set, the parent Title has the Disc Chapters/Episodes mapped, but the child Titles do not
2) When I edit the child Title in such a case, and insert a disc after I have edited and not yet saved my edits, the context shifts to the parent Title, and the data s saved to the wrong record (the parent Title rather than the child Title). In a non-box-set-case, the app remains positioned on the current record as the Disc-Chapter/Episode structure was not matched on a different record, so the edited data is written to the correct record.
I'll see if I can find (or create a case) to repro the "write to wrong record" scenario.
In the meantime, here are some screen captures of the steps, and the associated log of the operations. (Note, the displayed imaged is the third of three -- after the save.) I know my description may be a bit confusing, so please let me know if you have any questions.
File Attachment(s):
TheLadyEve_Title_State_Before_Disc_Insertion.png (364kb) downloaded 3 time(s).
TheLadyEve_Title_After_Modify_And_Disc_Insertion.p (363kb) downloaded 0 time(s).
log.txt (680kb) downloaded 3 time(s).
deprongmori attached the following image(s):
