Неожиданно забыла, как в VBScript разделяются параметры при вызове функции =_= Вроде бы запятой, но и пробел вполне логичен, нет?

Бугага. оказывается, происходит следующее. После попытки перечислить объекты, возвращаемые запросом к WMI, устанавливается код ошибки, но самой ошибки не происходит. Иными словами, «On Error GoTo hError» не срабатывает, переход на метку не происходит. Но если сделать «Err.Number», то это свойство оказывается ненулевым (438, «Object doesn't support this property or method»). Вот тут и срабатывает обработчик ошибок. Если там же сделать что-то вроде «Err.Raise 51», то программа реально упадёт с сообщением от рантайма. В самом VB6 это случается, если, скажем, в какой-то функции перехватить ошибку, но не сделать Err.Clear. В таком случае код ошибки будет виден снаружи с тем же эффектом. Но, как правило, это не проблема, поскольку код ошибки снаружи проверяют только если она гарантировано передаётся наружу (например, полностью отключается перехват, либо после перехвата делают «Err.Raise» с новыми значениями), а если всё остаётся внутри, то и снаружи это не интересно. Вооот. Если не проверять код, то дальше WMI выдаёт информацию, но всё с теми же проблемами, с которыми я столкнулась ранее. Мне не понятно только одно: почему оно вдруг поломалось и даже после перезагрузки работает так и дальше.

Похоже, проблема в WMI под Вайном. До обращений к нему обработка ошибок идёт в VB6 проге нормально. После – сходит с ума.

Происходит что-то странное. Теперь, при возникновении необработанной ошибки в VB6 программе под Вайном, рантайм выдаёт сообщение об ошибке и спокойно продолжает выполнение. Раньше оно хотя бы падало совсем, а теперь вот такие чудеса OO

Продолжаю атаковать WMI в Вайне. Только что всё сломалось, и класс Win32_NetworkAdapterConfiguration вообще перестал что-либо возвращать. Но это ладно. Выяснилось, что у меня в коде срабатывает обработчик ошибки, хотя для отладки я закоментировала обработку ошибок (то самое «On Error Resume Next»). Нигде выше ничего подобного нет, но программа не падает с сообщением от рантайма. Решила вписать «On Error GoTo 0», тоесть принудительно отключить обработку ошибок, всё начало падать, как и должно. Я не знаю, кто виноват, но в VB6 прогах в Вайне включен пропуск ошибок с самого начала, что явно не то, что ожидается.

WMI в Вайне – это что-то с чем-то! Прямо сейчас я пытаюсь приспособить работающий под виндой код к работе под вайном. Проблема настигла меня при работе с классом Win32_NetworkAdapterConfiguration. Некоторых свойств в Вайне нет, некоторые свойства возвращают не массивы строк, а массивы, в каждом элементе которого содержатся массив строк. При чём, судя по всему, это одинаковые массивы. Зачем? Почему? Нет ответа...

Самое страшное, что я видела в программировании – это когда один чувак читал код, переводя на русский язык всё встреченное и осмысливая полученное.

Гуглю, как использовать CommandLineToArgvW(). Натыкаюсь на статью Рэймонда Чена. Понимаю, что вечер будет томным =_=

FB заставил вспомнить богомерзкие Common и Shared == А ещё меня задолбало обязательное Declare во всех модулях при том, что Public и Private в объявлении функций и так прекрасно работают ==

В VB есть два вида деления: обычно и с отбрасыванием дробной части. Ну тоесть:

3 / 2 ==> 1,5
3 \ 2 ==> 1

Сегодня не могла понять, почему у меня при делении двух чисел вместо 255 получается 260. Вроде бы всё должно быть правильно. Были сомнения в точности одного из чисел, но там тогда получилось бы 256 или 254, но не такая разница. Поэкспериментировала, выяснила, что перед делением у чисел отбрасывается дробная часть, потом они делятся, и дробная часть отбрасывается снова. Вот и получилось. Честно говоря, обычно делю только целые числа и о такой особенности каждый раз очень хорошо забываю =_=

VB6 любит твипы. OLE любит химетрики. GDI любит дюймы. Чтобы получить размер картинки в пикселях в StdPicture, нужно всё это конвертировать в миллиметры, потом в дюймы, потом узнавать, что там с DPI у экрана, и результат округлить. Круто же.

Нашла в своей старой программе актуальное применение GoSub/Return.

Вчера всю ночь воевала с интересным глюком в своих программах. Короче, есть программа CloudIM, которая использует всякие дропбоксы в качестве транспорта. Когда приходит сообщение, в трее начинает мигать иконка, как других мессенджерах. Кроме того, есть одна утилита, которая запускает на фоне другие утилиты и каждый этап показывает мигающими иконками в трее. Всё это прекрасно мигало в Windows XP, но оказалось, что в Windows 7 просто показывается первый «кадр». Сначала думала, что это как-то связано с тем, что на машину с Нанами, где запускались эти проги, я хожу по RDP, но и с монитором ничего не изменилось. Потом предположила, что это специально сделано в системе, чтобы программы не раздражали пользователя. Короче, начала разбираться. Для начала сделала простую программу, которая показывает окошко и при этом выводит иконку в трэй, а при закрытии окна – убирает иконку. Так же в окне была кнопка, которая меняет иконку на следующую, а сами иконки программа брала из стандартных (те, что выводятся в окнах сообщений вроде красного крестика – их можно специально получить, чтобы в твоей программе они соответствовали тому, что выдаёт система). Что интересно, программа работала нормально. Даже если зажать кнопку энтером, иконки всё равно очень быстро менялись, так что борьбу системы с раздражителями я отбросила. Тогда перешла к натурным испытаниям. Взяла ресурсы у CloudIM и начала использовать иконки оттуда вместо системных. И тут с самонирисованными иконками всё сломалось. Если очень упростить картину, то сначала программа добавляет иконку в трэй через Shell_NotifyIcon() с параметром NIM_ADD. А когда нужно мигать, эта функция вызывается с параметром NIM_MODIFY и манипулятором нужной иконки. Сами иконки заранее грузятся из ресурсов через LoadImage() с указанием размера 16x16 (вдруг есть другие). Так же проверяется, что у нас за система, и если что-то до Windows 2000, иконки выбираются 16-цветные. В итоге программа загружает две иконки и попеременно рисует их в трее. Но, как я уже сказала, всегда рисовалась только первая, а вторая – никогда, хотя куча тестового кода показывала, что все вызовы происходят, и даже в самом окне иконки рисуются нормально. Попутно выяснилось, что если иконка грузится с диска функцией VB6 LoadPicture(), то всё рисуется нормально, а вот LoadImage() даёт такой сбой. Впрочем, потом оказалось, что если LoadImage() вызвать с параметром LR_LOADFROMFILE, то происходит та же проблема. Что-то было не так с самой LoadImage(). Я проверяла кучу кода, поскольку она вызывалась не напрямую, а через прослойки. Попутно попробовала LoadIcon() (она грузит только иконки и только размера 32x32, растягивая и сжимая всё, что не соответствует, если альтернатив нет). Попутно я попыталась не подписывать екзешник, ибо в описании Shell_NotifyIcon() что-то было про подпись, но, правда, в контексте идентификации иконки не по паре «манипулятор родительского окна – ID иконки», а по GUID. Но и это не помогло. Потом обратила внимание на сами иконки. Дело в том, что CloudIM использовала две иконки. В одной (первый кадр) был конвертик 16x16 в вариантах 16 цветов и 256. А во второй была пустота (конвертик появлялся и исчезал при анимации), поэтому там было два изображения: 16x16 и 32x32 с одним только прозрачным фоном. Почему такие размеры? Возможно, я хотела заюзать пустоту где-то ещё, но не стала. Но главное, я сделала обе картинки двухцветными. Чтобы пустота не занимала лишнее место. Вот где-то тут всё и ломалось. Windows 98 прекрасно чередовала 16-цветную картинку и 2-цвентую. Windows XP прекрасно чередовала 256-цветную картинку и 2-цветную. А вот Windows 7 сломалась. Вывела первую, а вторую рисовать отказалась, причём ошибок функция Shell_NotifyIcon() не возвращала никаких. Просто в трее оставалась старая иконка. После того, как я пустую иконку привела в соответствие, всё начало мигать как полагается. В принципе, я сразу подумала, что что-то не так с иконками, и даже заметила различия в форматах, но меня смутила вторая программа, где никаких пустых иконок не было, все иконки однозначно в одном формате, ибо кадры выглядят одинаково, только один залит тёмным цветом, а второй – светлым. Там даже все иконки 16-цветные! Это мне и подпортило отладку. Поэтому, разобравшись с первой программой, я перешла ко второй. Проверила тамошние иконки, потом добавила их в ресурсы тестовой программы. И внезапно оказалось, что всё прекрасно мигает! Я запустила ту самую программу, и оказалось, что там тоже всё прекрасно мигает! Секрет оказался в цветах самих иконок и в длине этапов, которые они обозначали. Как я уже сказала выше, на каждом этапе запускалась утилита, которая что-то делала, а иконка показывала, что она что-то делает. Первый этап, как правило, занимал больше всего времени, а последующие выполнялись заметно быстрее. На машине с Windows XP для утилит работы было больше, а на Windows 7 – заметно меньше. Поэтому последующие этапы на Windows 7 проходили быстро, часто – быстрее времени смены кадра, а оно было примерно 250 мс. с поправкой на тормоза. Тоесть по факту иконка мигала только на первом этапе, а на последующих появлялся первый кадр и исчезал. Что же не так с первым этапом? Если посмотреть на стандартную 16-цветную палитру, то можно заметить там пары цветов типа тёмно-зелёного и светло-зелёного. Все пары образуются подобными значениями в разных компонентах. Тоесть чисто по цифрам там всё сбалансировано. Просто глаз разные цвета воспринимает по-разному. И если отличие светло-зелёного от тёмно-зелёного видно сразу, то тёмно-синий от светло-синего отличается не так разительно и в зависимости от настроек дисплюя может вообще не бросаться в глаза. И по счастливому стечению обстоятельств первый этап обозначался именно синим цветом. Тоесть оно мигало, но это было не заметно. Кстати, пока я испытывала вторую утилиту, внимательно вглядываясь в иконки, я словила ещё один странный глюк. Неожиданно иконка одного из этапов не пропала и в трее образовалось две иконки, которые ещё и жили каждая своей жизнью, хотя иконка должна быть одна: программа не создавала никаких дополнительных. Правда, тут всё было ещё проще: увлёкшись, я прозевала запуск этой утилиты по планировщику, и он пришёлся как раз на тестовый запуск, а проверку, не запущена ли уже копия программы, я сделать забыла.

В очередной раз наткнулась.

# Quazi-ultra newer version! Now with RAR!
# REWRITE THIS WHOLE THING, BLYAT!!!

Dysfunctional programming language.
via https://www.joelonsoftware....-first-billg-review/

Понапишут говнокода, а потом рассказывают, что на путоне у них всё быстрее работает и не вылетает.
http://www.commitstrip.com/...the-end-of-the-road/

Три часа упражнялась писать на ассемблере COM файлы, компилировать их, все дела. А потом выяснила, что DOS stub – это EXE файл, а не COM =_= И откуда я это взяла?

Мы живём во времена, когда Дельфи – это ультрабыстро, ультраэффективно, ультракомпактно и почти не блевотно.

Забавный путь у моего самописного скринсейвера. Сначала я написала его на VB5 по аналогии с примером от MS. Потом переписала на C, взяв за основу пример GUI болванки из VC++ 6. А теперь вот портировала на FreeBasic.

Разработчик VirtualDub про Рэймонда Чена.

I love reading his blog because it's full of great information, but I hate reading it because every time I do I have to fix more bugs.

http://www.virtualdub.org/b...ivot/entry.php?id=57