That's the programming logic that was in the back of my mind and was afraid would be the answer. I agree that the user may have already indicated "Yes, replace the contents" but keep in mind that the contents are on the clipboard and not visual at this point in time. It's not until the user says "Yes" do the pasted contents become visible and that's when the user could think "Oops, that's the wrong clipboard contents" or perhaps, "Oops, I guess I forgot to actually copy the contents that I wanted because what got pasted was something from 30 minutes ago." In either case you can always say that it was user error up to this point. But my concept of a possible bug in this matter is that I was always lead to believe that I could click CANCEL while editing any events without changing the events contents. I was always lead to believe that I had to click on SAVE to actually save the contents of an event to the database.
I suppose I could accept your analogy but then I'd like to see both the SAVE and CANCEL buttons greyed out whenever an event contents are replaced. The reasoning being as you suggested the user has already confirmed the set of updates. This would bring the user interface into the same logic as to what has already happened to the database. But at the same time, I think users might begin to question why both SAVE and CANCEL aren't available and there should still be a second chance to CANCEL. Can't wait to see what somebody from Support will say about this. I came across this when I stepped away from the computer for about 30 minutes and then returned to paste some clipboard contents over existing ones erroneously thinking that I had already copied what I wanted to the clipboard. As soon as I saw the new contents were actually something from the wrong family and from something else I had done over an hour previous, I though "Oops, I guess I thought I had already copied to correct contents to the clipboard." I thought I could click CANCEL and no harm would be done. I was wrong. It's an all too easy way to destroy data. Of course, the safety here is that once the user realizes the wrong stuff was replaced, he could always to back and re-copy the correct event to the clipboard, return to the scene of the crime, and paste once again. Brian in CA -----Original Message----- From: MikeFry [mailto:[email protected]] Sent: Friday, August 28, 2015 2:31 PM To: [email protected] Subject: Re: [LegacyUG] Possible Bug - Cancel does't cancel On 28 Aug 2015 10:40 PM, Brian L. Lightfoot wrote: > Here are the steps. > > 1.Open any event from any individual. > 2. Click on the left icon towards the bottom right which signifies > “Copy Event to Clipboardâ€. > 3.Close that event. You now have one event on the clipboard. > 4.Open up any other event on that same person or on any other person. > 5.Click on the right icon towards the bottom right which signifies > “Paste Event from Clipboardâ€. > 6.Legacy will open a window entitled “Replace Contents?†Click Yes. I'm not sure this is a bug as such. At this point, you've already said you wanted to make the change - and effectively confirmed it. At this stage, I'm guessing that Legacy has already updated the database, and (here's the crucial bit) confirmed the set of updates. If the confirm isn't done until the window is closed, then there would still be an opportunity to cancel any pending updates. If that works, and I know it does using .NET, then cancel would mean cancel. -- Regards, Mike Fry (Jhb) Legacy User Group guidelines: http://www.LegacyFamilyTree.com/Etiquette.asp Archived messages after Nov. 21 2009: http://www.mail-archive.com/[email protected]/ Archived messages from old mail server - before Nov. 21 2009: http://www.mail-archive.com/[email protected]/ Online technical support: http://support.legacyfamilytree.com Follow Legacy on Facebook (http://www.facebook.com/LegacyFamilyTree) and on our blog (http://news.LegacyFamilyTree.com). To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp
