Darned clock watchers!

[Joe Chasan]

On Thu, Dec 11, 2008 at 07:53:33PM -0500, Brian K. White wrote:
> 
> ----- Original Message ----- 
> From: "Joe Chasan" <joe at magnatechonline.com>
> To: "filePro" <filepro-list at lists.celestial.com>
> Sent: Thursday, December 11, 2008 1:16 PM
> Subject: Darned clock watchers!
> 
> 
> > 
> > on Unix, in a terminal session, i need a way to constantly display system
> > time (hms) on a screen.
> > 
> > i can put it on screen and have a loop to display or video-sync either
> > @entsel or @wef - problem is that while in middle of typing characters
> > in a field, i can't force update.
> > 
> > Background:  timeclock application - users have to swipe a card or type
> > some info to clock in/out - they watch until last second possible to get
> > whatever maximum benefit is is for themselves - some of them type info into
> > field and are waiting until clock strikes certain time before pressing 
> > <enter>
> > 
> > i can't see it worth replacing all input fields on screen (even though
> > there's only a few) with inkey or waitkey loops and concatenating to
> > reassemble data back into fields, but maybe i'm overthinking this and
> > missing some obvious method.
> > 
> > i also note <DRAW> key code does not force update of time, i guess that's
> > an fp design decision.
> > 
> > FWIW, the server is syncronized to an NTP server on internet - most users
> > are on PC's, but windows time syncronization is not as reliable so
> > apparently just looking at windows clock wasn't doing it for them.
> 
> 
> That is retarded.
> Can you convince the employer to coarsen the resolution to whole minutes?

> Then the users can walk up and puch in/out any time and it doesn't matter what second they do so. They either get paid for that whole minute, or they don't. There would no longer be any point to typing and then waiting to hit enter or escesc unles they do it whole minutes in advance, which seems like it might cause friction with other users needing to clock in/out.

its not like the employer cares about seconds - its more that X is scheduled
to work from 9 to 5 and if they clock in at 9:05 a few times it will hurt
their pay and they complained about not seeing the time on the screen until
after the clock in/out procedure puts a time-stamp to it - it is not the 
time of the PC (which is already displayed naturally by windows) that counts 
but the time of the unix server that filePro uses so if their PC clocks are 
off by 10 minutes and filepro clocks them in/out at a time that has nothing 
to do with the time that windows shows they are confused.

would it be easier if i showed a clock with no seconds?  maybe, i'd certainly
have to update display less, but the same issues occur - i'd have to have
control to update it or a user might stare at 4:59pm for 20 minutes like 
an idiot.

there is little contention with other users - there is one station where
users can swipe cards into a bar code scanner and for this, it's easy - can
loop/display @wef - the scanner data is taken as a whole field and forces 
leave of field so there is no problem keeping control with @wef/@wlf.  the 
problem is for the users that clock in/out from PC's manually by keying 
in info.

> However, you should be able to do this with inkey and a tight loop.

thats pretty much what i thought i'd end up having to do if i couldn't
figure this out a different way - but the inkey/loop/field-build works 
best when there is only one field on the screen (which _do_ i have in 
some cases) and also, more importantly, makes it very difficult to 
back-space, arrow back and forward, edit, etc.

> 
> Something like this:
> 
> ...
> GOSUB inclk  'clock-input loop
> log the user in/out according to UI
> end or goto top or whatever
> ...
> inclk:
> sleep "100"
> keystroke = inkey , UI = UI + keystroke
> if keystroke or UI co magic submit/finish key or sequence, RETURN
> if @tm eq TM, GOTO inclk
> TM = @tm , display, GOTO inclk
> 
> 
> UI is the acumulated user input in screen displayable dummy.
> TM is the last known time, not displayed, put @tm on the screen.
> 
> Instead of the display command, which redraws the whole screen and may flicker the screen unaesthetically, maybe do 2 show statements to redraw just @tm and !UI
> 
> Result, hopefully: Ten times per second you check for keystrokes and to see if the time ticked over to a new second. Once per second you update the display, which includes !UI and @tm 
> Inkey does not block like waitkey or input or @update. Inkey just immediately collects a keystroke if one has been entered, or collects nothing, but either way it operates and finishes and processing proceeds to the next step instantly.
> 
> Completely off the cuff and untested.
> 
> -- 
> Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
--
-Joe Chasan-                           Magnatech Business Systems, Inc.
joe - at - magnatechonline -dot- com   Hicksville, NY - USA
http://www.MagnatechOnline.com         Tel.(516) 931-4444/Fax.(516) 931-1264