Версия для печати темы

Автор: mor 15.2.2008, 13:07

Поиском пользовался не нашел, гуглил, тот же результат, как такое сделать?

Автор: Litkevich Yuriy 15.2.2008, 16:21

методы hide() и show() применимы ко всем виджетам, пробывал?

Автор: DEADHUNT 21.7.2009, 1:31

visible = false, но меню всеровно показывается. есть ещё какие нибудь варианты?

Автор: Nicolay Sidorov 23.7.2009, 19:45

->setVisible(false)
->setHidden(true)
->hide()
- ничего из этого не работает для QMenu.
Остается использовать только setEnabled(false) или setDisabled(true), на большее, видимо, рассчитывать смысла нет.


Способ скрытия QMenu найден:

Надо только подсчитать порядковый номер нужного элемента QMenu (среди всех остальных, находящихся в menuBar'e):

//QMenuBar* menuBar;

menuBar->actions()[#]->setVisible(false);

// где # - номер нужного элемента

Автор: Litkevich Yuriy 23.7.2009, 19:51

а зачем считать? тебе должен быть известен указатель на действие (QAction).

Автор: SABROG 23.7.2009, 20:08

Или найти по имени объекта:

void hideMenuItem(const QString &name)
{
    QList <QAction *> actions = menuBar->actions();
    foreach (QAction *action, actions) {
        if (action->objectName() == name)) {
            action->setVisible(false);
            break;
        }
    }
}

Автор: kwisp 24.7.2009, 8:08

QAction наследник QObject так что можно и стандартные функции юзать, кстати оч удобно так ка можно регулярные выражения использовать.
QList<T> QObject::findChildren ( const QString & name = QString() ) const
QList<T> QObject::findChildren ( const QRegExp & regExp ) const

Автор: SABROG 24.7.2009, 8:17

Тут то ты и попался в ловушку При добавлении QAction к виджету, он не становится его хозяином:

Автор: kwisp 24.7.2009, 8:21

SABROG,
а у меня хозяин и все работает.
правда у меня action`Ы добавляются в один тулбар.

ты привел цитату из функции addWidget.
а если посомотреть на конструкторы QAction там есть QObject* parent.
если знаешь кого сделал хозяином всех действий думаю можно ими рулить.

Автор: SABROG 24.7.2009, 8:25

void QWidget::addAction ( QAction * action )

parent может быть нулем или его родителем может быть QActionGroup, или экшен может быть использован в нескольких местах.

Автор: kwisp 24.7.2009, 8:33

конечно может(сам только потом его удаляй и всё) использование приведенных мною функций предполагает целенаправленное использование хозяина. Кому надо найти нужный action? программисту. так вот ему можно рулить action через заранее назначенного специально хозяина. QActionGroup тоже наследник QObject вроде бы проблем нет.

использование action в нескольких местах не помешает управлению через хозяина.
это как вариант или предложение, я на своем решении не настаиваю.

просто утверждаю что функции которые я привел вполне применимы к QAction как в прочем и к другим наследникам QObject.

Автор: SABROG 24.7.2009, 9:13

Но он никак не будет связан с меню или виджетом. А его родителем будет, скорее всего, класс главной формы.



Если рассматривать ситуацию с "черной" коробкой внутри которой находятся не известные родители и не известные экшены (видимо именно такая ситуация у автора темы), то варианты предложенные тобой и Юрием не применимы. Иначе, лучше воспользоваться обычным указателем на QAction, если ты его создаешь и можешь контролировать какого родителя передавать, то зачем городить огород?

Автор: kwisp 24.7.2009, 9:39

дык, так рассуждать то функции findChildren пустая трата времени троллей.

а что там у автора имеет место быть это уже конкретика автора если он не знает хозяина action откуда он знает имя?

я считаю что если ты пишешь программу то зачем там городить "черные" ящики, в смысле того что не знаешь кому какого хазяина назначил. и расуждать об объекте типа о нем ничего не известно не практично.
не буду рассказывать и давать ссылки о том что -- отношения parent - child в Qt очень мощная штука и на ней многое построено.


так рассуждать то тебе имена действий тогда тоже не известны однако ты как раз по нему ищешь! всё тоже самое что и parent. Что objectName() -- свойство которое может быть нулевой строкой что parent указатель который может быть нулем. в случае черного ящика ты не знаешь ни того ни другого а в случае если сам пишешь программу то знаешь и первое и второе и явных причин не пользоваться стандартными библиотечными функциями нет

ну да ладно SABROG, о чем спорим то?
каждый сделает как хочет.
спор о пустом.

мир, дружба?

Автор: SABROG 24.7.2009, 10:46

Тоже верно.



Забавно все это, человек придумал сам для себя проблему и сам же её решил через заднее место.

Автор: kwisp 24.7.2009, 10:51

вот об этом по подробнее пожалуйста.
не понял до конца.

что за человек?
что за проблема?
почему через заднее место?

Автор: SABROG 24.7.2009, 11:29

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

Автор: DEADHUNT 26.7.2009, 1:30

что-то не кто так и не ответил, а правильный ответ:

if (state)
{
    menuBar()->insertMenu(viewMenu->menuAction(), projectMenu);
    menuBar()->insertMenu(viewMenu->menuAction(), buildMenu);
    menuBar()->insertMenu(viewMenu->menuAction(), debugMenu);
}
else
{
    menuBar()->removeAction(projectMenu->menuAction());
    menuBar()->removeAction(buildMenu->menuAction());
    menuBar()->removeAction(debugMenu->menuAction());
}

Автор: Гость_Nicolay Sidorov_* 5.9.2009, 1:35

короче, значит скрыть вот так:

//QMenu* menu;
menu->menuAction()->setVisible(false);

и сколько пришлось голову ломать, а ларчик просто открывался. Ну ничего в этом qt по-человечески не делается.

Автор: Litkevich Yuriy 5.9.2009, 12:27

Да это место выглядит нелогично, но на первых порах.
Когда приходит понимание того, что в панели меню (QMenuBar) находятся действия (QAction), то всё встаёт на свои места.