arthur2 писал(а):Я считаю, что если я достаточно автиритетен для человека, что он мочла согласится с моим мнением, то доказательства не нужно писать.
Считай, кто ж тебе мешает. В программировании ты для меня несомненный авторитет. Но "не сотвори себе кумира"- гуру тоже ошибаются. И - как и простые смертные - они
тоже не любят своих ошибок признавать, тем более когда были столь категоричны. Надувание щёк не убеждает - убеждают довыды.
ты не понял. Я не хочу убеждать кого-либо, когда пишу сообщение. Либо чел доверяет и соглашается, либо не доверяет и не соглашается. Я надеюсь, что всё-таки первое. Если же чел доверяет, но не соглашается (как, видимо, ты) ему следует попросить этих доводов, аргументов и доказательств, и, в зависимости от степени занятости, он их либо получит, либо нет.
arthur2 писал(а):И кстати, не твоё ли кредо - ни кому не верить на слово и до всего доходить самому?
Первое - нет. Второе - да.
Когда, например, я спрашивал tyomitch'а, обязаны ли быть блоки таблицы экспортов в одной секции и он сказал мне, что не обязаны, я не требовал подтверждения этих слов и не проводил экспериментов, чтобы выяснить, прав ли был он.
arthur2 писал(а): А я и в школе с преподами спорил, и в институте. Причём - вот совпадение - почему-то именно с теми, кто для меня был авторитетом. Странно, правда?
Да нет, не странно, наоборот - логично. Какой смысл спорить с человеком, который и мнение которого для тебя ничего не значат. (Утрируя) Ты же не пойдёшь спорить с необразованным бомжем, доказывая ему, что земля всё-таки круглая?
Таймер с интервалом 100 мс, открывает файл, читает первую половину файла, делает DoEvents, читает вторую половину, закрывает файл.
Пример какой-то вымученый. Ну ладно, в такой ситуации апи-таймер не годится, и что? А в другой - очень даже годится. Используя твою логику, и так любимый тобой язык метафор (в котором ты плаваешь), можно сказать, что "туфельки у вас дрянь, потому что в них по крышам лазить не удобно". Если поднапречься, можно, наверное, и для стандартного таймера придумать ситуацию, после которой винду переставлять придётся.
1) В такой ситуации API-таймер годится. В такой ситуации нужно просто отключение таймера на время обработки тика.
2) Определимся с терминологией. Таймер, который останавливается на время выполнения события, назовём "ждущим таймером", а таймер, который продолжает тикать во время выполнения события - соотвественно неждущим.
Я вижу, что сейчас у тебя сложилось мнение, что у каждого вида таймера есть свои преимущества и недостататки. Причём тебе кажется, что у неждущего таймера больше преимуществ чем недостатков.
Если я правильно понял, тебе считаешь что:
1) У ждущего таймера больше безопасность но меньше применимость.
2) У неждущего таймера безопасность меньше (см. пример), но больше применимость.
Твоя ошибка заключается в том, что ты считаешь безопасность и применимость равнозначными факторами. Однако это неравнозначные факторы. Если таймер не пользовяет сделать что-то, это можно обойти. Если же таймер позволяет сделать что-то, но в случайные моменты может порушить всю программу - это нельзя обойти.
Ты не понимаешь, что всякая неконтролируемая рекурсия (неконтролируемая рекурсия - такая рекурсия, о которой известно, что чёткого условия прекращения рекурсивной ветки фреймов вызова нет) -- зло.
Например рекурсия:
- Код: Выделить всё
Public Sub A()
If Rnd > 0.5 Then A
Debug.Print "x";
End Sub
является неконтролируемой, т.к. её глубина носит случайный характер. Вполне возможно, что "повезёт так", что рекурсии хватит стека. А возможно и не хватит.
С твоим таймером так же. Будет ли рекурсия продолжаться будет зависить от того, успеет ли код до DoEvents до того момента, как произойдёт следующий тик таймера. Время выполнения кода так же носит случайный характер.
И в конце концов, приведите мне пример, где неждущий таймер действительно бы пригодился?Antonariy
Зачем вообще пользоваться ручным COM'ом - чтобы не плодить лишние ссылки, которые потом может быть будет не очень удобно удалять.
.
Что значит не нужно плодить лишние ссылки? Ручной COM отличается от автоматического тем, что все вызовы AddRef, QueryInterface, Release и все операции с ссылками нужно будет делать ручками, в то время как всё это мог сделать за тебя компилятор.
Ведь так и знал, что придерешься
Не важно, что там хранится технически, важно, что без привязки к этим сущностям объект в vb существовать не может.
1) А я даже знал, что после придирки ты скажешь эту фразу.
2) Исключительно важно, потому что твои слова могут ввести читающих в заблуждение.
Малознакомых с COM заставит действительно поверить, что объекты хранятся в переменных, а при Set a = b - клонируются.
Более-менее знакомых (как arthur2) - заставит поверить, что действительно хранится ссылка
на объект.
Тогда какой-нибудь чел подумает, что код
Dim a as Object
Dim b As Class1
Set b = new Class1
Set a = b
Set b = Nothing
Можно перевести в:
- Код: Выделить всё
Dim a as Object
Dim b As Class1
Set b = new Class1
CopyMemory VarPtr(a), VarPtr(b), 4
Ведь, если верить твоим словам, в объектых переменных хранятся ссылки на объекты? Если я из одной переменной скопирую [ссылку на объект] в другую переменную, то ведь всё должно работать?
И потом пойдут топики "Кто-нибудь знает, почему этот код не работает?".
