The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
Accounting for over-caffienated users
Posted: 19 Dec 07 8:32 AM
|
I just wanted to pass along to everyone a tip that we oncovered here recently. Every once in a while we would get a user complaining that they got an error when they added a new contact. The error was a primary key violation - you can't add the same contactid into the contact database. My co-worker spent hours trying to recreate and figure out where this error was coming from. We finally found a way to recreate the problem. If you quickly double click on the OK button the system will fire multiple instances of that process. First one saves the contact record and then the second one tries to save the contact record and guess what - you get the error.
So what was the solution (besides cutting off the user's caffine level  ) ... the first line after the cmdOK button is pressed is:
cmdok.Enabled = False
So if the user double clicks the system won't register the double clicks.
Hope this helps someone else out there.
Happy holidays. |
|
|
| |
|
Re: Accounting for over-caffienated users
Posted: 28 Dec 07 12:54 PM
|
Re-enable? What for? After that user learns that they have to re-enter Slx every time they need to enter a new contact, well, then they'll slow down without being told. This is called 'interactive deductive learning'.
Now what do we do about the user who attempts to enter "$$34..045" in a numeric edit box?
Have a Happy New Year !
 |
|
|
| |
|
Re: Accounting for over-caffienated users
Posted: 03 Jan 08 2:05 PM
|
Class: Instance
Properties: Lock/Unlock. A private variable set to either 0 or 1 for unlocked or locked. (I didn't use a boolean for a reason but I can't remember it)
In every possible "double" operation I place a Instance.Lock, do some editing, then an Instance.Unlock. This prevents any duplicate calls to that routine to be processed.
Our problem that caused this to be built? A datagrid edit screen has multiple record types that sometimes share columns and needless to say this screen takes a long time to load in comparison to others. If I didn't place a lock the screen would open twice. The first instance appeared to work but would hiccup on ocassion and the second instance was completely useless as none of the form event code fired. I try to teach the importance of patience when it comes to running this app but it isn't always remembered when deadlines approach.
I'm getting to the point where this class is used in everything. It's tedious but it solves the problem when you need to keep the UI from processing multiple events. |
|
|
|