On 16.10.2012 21:30, "Артём Н." wrote:
16.10.2012 21:14, Alexander Danilov пишет:
Тоже GLADE?
glade хорош для того, чтобы прикинуть, как должен выглядеть результат,
Вообще не имею о нём представления.
В данном случае я хочу
оптимизировать работу там, где вижу возможность оптимизации. Смена
редактора кода реально мне может помочь в плане производительности.
Понятно.
Но, например, взять Embarcadero RAD Studio (ранее Borland C-Builder).
Переключиться между cpp и h я могу через Ctrl+F6.
А в vim?
Я могу и обратную ситуацию промоделировать.
Есть набор полей с подписями и разными типами данных и разными фильтрами, пусть
их положим штук 30, часть их них опциональна и зависит от других полей, берётся
всё это описание из внешнего источника данных, который может меняться. Задание:
покажите через Ctrl+F6 эту формочку.
Вот в нормальной среде (язык+редактор) я это сделаю, а в продуктах от Борланда
можно долго
[ *** любой понравившийся вам матерный эквивалент*** ]
Так а что сделать-то надо?
Графический интерфейс пользователя?
И как вы сделаете это "в нормальной среде"?
Задача не очень ясна, но, раз уж упомянули эту RAD, применительно к данному
случаю.
Я бы выделил группы полей, зависящих друг от друга.
И сделал мастера (или появляющиеся вкладки, в зависимости от выбора
пользователя, например TTabControl или как-то так, не помню).
"Внешний источник", например, XML или БД?
Как реализовать построение интерфейса зависит от структуры источника.
Если есть транзитивные зависимости, то мастера там подойдут лучше всего.
Фильтры и тип предоставляются источником.
Возможно использовать что-то типа TMaskEdit (да, я согласен, он не особо, но
возможно написать и своё) и списки для представления наборов значений.
Размещать элементы интерфейса на формах придётся программно.
Цитата: "Размещать элементы интерфейса на формах придётся программно".
Вывод: Использовать эти самые рисующие RAD имеет смысл только для простых формочек, состоящих из
фиксированного небольшого количества заранее известных элементов. В противном случае размещать
придётся программно, а это проще делать на языках, умеющих более шибко манипулировать данными.
Непонятно одно: в чём, в данном случае, отличие этой RAD от "нормального языка"?
А вы попробуйте передать в процедуру на паскале массив сложных структур данных - за то время, что
будете описывать все типы, из которых состоит эта структура и массив и параметры функции и прочее,
на нормальном языка (Haskell/Lisp/Tcl/Python/Ruby/Perl,... зал, помогайте!) уже можно будет написать
всю программу. Вот на C++ можно будет "исхитрится" и объявить параметр как "void*", а потом, когда
наступит очередная полоса "невезения", сидеть в отладчике и удивляться: "как же так, ну что тут
сложного, подумаешь, *(++(*p)->[*++i])+***p++, чего он глючит?!"
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d9f8b.1090...@gmail.com
