Opening Start Menu

  • Thread starter Thread starter Anando [MS-MVP]
  • Start date Start date
Newsgroup said:
Previously, when I went into my start menu (bottom left corner), when
I hovered over a folder it would expand to let me see what's inside.
Suddenly, now every-time I have to press the folder in the menu to
get it to expand to show me the contents inside. How do I get it to
a state where hovering automatically expands the folder?

Thanks.
Click to expand...

Would you mind fixing your clock you are posting from the future. According
to your headers, you're in Lahore, and your time zone is correct, but the
stamp is sixteen hours ahead of what it should be.

Post dating is considered the Usenet equivalent of queue-jumping, and
therefore extremely rude. You wouldn't like it if someone cut to the front
of the queue in the supermarket or bank, so why should Usenet be any
different?

This is in your own best interests as many people (myself included) will not
respond to post-dated messages (except to inform the poster that they need
to adjust their settings). Also, many servers will strip post dated messages
as it's a tactic used by spammers to ensure their messages receive top
billing (as it were).

Once you have made the necessary adjustments, I'm sure someone will be more
than willing to assist you.
 
Hello Miss P.
The whole thing about timing maintained by client sounds very stupid!
I think that this task should be done by the server.
Perhaps designers had a reason to make it depend on the client?

George
 
Yeah, there is no guarantee of delivery time. Image if you see the last, second, fourth, third, first in a thread - as you may have with server side times.
 
Previously, when I went into my start menu (bottom left corner), when I
hovered over a folder it would expand to let me see what's inside.
Suddenly, now every-time I have to press the folder in the menu to get it to
expand to show me the contents inside. How do I get it to a state where
hovering automatically expands the folder?

Thanks.
 
George said:
Hello Miss P.
The whole thing about timing maintained by client sounds very stupid!
I think that this task should be done by the server.
Perhaps designers had a reason to make it depend on the client?

George
Click to expand...


Huh?! The time is localised for the viewer's zone but, if the poster's clock
is off, the viewer's server cannot correct the discrepancy. Thus the time is
dependent on the posters clock being correct. If the poster's clock isn't
correct, the time won't be correct.

Is that easy enough for you to understand?
 
Miss Perspicacia Tick said:
Huh?! The time is localised for the viewer's zone but, if the poster's
clock is off, the viewer's server cannot correct the discrepancy. Thus the
time is dependent on the posters clock being correct. If the poster's
clock isn't correct, the time won't be correct.

Is that easy enough for you to understand?
Click to expand...

Actually, George was suggesting that when a NNTP client submits a message to
the server, it should be the server that sets the Date: NNTP header
overriding what the client may have put for the Date: header, which is
something that is allowed for by the RFCs. What isn't allowed for by the
RFCs is for the server to change the Date: header on a message handed to it
by another server.

It isn't the first time I've heard the request, nor will it be the last. I
am not sure if it will be implemented. Not all servers on USENET behave the
same way with regards to the Date: field. Some will over-write it, some
won't.

John Eddy
Microsoft Newsgroups Administrator
 
Miss Perspicacia Tick said:
Huh?! The time is localised for the viewer's zone but, if the poster's clock
is off, the viewer's server cannot correct the discrepancy. Thus the time is
dependent on the posters clock being correct. If the poster's clock isn't
correct, the time won't be correct.

Is that easy enough for you to understand?
Click to expand...

Yes it is... In case that we have multiple servers all-over the world,
synchronization may cause delays. In our situation, the clients adds a
timestamp + time-zone to the message.

My original idea was that the server can use a time stamp from the moment
when it started receiving data from the client. This should be equal to the
client's time, unless the client's clock is wrong (time-zone is corrected
automatically). In this scenario the time should be correct even if there
are network problems.

Thank You for the information!
 
Back
Top