Батхерт на VB6

На сегодняшний день мне довольно много приходится писать на VB6. Хотя эта среда раздражает меня конкретно - особенно после того как я освоил программирование не просто в NET, а в NET 2005. Свое недовольство этой безнадежно устаревшей средой я могу кратенько суммировать так:

• Основная проблема VB6 - ограниченные возможности. В среде VB6 виртуальная машина насчитывает всего 700 примитивов программирования против 100 000 в NET. Из-за этого реализация самых элементарнейших программ становится БОЛЬШОЙ ПРОБЛЕМОЙ. Я не говорю даже там о криптографии или мультизадачности и пр. Речь о самых примитивных вопросах. Например, в проге надо посадить в системный трей иконку. Это делается в NET просто перетаскиванием мышкой на форму пиктограммки NOTIFYICON. В VB6 - это головная боль, решаемая только собственной прогой, напрямую обращающейся к API. Для этого сначала пишутся вот-такие тесты, прощупывающие возможности API, потом все это переносится в рабочий проект.
• Чудаковатые типы данных языка. Например вся виндузня (API, реестр, сети) устроена на беззнаковых 4-х байтных переменных Int (к слову сказать обычная переменная Int почему-то в VB6 называется Long !!!). Что означает отсутствие переменной UNSIGNED??? А ничего - просто процентов 50% виндузовых API просто нельзя вызвать, нельзя прочитать половину настроек, прописанных в реестре... Ну с сетью я как-то научился извращаться. Например передавать IP-адрес не в виде простого числа UNSIGNED INTEGER, который не включен в чудаковатые типы данных VB6, а разложить айпишник на байты и передавать отдельно по байтам. Но такие извращения не для слабонервных...
• Чудаковатые синтаксические конструкции с непредвиденными результатами. Чего стоят, например, такие чудо-конструкции, как
  A=B=C
  которая, кто не понял о чем речь - присваивает переменной а результат сравнения B и C !!! Или например, такая конструкция
  A.Metod Recordset
  передает рекордсет в метод полностью, в отличии от конструкции
  A.Metod (Recordset)
  которая передает в метод лишь огрызок рекордсета, под названием Fileds !!! Почему именно его - остается загадкой. Если считать, что обьект усекается до свойства по умолчанию, то Fields должна была бы усекатся до Item, Item до Count и так далее. Однако почему-то дальнейшего усечения не происходит, а все усечение ограничивается только обьектом верхнего уровня и его наличие или отсутствие определяется наличием или отсутсвием СКОБОК !!!
  Тем, кто не писал на VB6 трудно поверить, что конструкция
  Dim i,J integer
  Обьявляет целой только J, а I обьявляется как Variant !!! Однако, поверьте, это действительно так!
• Чудаковатые типы проектов, не позволяющие создавать нормальные распределенные приложения. В принципе, теоретически это как бы возможно сделать с использованием COM+ технологии, но на практике я таких приложений не видел. А если они и есть, то это нечно индивидуальное, развернуть и настроить которое с небольшими усилиями просто невозможно. А ведь чтобы программу ПРОДАВАТЬ - ее надо разворачивать в два щелчка. А иначе - это просто поделка для личного пользования. К слову сказать .NET Remoting и программируется просто и разворачивается без каких бы-то ни было проблем...
• Сложность Web-приложений на VBSCRIPT. Открыть тег в одном INC-файле, потом промотать еще десять INC-файлов - и наконец закрыть тег - это занятие не для слабонервных. Сделать серверные Web-компоненты на VB6 тоже очень непросто, сколько я их ни пытался делать - постоянно возникают какие-то непреодолимые проблемы с безопасностью. Да собственно говоря, зачем такая глубина в демонстрации Web-ограниченности VB6 - тут даже редактор HTML-страниц работает без подсказки...
• Весьма скудные возможности ADO. Ну помимо того, что она просто держит коннект все время открытым (если мы хотим фиксировать изменения), она не позволяет типизировать типы данных. Ну собственно в ADO мы можем только написать:
  RecordSet("TovarName")
  но никак не можем написать как в ADO.NET
  MyPriceList.Row(i).TovarName
  при этом имя поля TovarName выбирается из списочка с подсказкой. При работе приходится держать открытым окно QueryAnalizer и наименования полей для рекордсетов брать оттуда. Вот так технология !!!

  Ну и плюс все остальные ограничения ADO, типа отсутсвия сериализации в XML... Впрочем стандартный сериализатор в VB6 отсутсвует вообще, и это еще одна причина отсутствия на VB6 настоящих распределенных приложений.

• В VB6 присутсвуют некие странные выкидыши обьектного программирования в виде контролов и классов. При этом, скажем наличие параметризованных конструкторов меня раздражает, но не сильно. В принципе при динамическом выделении памяти и известной изворотливости параметрированные конструкторы можно обойти в методе, скажем MyInit.Но как обойтись без наследования и переопределения интерфейсов?
• Собственно отсутствие обьектного программирования и привело в качестве первого отрицательного результата к странным и несогласованные свойства стандартных контролов. Вот кто, например, может поверить, что у совершенно одинаковых списочных контролов, управляющих коллекцией LIST - ListView и ComboBox - у одного присутсвует, а у другого отсутсвует свойство SelectedItem?
• Весьма ограниченные возможности IDE. Ну разве это нормальная среда, если сделать иконку для приложения или отредактировать ресурс-файл, или даже просто посмотреть на файл в шеснадцатиричном виде, чтобы понять в какой он кодировке UNICODE или ANSI - надо держать ОТДЕЛЬНЫЕ приложения? Ну я уже не говорю о таких обычных в NET вещах, как профилер, выявляющий тормозные участки кода или наличие в среде нормального инсталятора, делающего MSI-файлы...
• Среда VB6 не делает даже самые простйшие и необходимые вещи даже в принятой парадигме VB6-программирования. Например, вы увеличили версию библиотеки - однако IDE не умеет делать апгрейд к новой библиотеки и удалить библиотеку из списка REFERENCE нельзя, тк контролы IN USE. Оказывается заставить IDE проапгрейдить версию библиотеки можно лишь с помощью ручных манипуляций. Выбросить из файла проекта ссылку на библиотеку, загрузить проект без библиотеки, а затем добавить в проект ссылку на новую версию библиотеки заново. Другой пример - наследуемая форма на базе существующей. Ну что это за среда, в файле проекта которой надо ежедневно вручную ковырятся нотепадом?
• Мало того, что функции IDE предельно сужены, даже узкий набор заявленных функций НЕ РАБОТАЕТ НОРМАЛЬНО. Даже после всех сервис-паков на множество разных машин у меня проект не компилировался нормально, пока я не менял тип компиляции P-сode/Native-Code.
• Чудаковатая схема обработки ошибок. Нельзя обработку неких ошибок оставить в одном модуле, обработку других отдать другому модулю - даже единый обработчик на главной форме приложения определить нельзя. Ну для каких-то игрушечных приложений это пережить можно, но вот в большом проекте...
• Отсутствие нормального отладчика. Кто не писал на VB6, тот даже не поверит, что нельзя просто запустить отладчик, потом сделать Attach to Process к какой-то работающей VB6-проге, остановить ее на точке прерывания, посмотреть переменные, определить, почему например она зациклилась. А как же отлаживать VB6 проги? А никак! Только пока прога еще в среде у разработчика, запуская ее прямо ВНУТРИ среды IDE - а потом уже никак!!! Вот так среда!!!
  

Этот списочек можно было бы продолжить, но теперь я очень хорошо понимаю, почему навык ковыряния VB6-прог уже несколько лет не сертифицируется как специфическое профессиональное умение - программирование...

В общем-то, среда VB6 лично меня на сегодня настолько раздражает, что я даже все тестовые проекты сначала пишу на VB2005, а потом как-то интегрирую отработанные на тестах идеи в среду VB6. Например, недавно мне понадобилось импортировать некий Excel'евский прайс-лист в SQL-базу. Cходу я не помнил, как получить доступ к крестику слева на экране, которой группирует строки. В IDE-2005 для этого есть готовый вид проекта - WorkBook. Пару щелчков - и 2005-проект готов. Только после этого отработанные идеи переносятся в эту безнадежно устаревшую среду десятилетней давности...

< THANKS ME>