LOL
On Fri, 14 Oct 2016 07:35:22 -0700, Kirk Brooks wrote: > Chip, > That's one of the places where management comes into play with programming. > My experiences have been there's no joy in attempting to program in > management's assumptions of user behavior. Happens to me frequently: > > boss: "set it up so this and that are required for saving this sort of > record. No exceptions!" > > me: "OK." > > -- the day these changes go live -- > > boss: "Why can't I save this record?" > > me: "Because this and that isn't fully entered." > > boss: "But we need to override that sometimes." > > me: "Ok, but you said 'no exceptions.'" > > boss: "this isn't an exception it's an override." > > me: "I didn't think of that." > > Apologies to Scott Adams. > > > I don't want to have to care about what management thinks it's doing. So I > tend to let such conditions be controlled by a preference management can > set and write the code to work regardless of which is chosen. > > In the case you describe management can rail about completing data entry > quickly all they want and that won't prevent someone from starting a > transaction and getting distracted. In a case where those data are really > critical I'd not let any user lock the record but collect proposed changes > in variables, submit the variables for saving and do the validation and > error checking. If it's all good then load the record and write the > changes. > > On Fri, Oct 14, 2016 at 7:11 AM, Chip Scheide <4d_o...@pghrepository.org> > wrote: > >> yes. >> But then : >> - if the 1 user changed a value, everyone probably needs to know that >> the record is being modified and whatever value(s) are displayed may >> not be correct. >> - if the 'touch' (in code) is only a lookup - Read Only is your friend >> :) >> - users learn to finish, after being <redacted> yelled at </redacted> >> told a few times to complete what they were doing :) >> >> On Fri, 14 Oct 2016 04:20:58 -0700, Kirk Brooks wrote: >>> The problem with starting transactions >>> from an input form in such a way that they are finished by user action >>> (enter or cancel) is everything you 'touch' within the transaction gets >>> locked until the user is done. >> ********************************************************************** >> 4D Internet Users Group (4D iNUG) >> FAQ: http://lists.4d.com/faqnug.html >> Archive: http://lists.4d.com/archives.html >> Options: http://lists.4d.com/mailman/options/4d_tech >> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com >> ********************************************************************** >> > > > > -- > Kirk Brooks > San Francisco, CA > ======================= > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
