казалось бы, причем здесь Qt  

Скриншот к моему предыдущему посту.  

Ну, вот, ты сам привёл пример . Скажи мне пожалуйста, как в дизайнере ты укажешь editbox'у, что он должен иметь ширину на два символа? Потом я покажу тебе, как это делается в Qt без дизайнера(уверен, что точно также можно будет сделать и для SWF, только вот где проблема - для SWF без дизайнера не программируют ).


Ну давай простой пример нарисуй, только, чтобы не "70" элементов, а 2-4 элемента(примитивных) и скажи что тебе куда запихнут, что вниз, что влево, что вправо, в общем, какой-нибудь частый случай изобрази, а я тебе покажу как легко это делается в коде.


Это завязки на логику. mr.DUDA, вроде ясно дал понять, что логику писать не нужно, я лишь показал, где(в каком месте кода) с этой логикой придётся увязывать контролы и всё.


Дизайнер SWF позволяет не создавать мембера для отдельных контролов? Респект ему и уважуха, если это так . Только почему-то я всё равно вижу повсюду "label1", "label2", "label3" и т.д.(в том же скриншоте).
Плюс к этому, есть вещи, я уверен, которые с помощью дизайнера настроить не удастся. Тогда придётся оставлять мемберов лишь для того, чтобы произвести донастройку в конструкторе(или где у вас принято это делать), после чего эти мемберы будут мёртвым грузом в каждом объекте, не так ли?


Ты немного не в том ключе понимаешь мои слова. Я изначально утверждал, что SWF так спроектирован, что нет возможности писать код в notepad'е, и не напрягаться в этот момент, а в какой пиксель нужно шлёпнуть контрол, а какой у него должен быть размер и т.д. BTW, в Qt есть возомжность и pixel hunting, если появится желание пострадать фигнёй .


Я чес слово уже не помню что там к чему. У меня мало опыта в написании гуя под SWF. Ну, скажем, такой пример: есть некий контрол, отображение которого зависит от многих факторов доступных только в рантайме, и, чтобы всё это запрограммировать так, чтобы это выглядело в дизайнере также, как в рантайме - мне кажется, не самая простая задача. Если дотнетчики и не ленятся делать это, в любом случае им приходится писать лишний код, который нужен именно для дизайнера - не это ли monkey job? 


Подойди к вопросу более абстрактно: есть такие элементы UI, которые не сразу понятны неискушенному пользователю. Есть способ помочь ему освоится: сделать контекстную помощь, которая должна быть доступна при взаимодействии с элементом. Насколько я могу видеть - просто накиданы лэйблы, за которыми нужно самому следить, самому прописывать тултипы или ещё что-то и т.д. Если, вдруг, понадобится сделать так, чтобы при наведении на вопросик всплывал коротенький тултип со словами "нажмите меня, чтобы увидеть помощь", а при щелчке на нём открывалось плавающее окошко(если оно ещё не открыто) и в нём появлялась бы подробная развёрнутая помощь, то, пришлось бы перевбивать тултипы, а саму помощь выносить куда-то в другое место, не так ли? А потом передумали и решили, что открываться помощь должна не по щелчку на вопросик, а просто при наведении на него мыши, то пришлось бы перецеплять эвенты, не так ли? Далее, решили убрать вопросик и сделать так, что помощь высвечивается просто при наведении мыши на непонятный контрол, что делать придётся ты сам, думаю, догадываешься. Потом передумали и решили вернуть вопросик. Потом ещё подумали и решили сделать цвет вопросика не синим, а пурпурным. И так далее. Я тебе могу долго приводить примеры того, как можно изменить способ отображения контекстной справки(представь, что я привередливый клиент), просто я хочу, чтобы ты понял, что при правильной архитектуре GUI-фреймворка можно легко писать намного более качественный код, который просто невозможно делать в дизайнере.

Это сообщение отредактировал(а) archimed7592 - 22.5.2008, 10:48

* сразу оговорюсь - не понимаю при чём тут SWF... говорю лишь о VS В) *

archimed7592, так, я может не обозначил свои цели. единственное что я хотел сказать, что винформы не такая примивная штука как ты о ней говоришь (по крайней мере у меня лично сложилось такое впечатление   )

Конечно прямо вот так "2 символа" я не напишу. просто сделаю маленькую ширину.   


ой слушай, ты меня не понял. это к спору не относится. просто реально интересно В) жалко чтоли?


Дизайнер студии позволяет не создавать мемберов. Эти лейблы там есть потому что как-то надо в дизайн тайме в ними работать. Так что всё выглядит одинаково просто с той разницей, что мемберы можно и не делать.
А какие вещи ты бедушь донастраивать? Лейбл тот же самый - чего ему, шрифт поставил да и всё. Ведь мембуры не нужны для тех контролов которые не задействованы в логике. Если ты хочешь менять надписи - всё равно надо какую-то ссылку иметь.


По-моему он спроектирован так именно для того чтобы не было надобности писать это в блокноте В) вот и всё.


Ну во-первых, я не вижу преимущества писать код для всего контрола вручную. В дизайнере создаётся костак контрола. В логике уже обрабатываются определённые ситуации. Итого для дизайнера не надо писать ничего. Не вижу лишнего кода.



Если стоит такая задача, то на винформах лучше всего реализовывать через юзер-контрол.

Так вот. Ещ раз - я не говорю что винформы = великолепная гуи, или что она лучше QT. я просто посчитал своим долгом высказать своё мнение. я с винформами работал не то чтобы очень долго, но достаточно. и могу сказать, что там есть свои пакости и непристойности, однако это не значит что она уж совсем никудышная. дизайнер - удобный. просто и со вкусом. если надо можно очень даже неплохие гуи создавать. возможностей куча.

ЗЫ главное теперь до сравнения WPF не дойти   

ЗЗЫ При чём тут SWF?... 

ЗЗЗЫ так вот питон - классный язык. очень нравится его 1) кроссплатформенность и 2) скриптованность. Очень удобно. С .НЕТ сравнивать его не могу. ибо всё-таки плохо в нём разбираюсь (дилетантишка одним словом).

Это сообщение отредактировал(а) Kefir - 22.5.2008, 11:18

mr.DUDA, зачем мне объянять кому-то как расположены элементы? 0_о
Кому какая разница, как они расположены, если виджет - это "черный ящик", который отвечает за своё дело и ничего более?


Зачем мне эти размеры? Нет, бывают редкие случаи, что нужно сказать, что этот виджет занимает N% контейнера... Ну и так и пишу:

Зачем мне дизайнер для этого?


Everything by the book .
Если вернуться к тому, с чего начинали, и опять поффтопить про сильные и слабые связи в С++, то, к примеру, внешний виджет, использующий твой, при изменении внутренней структуры твоего виджета будет перекомпилироваться, несмотря на то, что интерфейс с которым он работает с твоим виджетом не изменился. Происходит это потому, что ты, к примеру, изменишь название приватного поля, или добавишь приватную ф-цию... Это проблема конкретно С++.


Ух как... Вот об этих копи-пастах я и говорю - ухудшают они качество кода. А когда ты логику пишешь, ты тоже копи-пастом не брезгуешь? 
Ну, собственно говоря, я уже привёл выше Kefir'у связанные с этим проблемы, повторяться не буду.

В VS уже нету такой штуки, как System.Windows.Forms? Жаль .
Я употреблял это сокращение, дабы дать понять, что говорю именно об SWF, а не о WPF, который якобы "ещё круче Qt" .


О, вот как, а что будет с этим контролом, когда за компьютер сядет человек с плохим зрением и выставит огромный системный шрифт?


Ну что, что, откуда я знаю что .
Что-то вроде этого

Мало ли что там может быть - от логики зависит и от связи с ней .


А что, не бывает в мире ГУИ вещей, которые приходится донастраивать в конструкторе? Скажем, заливать combo/list-box значениями, полученными откуда-то динамически?


Блин... Перефразирую:
1. Есть фреймворк, который настолько удобно спроектирован, что можно не задумываясь писать ГУЙ в блокноте.
2. Есть фреймворк, который не очень удачно спроектирован, хотя бы, потому что для того, чтобы сделать дизайн необходимо иметь дизайнер?(он что, часть фреймворка?)
Напомню, что началось всё с фразы 3-хмерного маньяка, мол "нет ничего удобнее для ГУЯ, чем дотнет".


Мдя, ну возьмём table(не помню точного названия) с его возможностями настраивать через всяки диалоги связи с датасетом и т.п. Да и сам датасет, хоть он и не гуёвый элемент, немало диалогов для настройки имеет. Я говорю про написание этих диалогов - их придётся писать, если хочешь, чтобы в дизайнере можно было манипулировать контролом также, как в коде. Это и есть никому не нужная работа(которую, подозреваю, многие делать поленятся, ибо, действительно - monkey job, если сам контрол, конечно, не для продажи пишется).


Вот видишь, сразу контрол.  А почему контрол? А потому что без дизайнера себе жизни не представляем, да? 
Я же сказал(от лица привередливого клиента), что через месяц передумаю и попрошу сделать так, чтобы всё действо происходило при наведении мыши на непонятный элемент, а не на контрол рядом с ним(будь то вопросик или крестик - неважно). И чем тебе этот контрол поможет?

Добавлено через 10 минут и 28 секунд

А чё ж в спор полез? 


Это сообщение отредактировал(а) archimed7592 - 22.5.2008, 11:47

ах соо. тогда ясно. просто мне эта аббр. больше флаш напоминает В)



научи меня, о гуру!



конечно бывает. вот и донастраивай. если ты хочешь с контролом общаться напрямую - делай мембер. или ты на QT говоришь можешь комбик заполнить без ссылки на него?   



Действительно. Потому что незачем. Накатал что тебе конкретно надо и живи спокойно. Зачем делать универсальный контрол, когда ты его юзаешь в двух местах программы? Понадобится полная универсальность - вот когда понадобится - тогда и сделаешь.




Нет, не угадал В) Юзер контрол потому что он позволяет запихнуть в него несколько контролом одновременно. То биш в него я поставлю, к примеру, лейбл и текстовое поле. Скажешь поставить сбоку вопросик - пожалуйста. Поставлю в него ещё и вопросик.

Добавлено через 53 секунды
А что, в QT вопросики по другому расставляются?    Есть система "анти-привередлиость"?

Видимо ты не работал в команде, когда с виджетом работает более чем один девелопер.


Да, конечно не брезгую. У меня весь код - один сплошной копипаст !   


То есть Qt настолько умён, что человек-дизайнер уже как бы не нужен? Всё будет расставлено и растянуто как положено. Вау, нафиг тогда винформс и WPF, накоплю 6 килобаксов и перейду на Qt/C++   

Вообще говоря, я услышал эту аббревиатуру, если мне память не изменяет, от Exception'а... Может быть я расшифровал её неправильно? Ну, не суть.

Зачем сарказм? Я действительно не знаю, что будет с контролом, если выставить крупный системный шрифт.
В коде это делается так:

Это я расписал в 6 строк, ибо, как я подозреваю, не все знакому с С++ и не поймут записанное в одну строку(намного короче).
Думаю, что в .NET'е можно проделать тоже самое, только не в дизайнере.


Можно сделать это без мембера. Просто ссылка будет иметь ограниченную область жизни(от места объявления до закрывающейся фигурной скобки):

Ты же не удивляешься, что дизайнер как-то умудряется производить настройку контролов без наличия мемберов(раз их можно убрать)... То же можешь делать и ты, только вот где проблема - без дизайнера жизнь не сладкая у SWF программистов .


И что, ты в обоих местах будешь проделывать одни и те же действия?
Насчёт "зачем универсальный?" - а я не знаю зачем . Мне и не приходится делать универсальные контролы, ибо у меня не стоит задача, чтобы они работали в дизайнере. Мне достаточно, чтобы контрол выполнял требуемые от него ф-ции и всё. Дальше я его в двух(в десяти, в двадцати) местах программы создаю и использую и никаких проблем.
Об этом я собственно и говорю - вам не хочется делать универсальные контролы, и, когда придётся что-то изменить - придётся делать много monkey job и ни к чему другому копи-паст в дизайнере привести не может(собственно, как и копи-паст в коде).


Эххх. Теперь представь, что у тебя есть лэйбл и эдитбокс(ну, типа поле для редактирования - ничего особенного). При наведении на оба элемента(что на лэйбл, что на эдит) должна дёргаться контекстная помощь. Занул ты обоих в свой контрол и радуешься жизни. Теперь представили, что таких полей для ввода с надписями много и они как-то должны быть сгруппированны. Когда у тебя просто есть отдельно лэйбл и отдельно эдитбокс, то ты можешь засунуть их в отдельные столбцы GridLayout'а. Когда они обёрнуты в какой-то спец-контрол, отвечающий за помощь, то это уже становится монолитный контрол и засунуть разные его части по разным столбцам не получится. Можно, конечно, воспользоваться span'ом на оба столбца, но эффект будет тот же, что если ты эти пять полей для ввода засунешь в VBoxLayout, т.е. будет похоже на ёлочку.
Как тут поступим?

Да, не работал. Правда, я не до сих пор не могу понять, что это за мега навороченный виджет должен быть, чтобы нельзя было разбить его по ф-ционалу и дизайну на кусочки и поручить их разным людям.


Сарказм какой-то пошёл.. Ты хочешь услышать, что я пытаюсь донести или ты несмотря ни на что будешь продвигать свой тезис, мол ничего удобнее .NET для гуи не существует? Тогда не вижу смысла в дальнейшей дискуссии.


Не понимаю тебя. Вот смотри, код:

Вот что получается.

Слева-направо, сверху-вниз: 1) размер по умолчанию; 2) юзер руками растянул по горизонтали; 3) растянул во вертикали; 4) растянул по диагонали.
И теперь вопрос: какие такие размеры мне пришлось учитывать?

А вариантов, когда виджет дорабатывает кто-либо кроме создателя не рассматриваешь? Или тот же виджет, но спустя полгода ты подзабыл как оно должно было выглядеть.


Пример в ответ. Если добавить справа от текстбокса кнопку, размер кнопки можно как-то задать?

да всё ясно - мы просто по разному расшифровываем эти буквы  


ну конечно, само собой.


конечно, само собой. так оно и получается. только я работу с дизайном делаю делаю в дизайнере, а ты печатаешь кодом. в чм превосходство второго варианта? пока что я могу лишь заметить, что в дизайнере работать намного нагляднее, чем описывать в коде.



так о чём разговор? суть всё то же самое.



ну опять. ну вот, сделал я контрол и буду юзать его хоть сто раз в любых местах. универсальный контрол в моём понимании - тот, который можно использовать в различных ситуациях. при чём тут этот копи-паст?



перед этим хотелось бы услышать как всемогущий QT решает эти задачи. а то я пишу, пишу, жду, жду...

В том, что в дизайнере нельзя задать ширину относительно размера системного шрифта, а без дизайнера можно.


Ок, раз то же самое, покажи мне как ты без мембера добавишь в дизайнере комбобокс и потом проинициализируешь список его значений в конструкторе.


Ок. Есть контрол "форма ответа в тему". Она присутствует в трёх местах - быстрый ответ, "долгий" и ответ в ПМ. Хотя нет, ещё несколько мест: новая тема, новое ПМ.
Ситуации суть те же. Написали мы такой контрол. Ок. Нужно разместить его на странице. Размещаем... Ой, а как эту форму немного кастомизировать для разных случаев? Блин, нужно делать специальные диалоги настройки специально для дизайнера, вот же чёрт, придётся заниматься monkey job лишь для того, чтобы воспользоваться всею "мощью" дизайнера... Аналогия ясна?
Что-то мы из пустого в порожнее гоняем... Я напомню в чём здесь спор: я утверждаю, что некоторые контролы со сложной логикой при использовании в дизайнере приходится настраивать через спец. диалоги. Диалоги эти не нужны никому, кроме дизайнера. Вывод: это плохая черта делания ГУЯ в дизайнере, ибо приходится писать эти диалоги лишь для того чтобы пользоваться дизайнером. Вы согласны с этим выводом? Нет? Почему?
Ещё напомню это: без дизайнера делать ГУЙ нельзя при использовании SWF, а при использовании Qt делать ГУЙ можно без дизайнера. Вывод: Qt намного удобнее потому что не нужен никакой code behind, чтобы скрыть тот ужас, который генерит дизайнер - им можно просто не пользоваться. Вы согласны с тем, что фреймворк в котором можно с лёгкостью делать гуй без дизайнера лучше? Нет? Почему?


Чего ты написал до чего ответа не дождался? 0_о
Я не утверждаю, что Qt решает эту задачу. Я утверждаю, что эту задачу можно решить когда не используешь дизайнера, а сделать это(т.е. писать код руками без дизайнера) можно только с один из двух обсуждаемых фреймворков - с Qt.
Я напомню, в чём вопрос: я утверждаю, что дизайнер принуждает к плохому стилю. Я бы даже без необходимости размещать в гриде не стал бы оборачивать лэйбл и эдитбокс в невидимый спец контейнер, отображающий хэлп и это не потому что я такой "гуру", а потому что просто я не пользуюсь дизайнером и не скован его ограничениями.
Собственно, я буквально неделю назад занимался прикруткой этого контекстного хэлпа к одному проекту. Прикручиванием я занимался уже после того, как проект был реализован, ибо когда я пытался научить персонал пользоваться программой, я понял, что другого выхода просто нет - запомнить пять шагов они не в сосотоянии, использовать(понимать) "обыкновенную" справку они тоже не в состоянии. Как бы смешно это не звучало, сначала я сделал с подобными вопросиками - даже это оказалось им не по силам(они не виноваты, просто уровень компьютерного развития почти нулевой, они из калькулятора результат переписывают на бумажку, после чего вводят его в экселе в соседнем окне с бумажки).
Тогда я сделал так, что при наведении мыши во второй половине окна отображалась html'ина с подробнейшим описанием и иллюстрациями(к слову, это хоть и помогло, но не особо - в итоге пришлось снимать видео при помощи CamStudio, где показывать подсвеченным указателем мыши куда нужна тыкнуть, зачем и т.д.).
Итак, добавление справки выглядит так:

Как ты понимаешь, когда я переделывал с вопросика на hoverEnter/Leave я даже не заглядывал в этот код, я лишь немного подправил ContextHelpManager.


Почему должно было? Хочешь сказать как оно выглядело?
Ну не проблема написать три строчки:




Когда виджет в лэйауте, то размер - величина рекомендательная. К примеру, справа - это в отдельном столбце? Тогда столбец будет себе подбирать ширину по определённым правилам. Ньансы можно выбрать такие: задать стретч, чтобы этот столбец всегда занимал минимум пространства, тогда будет использован sizeHint отдаваемый кнопкой. Иначе, можно для каждой кнопки задавать fixedWidth. Иначе, можно выставить sizePolicy->horizontalPolicy в Fixed. Ньюансов куча - зависит от того, чего ты реально хочешь добится. Можно вообще эту кнопку вынуть из лэйаута и позиционировать её и задавать ей размеры руками, просто никто так делать не будет .

Вот это я и хотел услышать. Значит в Qt всё же есть шаманская машинка, которая определяет оптимальные размеры и отступы (по size policy и т.п.). Удобно (без сарказма).  


В винформах есть AutoScaleMode, там в т.ч. есть вариант Font.

так вот в коде и добавляем В) то что есть дизайнер не отнимает возможности дописать что-то в коде. я не прав?
о тут mr.DUDA даже лучше сказал В)


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


Я понял что ты имеешь в виду, только я тебе о том и говорю - набросали костяк в дизайнере (ну там, накидали поле текстовое для ответа, кнопычка, ещё что-то). А в коде затачиваем до опупения. Для дизайнера ничего не надо делать.


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


Да кто тебе гадостей таких наговорил? Пиши на здоровье!


нет. не согласен. тот фреймворк лучше, у которого можно с лёгкостью делать гуй (заметьте, опущена часть без дизайнера). а с дизайнером или без - это уже дело второе. я считаю, что винформы очень удобны в плане создания гуя, ты считаешь, что нет, потому что тебе больше нравится писать ручками    аргументы, а-ля "а там меберы мешают", по-моему, просто смешны.


нут, я как бы думал, что вот ты сейчас меня послушаешь и скажешь как на QT это сделать (ну мне это показалось логичным, может я неправильно понял).



хосспади, так напиши такой же хелп манагер на шарпе и радуйся жизни. Ты меня пытаешься убедить в том. что на QT всё намного проще и показываешь код, который к QT отношения не имеет. Ну да, клёво, класс, который подписывается на чужие эвенты (условно говоря).

Это сообщение отредактировал(а) Kefir - 22.5.2008, 16:12