«Идея-то хоть» как раз неверная. Совсем.
Смысл в своём ML — затормозить выполнение кода, заблокировать его внутри нужной процедуры пока не произойдёт что-то. Заблокировать UI — совсем другая опера, и решается не своим ML, а Disable-ингом.
Ну, я вижу только одну граблю - в момент, когда обнуляется системное время.
Вот такой грабли как раз нет. Чтобы понять это, попытайся объяснить мне природу проблем при обнулении счётчика тиков.
Есть другая проблема со временем: если на момент вызова функции счётчик тиков будет иметь значение из промежутка от (0x7fffffff - SpecifiedDelay; 0x7fffffff], то тебя ждёт Overflow со стороны VB. Если бы это был код на С/С++, произошло бы переполнение, которые не нарушило бы арифметику. Решения: кривое — отключить в настройках оптимизации проверку переполнений, правильное — складывать не VB-шным оператором сложения, а чем-то внешним, например функцией
InterlockedExchangeAdd.
Даже если ты сделаешь такую замену, от оператора >= тоже придётся избавиться, ибо он сразу же выкинет тебя из цикла, хотя время ещё не настало.
Другие бывшие грабли: указание идентификатора таймера. При указании идентификатора, если таймер с таким идентификатором уже был, произойдёт замена, вместо добавления. С учётом того, что функция mySleep может быть вызвана из самой себя, это плохо.
Другие бывшие стилевые грабли: использование глобальной переменной со ссылкой на экземпляр формы.
Принципиальные грабли: при обработке какого-то сообщения обработчик породит свой ML, который случайно обработает твоё таймерное событие. Тогда тебе придётся ждать нового таймерного события, но и его может кто-нибудь съесть.