Updated the SKU data entry for Activities that require it. For example, repack activities. When the general TimeClock display overhaul was undertaken, the SKU data entry was overlooked so it didn't work within the same framework anymore. This has now been corrected and works within the same framework as the rest of the data entry mechanisms.
The checklist function in the TimeClock was adjusted slightly to address a problem with checklists that don't require an additional number (like a bin or a forklift). There was an error where such a checklist would not proceed with the correct questions as the checklist was being loaded after the additional number was entered. This is primarily in support of having a "health" checklist - something that workers fill out prior to the start of their shift.
The fingerprint scan log update mechanisms were updated to support longer MODIFIER values. This was preventing Workers from punching in, stalling right after confirming their fingerprint scans. Updated same field in other tables.
Fixed an error where the punch wasn't being recorded because of an internal IntToStr error based on the Location not being a valid location. Added a default of '900' in this case, and more error checking.
Added a \"clear keyboard queue events\" step to the ResetTimeClock and also the ProcessPunch routines to hopefully catch the cause of the above - people entering their checklist so fast that the clock is reset before the punch is fully recorded. I don't think the keyboard repeat function is enabled for TimeClocks configured to run as TimeClocks, so they're just tapping 0 indiscriminately, which should still work and not get tripped up like this.
Added a block to prevent entering worker numbers starting with 0. No clue why this wasn't done 20 years ago?!
Minor change to keep flushing the keyboard queue when entering the Password screen. Seems some keyboard input was being carried over to the next screen. Will add more KeyboardFlush calls if it turns out this is helpful elsewhere.
'Supervisor Functions' now appears at the top-right of the Supervisor Functions menu once again.
Added an extra fail-safe to the worker history function so that it always has at least a division=0 when running the query. Seems it somehow lost its division value if the TimerCheckIn function was run while the Supervisor Functions were displayed.
Added some more logic to try and figure out why the TimerCheckIn function was run while the Supervisor Functions were displayed. Was not suppose to happen unless the screen timer was disabled due to too long of a wait.
Exception handling changed to restart app after 2 failures in 10 minutes rather than 5 failures in 1 minute. Something got kerfuffled on one of the VF TimeClocks and with all the database timeouts and reconnects, the exceptions were 5 minutes apart. Not quick enough to trigger the restart, but slow enough to generate a steady stream of error notifications.
Default window title changed to 'TimeClock'. Eventually this is set to 'TimeClock <#> <name>' but for some reason it was appearing as 'TCMain' during the init. For, like, the last 20 years. Go figure.
Added version and elapsed time info to the TimerCheckin log so I can better gauge performance issues, and because logs created before a server reboot don't have any other version information in it after midnight.
Minor adjustments to the log to show time remaining before the next Check-in when a check-in is requested but the check-in delay has not yet elapsed.
Other log formatting to keep up with the [ABC] style present everywhere in the log. Fingerprint Scanning and Phase lookups were the latest culprits this time out.
Invalid key entry was removing the worker number from the process, but it seems sometimes the process continued without the worker number! Not so good. More careful now to simply ignore invalid keys without interrupting anything. Seems that fingerprint scanning as part of its normal course of operations would generate key presses to continue the process along, and thus get messed up when the worker number was dumped along the way. Oops...
More logging with fingerprint scans, particularly when scans are not successful.