A working Clock 12

[spudmizer]

Is there a way to make a clock that works automatically, I have it now to were when you log in, it tells you the time you log in, but I want an actuall working clock.. Set to the computers clock !!!

 

[missinglinq]

I've used this for a while. Place unbound text boxs named txtOmega and txtDayRunner on your form and this in your code section:

Private Sub Form_Timer()
Me("txtOmega&quot = Right$(Now, 11) 'Time display
Me("txtDayRunner&quot = Left$(Now, 10) 'Date display
End Sub

This places a realtime clock that gives you hours/minutes/seconds and AM/PM. The txtDayRunner displays the current date and can, of course, be omitted if you're not interested in that.

Hope this helps.

The Missinglinq "It's got to be the going,
not the getting there that's good!"
-Harry Chapin

 

[spudmizer]

OK What Am I overlooking

On the form I put two unbound text boxes

txtOmega
txtDayRunner

Then I got to the Module section a put in a new module
Private Sub Form_Timer()
Me("txtOmega&quot = Right$(Now, 11) 'Time display
Me("txtDayRunner&quot = Left$(Now, 10) 'Date display
End Sub

But How do I run it
????

 

[missinglinq]

It won't work from a module; it needs to go in the code section of the FORM you have the text boxes in. From Design View of your form go to the menu and select:
View-> Code
and place the code here in the code section.

"Sub Form_Timer" is a function of a form.

The Missinglinq "It's got to be the going,
not the getting there that's good!"
-Harry Chapin

 

[oneeyedwilly]

it wouldn't work for me either until i added the line 4 (see below)of code and set the property of the forms timer interval to 1000, it works on 120; i believe the higher the number the greater the processor power is used

note the change in line 2: 11 became 9 as the last 2 digits of the date appeared in the box.

1) Private Sub Form_Timer()
2) Me("txtOmega&quot = Right$(Now, 9) 'Time display
3) Me("txtDayRunner&quot = Left$(Now, 10) 'Date display
4) Me![txtDayrunner].Requery
5) End Sub

If you hadn't cracked it already I hope this helps

 

[spudmizer]

Oneeyewilly,

That did the trick you get a star !!!

 

[Craig0201]

No.....don't!!!

All you are doing is clogging the CPU unneccesarily....There is a clock in the bottom right of the Control Bar in Windows.....

Also....."i believe the higher the number the greater the processor power is used" is incorrect. The lower the number, the greater the number of times the event fires. Hence the more often code runs => CPU usage increases.

Craig

 

[spudmizer]

Craig0201,

The Database take full screen mode so I needing the clock.
Also you are correct, sort of. THe number tells how many
1/1000 of a second to take of 1000 = 1 sec or
Run Code: Wait 1 Sec: Run Code: Wait 1 sec:
so the bigger the number the longer time between the code
so 10000 = 10 sec
So it would go Run Code: Wait 10 Sec: Run Code

However the faster the computer the faster it counts to 1000
so on a 266mhz processor ( slow clock speed) it would take about 1.25 second where on my Dual Athlon 1.9 GHz processor
it takes about .5 of a second

 

[Newposter]

This is all way too complicated. Just make two text boxes.

For one, the ControlSource is: =Now() and the Format is: hh:nn:ss
For the other, the ControlSource is: =Date() and the Format is: Long Date

That's all that is required to make an on-screen clock for an Access form. Newposter
"Good judgment comes from experience. Experience comes from bad judgment."

 

[TXRUSS2]

If you use:

For one, the ControlSource is: =Now() and the Format is: hh:nn:ss
For the other, the ControlSource is: =Date() and the Format is: Long Date

Won't this just display the date/time that you opened the form?

 

[spudmizer]

Yes

but it will not automatically update on its own on the form. The above formentioned way "rechecks" the computer clock every second !!! What would you do for a Klondike Bar?

 

[missinglinq]

I tend to agree with the first line of Newposter's first post; "This is all way too complicated." Many things about Access are still a mystery to me, although I've been writing code in QuickBasic 4.5 for a decade now (Visual Basic was produced by "marrying" QuickBasic 4.5 and an interface program called Tripod, and VBA is a subset of Visual Basic). But the code I posted in my first response to this question has been up and working correctly for several years now. I'm totally at sea as to Oneeyedwilly's need to requery the text box for the date; "requerying" is kind of what the form's timer does every time it "ticks". This "need" to make simple things complicated keeps cropping up again and again both here and on other forums; I just don't get it. What I do with 2 or 3 lines of code, someone else suggests needs 15 or 20 lines of code to do! Keep it simple! Someone recently wrote in that his company had changed the acceptable nomenclature for "business tavel" to "transportation" and he needed to be able to replace the former with the latter in a given field of a huge table. As this involved thousands of records, he was looking for a a method other than manually changing each record's entry. Someone promptly suggested SQL statement that involved lines and lines and lines of code to find each "business travel" entry and replace it with "transportation". I suggested going to the table, clicking on "Find and Replace" for the appropriate field, entering "business tavel" then "transportation" and clicking on "Replace All". Guess what? It worked! Keep it simple! Life's complicated enough without making it harder!

The Missinglinq "It's got to be the going,
not the getting there that's good!"
-Harry Chapin

 

[GDGarth]

missinglinq gets a star from me!

 

[missinglinq]

Thank you GDGarth!

The Missinglinq "It's got to be the going,
not the getting there that's good!"
-Harry Chapin

 

[RickSpr]

Missingling's original post is all that's necessary, except that he forgot to mention that you need to set the form's TimerInterval property.

Spudmizer is mistaken about faster computers counting to 1000 faster. Well, actually that's true, but setting the TimerInterval to 1000 is not the same as having the computer count to 1000. Whenever the form's TimerInterval is non-zero, the computer is counting anyway, one tick per millisecond. Setting the timer higher just means that the Timer event procedure will execute less often/fewer times.

However, while setting the TimerInterval lower actually does use more CPU power, the waste is negligible for all practical purposes. I suggest using 500 (1/2 second), to avoid the situation where the CPU clock changes a few microseconds after a timer tick occurs, with the result that the form is almost a full second late updating its display. With a setting of 500, the form will be less than 1/2 second late.

Requerying the form isn't necessary with Missingling's method.
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[missinglinq]

RickSpr is correct; TimerInterval property for the form is set to 1000. This procedure has been up and running so long I'd forgotten that detail. Thanks for the reminder.

The Missinglinq "It's got to be the going,
not the getting there that's good!"
-Harry Chapin

 

[jdegeorge]

Hi:

Put this code in your form's ON LOAD event:

Me!lblClock.Caption = Format(Now, "dddd, mmm d, yyyy, hh:mm:ss AMPM&quot
Me.TimerInterval = 1000

Put this code in the TIMER INTERVAL event:

Me!lblClock.Caption = Format(Now, "dddd, mmm d, yyyy, hh:mm:ss AMPM&quot


Then, but a label on the form called "lblClock" (without the quotes) and you're done.

Hope this helps!

Jim "Get it right the first time, that's the main thing..."

 

[judgehopkins]

Jim's method works great.

The other methods described cause "Calculating..." to flash on the status bar every millisecond.

For jdgeorge:

Judge Hopkins

http://www.psc.state.mo.us/adjudication.asp

There are only two rules for success: (1) Never tell everything you know.

 

[ToeShot]

Quote:
"This 'need' to make simple things complicated keeps cropping up again and again both here and on other forums; I just don't get it. What I do with 2 or 3 lines of code, someone else suggests needs 15 or 20 lines of code to do! Keep it simple!"


I don't think it is a matter of making things complicated. As pepole learn to write code, they see what works and what doesn't, and when they get something that works they may not look for a better way. I have done this many times, where I have code that works to the T, yet I will come across some post that my code would work perfectly for just to see someone made it even easier with only a few lines. I could have found a different way to do what I wanted to but since my first way worked I never bother looking for a shorter way to do it in code.

YES simple is good but somtimes simple is just hard to see



Dave
ToeShot@Hotmail.com
Today Is Tomorrows Yesterday. So Why Wait

 

[judgehopkins]

YES simple is good but somtimes simple is just hard to see

Amen to that!

Judge Hopkins

http://www.psc.state.mo.us/adjudication.asp

There are only two rules for success: (1) Never tell everything you know.