Решил не плодить свою тему, т.к. вопрос такой же.
Ну например
1) есть ProgressBar и по достижении MaxValue хочется задержать взгляд юзера на секундочку
ЗАДЕРЖКА НЕ КРИТИЧНА
2) или например секунда-другая жизненно необходима для переиниализации чего-нибудь, чем VB управляет.
ЗАДЕРЖКА КРИТИЧНА

По жизни пользовался своей ф-цией типа той что в предыдущем посте.

По сути тоже что и в предыдущем посте.
Слабое место этого кода в
Or (Timer < ltime)
Но если этого не делать, то в полночь можно зависнуть. (верояность мала, но один раз "попал")

"Поумнев", решил использовать чего-нибудь "поумнее".
И накололся похоже. Работать то оно работает, но похоже , это ощущения, но кажется это так... что-то портит в системе.
Т.е. если этот Sleep раз сработал, то у меня перестает работать нек. фича(независимая): С++ программа которая следит за активностью установки plug_and_play драйверов(должна выйти по окончанию процесса установки), уж не знаю как устроена, но ведет себя некорректно и начинает выходить раньше времени. Причем программа со Sleep() уже давно отработала и закрыта, а последствия не устраняются до перезагрузки.

Т.е. чутье подсказывает что Sleep() лучше не использовать? Да и на Microsoft есть намеки на то что не стоит.
http://msdn.microsoft.com/en-us/library/ms686298(VS.85).aspx

Остается вариант
If (Timer - ltime > m_pause) Or (Timer < ltime)
полночь конечно не критично если ЗАДЕРЖКА НЕ КРИТИЧНА
но если это случай ЗАДЕРЖКА КРИТИЧНА может таки глюкануть
Если скажем запущено 5-10 циклических процессов, в каждом из которых применяется пауза в 2-3 секунды между циклами по 1-2минуты, то вероятность что в полночь кто-то попадет в паузу и пауза не сработает таки не нулевая.

Чего б придумать понадежней для задержки?

Shocker.ProДмитрий, если я правильно понял, ты уперся в отсутствие возможности работась с миллисекундами в DateAdd
О DateAdd я как-то вообще не думал.
Да можно и Вашу использовать, можно и мою DoSleep допилить.
Например
запоминать положительные (Timer - ltime)
но перед этим проверять
(Timer < ltime)
если вдруг сработало, то выход из цикла и запуск другого такого же цикла на оставшееся время.

Для визуальной задержки по достижении макс. значения ProgressBar (для чего мне сейчас это понадобилось) мне даже моей
Sleep(1000) с головой хватит, а эффект полуночи, ну не будет задержки, не критично..инсталлятор не сломается.
Даже миллисекунды не нужны,можно было и не извращаться с делением на 1000.

Странно другое, что не существует нормальной корректной штатной функции VB или API, чтоб не думать как придумать с точностью константы или с обходом эффекта полуночи.
Потому как API-шная Sleep() точно глючная, и кажется еще на Висте не работает. Как только заменил на свой примитив, "спецэффекты" с влиянием на другие программы прекратились.
VOID WINAPI SleepBe careful when using Sleep in the following scenarios:

Code that directly or indirectly creates windows (for example, DDE and COM CoInitialize). If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. If you have a thread that uses Sleep with infinite delay, the system will deadlock.
Threads that are under concurrency control. For example, an I/O completion port or thread pool limits the number of associated threads that can run. If the maximum number of threads is already running, no additional associated thread can run until a running thread finishes. If a thread uses Sleep with an interval of zero to wait for one of the additional associated threads to accomplish some work, the process might deadlock.

For these scenarios, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than Sleep.
Спасибо майкрософту конечно за заботу, но MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx слишком кажется наворочены, чтоб пытаться их осознать с т.зрения таких простых задач как задержка в VB-коде.