Generally it's best to avoid square brackets. Difficult to answer your main
question though until you give some information about what I asked you
previously.

Regards,
Peter T

"zip22" wrote in message
...
[now()] did what I was looking for. I don't think it was a data type
issue.
The cells are set to "mm:ss.00"

range("A1") = Now
always rounds down to the second

range("A1") = [Now()]
gives me hundredths of a second

after looking into the square brackets, it looks like i can also use
[A1]=[Now()]

This looks like it will be more straightforward to code. Is there any
downside to using this instead of timer? (if I am happy with hundredths of
a
second)



"Peter T" wrote:

What's the purpose, IOW do you want a timer or do you want to know the
actual time, and in either case to what resolution.

FWIW Now() normally gets coerced to one second in cells due to the Date
type
conversion. However it's actual resolution is to 1/100 sec (at least in
my
light testing) so maybe simply -
dim x as double
x = [now()]

Despite the timer bug Rick mentioned, I've never had a problem with it.
So
for quick testing where a resolution of about 1/20 sec is enough I use
VBA's
Timer function. For higher resolution there are various APIs, eg
GetTickCount (that also has a rollover but it's never bit me!).

Regards,
Peter T



"zip22" wrote in message
...
Excel's Now() function has a resolution down to hh:mm:ss.00 where the
VBA
Now
function only has hh:mm:ss. I need the accuracy of the excel now
function
in
a macro but

application.worksheetfunction.now

does not work. My workaround at this point is referencing a cell with
"=now()" in it, but before I reference it I have to use
application.calculate
so it updates. Is there a better way to do this?


.