Главная » C++, C++ Builder » Волоки, пока не уронишь C++ Builder

0

Еще одна печальная история из моего программистского прошлого. Несколько лет назад меня попросили реализовать довольно простое окно диалога. В диалоге было два  списка.  Первый список должен был содержать все возможные варианты из данной темы, а во втором должны были

находиться выбранные. Между двумя списками в окне диалога располагались две кнопки, озаглавленные >> и <<. Кнопка >> перемещала выбранные элементы из левого списка (все возможные варианты) в правый (выбранные). Это было довольно простое окно диалога, и я справился с ним за пару часов. После этого начались проблемы.

Первый же смотр продукта пользователем немедленно направил мое окно диалога на переделку. Во-первых,  пользователю не нравились кнопки >> и <<. «Не очень понятно», — говорили они.

«Хорошо», — сказал я, и поменял текст на кнопках на «Добавить» и «Убрать».

Как раз в то время популярной темой для обсуждения в мире Windows (это была система Windows 3.1) была концепция drag-and-drop (дословно: перетащить и уронить). Один из  старших менеджеров, который имел некоторый опыт общения с продуктами под Windows, поднял эту тему.

«Что нам здесь нужно», — сказал он, — «это система drag-and-drop между двумя списками». К сожалению, в этом действительно был смысл. Пользователь стал бы просто выбирать нужные элементы в левом списке и перетаскивать их в правый список. Мы предложили прототип окна диалога, сделанный с помощью посторонней утилиты, и пользователям он понравился. Было легко выбирать один или более элементов слева и перетаскивать их направо. Дискуссия была закрыта; программирование началось, и проблемы немедленно появились.

Когда все это происходило, в системе, используемой нами (это были классы MFC, но фактически могло быть что угодно), поддержки для drag-and-drop не существовало. Разработка drag-and-drop для двух списков означала создание собственного класса списка, наследующего от стандартного, проверку нажатия кнопки мыши и определение того, что могло быть выбрано в списке. Три дня прошло, пока я доблестно пытался разработать процедуру для двух списков. В конце концов у меня было нечто, в основном работающее без странных побочных результатов. Программа была предъявлена конечным пользователям, которым сразу понравилось то, что они  увидели.  Как сказал мне мой менеджер после презентации (почему, интересно, программистов никогда не приглашают на представление продукта?), было всего лишь несколько пожеланий. Во-первых, им хотелось иметь возможность помещать элементы в нужную часть второго списка. Другими словами, часть, «роняющая» элементы, должна была поддерживать позиционирование. «Хорошо»,

— подумал я, — «это разумное требование». Второе требование, однако, было страшным: позволить пользователю перемещать элементы внутри одного и того же списка.

Если вы когда-либо делали список с возможностью drag-and-drop, вы, вероятно, сталкивались с этой проблемой. Задача не только в удалении существующего  элемента,  а также в вычислении места, в которое он попадет в новом списке. Это был страшный код, так как я мог только догадываться о том, в какую позицию попадет элемент. Это было вне нормальной функциональности списка, и поэтому мне пришлось погрузиться в Windows API, чтобы доделать эту работу.

Наконец, через три недели после первой демонстрации, окно диалога с двумя списками было завершено, и пользователь был удовлетворен. Еще через неделю проект был закрыт, и я остался без работы. В чем мораль этой истории? Я точно не знаю, но вещи, подобные этой, гораздо легче реализуются в CBuilder, чем это было в MFC.

Источник: Теллес М. – Borland C++ Builder. Библиотека программиста – 1998

По теме:

  • Комментарии