Генерация кода из ui.

[panAlexey]

У вас уже промышленный масштаб серьёзной системы
А серьёзные системы требуют серьёзных подходов.
А как у вас реализованы вызовы пунктов?

Элементарно запускается. В первой колонке путь к объекту: "Обработка.УправлениеНастройками1Спп32хх"
Оборачиваешь в системную команду: ОткрытьФорму("Обработка.УправлениеНастройками1Спп32хх");
У меня правда реализовано с пом. доп обработки, которая сначала права на использование объекта запрашивает, а потом уже открывает.

[panAlexey]

Я собственно и заморачиваюсь на системы типа http://www.prog.org.ru/topic_23822_0.html
Потому что знаю, любая система, введенная в эксплуатацию имеет шанс разрастись в монстра,
управлять которым можно будет только с помощью специальных инструментов.

[Igors]

Bepec, я тут маленько пофлудю, надеюсь "частично в тему"

В добрые старые времена на Mac  (когда еше никаким линухом и не пахло) все и всегда грузили диалоги из ресурсов. Диалог рисовался интерактивно, редакторы были - и не один. Загрузив диалог знали что контрол 1 - напр button, 2 - EditText и.т.д. Известны были только ID, по ним можно было взять handle контрола и дальше с ним самому разбираться. И все прекрасно работало, программист никаких трудностей не испытывал если руки у него росли как надо.

А теперь - подайте то, принесите это. И текст сгенерите, и чтобы красиво оформлен, и попку подмойте.. В итоге - безрукое создание, умеющее только собирать, подключать и, по существу, ничего более. Зажрались. А ведь никто не мешает делать как раньше - есть QFormBuilder, и сигналы он хранит, и пропердии (не то что раньше - ID и все). Рисуйте себе в дизайнере на здоровье, потом только контролы в свои переменные загрузите. Чужой код (какой угодно хороший) всегда будет источником проблем по той простой причине что чужой. Его лучше не иметь.

[Bepec]

to panAlexey:
Хорошо, что у вас имеется готовая система Спасибо за пожелание.
Одно плохо в идее с креатором - креатор (моё ИМХО)

to Igors:
В тему ваш флуд, в тему
Я всё ждал когда это скажут - "пишите на ассемблере, а то превратились в тупых сборщиков из лего".

Дело не в "красиво оформлено" и не в "подай принеси" и даже не в "зажрались"

А дело в автоматизации рутинной работы Я ещё не дошёл до создания скриптового движка для связывания экшенов.
Но необходимость обработать 20/30/40 пунктов меню заставляет подумать об автоматизации написания кода. 40 раз писать к примеру "void on_action_trippleKillEnemy_triggered(bool);" в h. А потом 40 раз в cpp. А потом ещё и держать в голове (или дополнительно 40 раз писать комментарии) где эти пункты находятся - как бы плохо.

Igors - предложите другой способ написания обработчиков для action'ов и мы с вами его обсудим.

[kuzulis]

2 Верес,

блин, а я что-то до сих пор не въехал, зачем это надо...

Т.е. ты хочешь, типа: набросал на UI контролы, назвал их как тебе нужно, жмакаеш некую
магическую кнопочку "сделать мне волшебство" и на выходе получаешь класс...

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

Блин, я недогнал...

[Bepec]

to kuzulis:

Собственно начало этой темы положили action'ы. У которых мне нужен был только один слот - нажатие.

Т.е. набросал action'ы на QMenu в дизайнере, задал им имена. Сохранил ui.
Врубил скриптип - чух мара пух - получаю кусок кода для h и cpp. И там и там имеются комментарии аля "//файл->открыть", обозначающие месторасположение контрола.

Для примера и более полного понимания - вот жаба скриптик.
Способ применения - задать ему в параметрах командной строки обрабатываемый ui. В ui должны быть action'ы.

На выходе текстовый файлик test.txt создаваемый рядом со скриптом, содержащий в себе код.

PS соответственно он работает на W7 64, а вот на линуксах как js запускать я и не подозреваю.

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

[GreatSnake]

А почему бы всё не упростить и вешать слоты не на каждый QAction, а один слот на один QMenu::triggered( QAction* action )?

[Bepec]

И получить один огромный смешанный свич? Который в конце концов сведётся к вызову функций, реализующих функционал?

Т.е. как я вижу, получается аля

Код:

switch (какой-то_признак)
{
case какой-то_признак_1: 
    вызов_функции_реализующий_функционал_1;
    break;
}

Вижу только недостатки такого подхода. Как то неявность для стороннего программиста, большее (на 1, но всё же) количество функций (кстати проще подключать на QMenuBar).

м?

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

[GreatSnake]

И получить один огромный смешанный свич? Который в конце концов сведётся к вызову функций, реализующих функционал?

Почему огромный? У тебя что в меню огромное количество пунктов Если > 20, то кривой дизайн.
И в любом случае всё "сведётся к вызову функций, реализующих функционал".

switch (какой-то_признак)

Привязываемся не к "какой-то_признак", к QAction::objectName().

(кстати проще подключать на QMenuBar).

Может и проще, только бессмысленно, ибо только определённое меню знает какой QAction был выбран.

[Bepec]

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

Да, меню огромное. > 20/30/40 с уровнем вложенности 3.

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

Да, кривой дизайн. Дизайн не мой. Дизайн заказчика.

Да, я бессилен в этом направлении.

[GreatSnake]

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

Где

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

Тебе в любом с лучае придётся писать туеву кучу слотов на каждый пункт. От этого никуда не деться.
То, что я предлагаю, имхо, должно как раз упростить всё.
Можно явным перебором по названию QAction, либо через QMetaObject::invokeMethod() опять же по имени QAction дергать определённый слот.

[Bepec]

made by assistant QMenuBar

This signal is emitted when an action in a menu belonging to this menubar is triggered as a result of a mouse click; action is the action that caused the signal to be emitted.
Normally, you connect each menu action to a single slot using QAction::triggered(), but sometimes you will want to connect several items to a single slot (most often if the user selects from an array). This signal is useful in such cases.

Видимо мы не понимаем чуть друг друга. Последовательность моих действий:
1) создать QtGui класс, создать в ней меню из 5 action'ов.
2) запустить скрипт на ui. файл.
3) скопировать вывод в h, cpp.
4) реализовать функционал.

Вот вывод уже готового скрипта, который я выкладывал ранее.
Т.е. куева туча слотов создана, уже связана с формой. Мне остаётся только скопировать это в h, cpp и реализовать/объединить если необходимо функционал.

Код:

void on_action_triggered ( bool checked );
void on_action_2_triggered ( bool checked );
void on_action_3_triggered ( bool checked );
void on_action_4_triggered ( bool checked );
void xoxChecker::on_action_triggered ( bool checked )
{

}
void xoxChecker::on_action_2_triggered ( bool checked )
{

}
void xoxChecker::on_action_3_triggered ( bool checked )
{

}
void xoxChecker::on_action_4_triggered ( bool checked )
{

}

[kambala]

3) скопировать вывод в h, cpp.

хороший скрипт сам должен писать в файлы.

я предпочитаю давать слотам норамальные названия, отражающие что они делают.

[Bepec]

Kambala, я ж произвёл все действия только что и исключительно для примера. Дабы прояснить все страсти.

Да, скрипт недоделанный. Да, он к тому же не умеет читать комментарии из-за UTF8.

Да, я тоже предпочитаю давать нормальные названия.

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

Да, я устал, разнервничался и хочу домой. Не придирайтесь к словам и примерам пожалуйста.

[GreatSnake]

Я говорю совсем про другое. Можно всё сделать автоматом непосредственно в самом приложении без всяких скриптов.
Достаточно чтобы меню имело уникальное название и элемент меню в рамках своего меню тоже имел уникальное название.
Далее после создания QMenuBar-а и всех его подменю пробегаешься по всем подменю и вешаешь на каждое меню слот на QMenu::triggered( QAction* action ), в котором по имени меню и полученного action формируешь название слота и через QMetaObject::invokeMethod() вызываешь этот слот. Понятно?