qobject_cast то работает то нет...

[Krow]

Код:

qobject_cast<mainWindow *>(parent()->parent()->parent())->ui.actNumberSklad->text();

вот этот код вылетает с ошибкой..

Код:

qobject_cast<mainWindow *>(parent()->parent()->parent())->ui.actTovCat;

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

[spirit]

валидность указателя каждого парента и самого actTovCat. что-то не так с указателями (нулевой или невалидный).

[lit-uriy]

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

Код

C++ (Qt)
mainWindow *w = qobject_cast<mainWindow *>(parent()->parent()->parent());
if (w){
    w->ui.actNumberSklad->text();
}else{
    qDebug() << "Kemuto herovato";
}
 

[Krow]

Код:

	mainWindow *w = qobject_cast<mainWindow *>(parent()->parent()->parent());
		if (w)
		{
			dirCount = w->ui.actNumberSklad->text();
		}
		else
		{	
			QMessageBox::information(0, "", "Khernya kakaya-to");
		}

один фиг спотыкается на первой строчке... если ставлю всего один парент тогда выскакивает сообщение что это всё фигня... иначе просто отваливается в дебаггер и всё...

[Krow]

Код:

fMyOrg *child = new fMyOrg;
child->dirCount = dirCount;

сделал так при вызове из mainWindow. теперь работает всё как надо.
но всё же интересно почему оно там спотыкалось!

[SASA]

ИХМО если у вас появляются структуры вида parent()->parent()->parent(), то либо рядом должно быть много проверок и комментариев, либо надо менять архитектуру.

[BRE]

либо рядом должно быть много проверок и комментариев

А в комментариях лучше написать: "FixMe: Сегодня мне было особенно плохо..." 

либо надо менять архитектуру.

+1. Нужно сразу начать менять.

[Igors]

Присоединяюсь, конструкция parent()->parent()->parent() ненадежна и будет разваливаться при каждом добавлении лайаута. Про "архитектуру" громко сказано, можно нормально сделать за 5 минут

http://www.prog.org.ru/topic_10751_0.html

[BRE]

Про "архитектуру" громко сказано, можно нормально сделать за 5 минут

Да костылек можно быстренько подставить, вопросов нет.
Только если необходимо из внутренних виджетов добираться до mainWindow, то скорее всего что то не то с архитектурой классов и их связями. Дочерние классы получаются зависимыми от класса mainWindow, они должны о нем знать и уметь им пользоваться. Что не есть гуд, для повторного использования кода.
По мне уж лучше связывание через connect сделать...

[Igors]

Только если необходимо из внутренних виджетов добираться до mainWindow, то скорее всего что то не то с архитектурой классов и их связями. Дочерние классы получаются зависимыми от класса mainWindow, они должны о нем знать и уметь им пользоваться. Что не есть гуд, для повторного использования кода.
По мне уж лучше связывание через connect сделать...

Согласен что connect лучше/техничнее, но проблем с архитектурой это не решает. Все равно "кто-то" (кто связывает слот/сигнал) должен "знать все" о mainWindow и его child - зависимость все равно остается прямой/явной. Ну и до повторного использования еще дожить надо

[BRE]

Согласен что connect лучше/техничнее, но проблем с архитектурой это не решает. Все равно "кто-то" (кто связывает слот/сигнал) должен "знать все" о mainWindow и его child - зависимость все равно остается прямой/явной. Ну и до повторного использования еще дожить надо

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

[Igors]

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

Все верно, не должен child переться в parent (и особенно вызывать методы parent напрямую). Но что делать если ему от parent'а нужно что-то получить чтобы продолжить свою работу? И это "что-то" по смыслу в  parent. Иногда удается удачно положить, иногда интерфейсная прокладка подойдет, ну а иногда проще признаться - это глухо конкретно и ни на какую общность мы не рассчитываем

[BRE]

Все верно, не должен child переться в parent (и особенно вызывать методы parent напрямую). Но что делать если ему от parent'а нужно что-то получить чтобы продолжить свою работу? И это "что-то" по смыслу в  parent. Иногда удается удачно положить, иногда интерфейсная прокладка подойдет, ну а иногда проще признаться - это глухо конкретно и ни на какую общность мы не рассчитываем

Код

C++ (Qt)
mainWindow::mainWindow(...)
{
	m_setupWidget = new SetupWidget( this );
	connect( m_setupWidget, SIGNAL( changedParameter1( int ) ), SLOT( setData( int ) ) );
	connect( m_setupWidget, SIGNAL( changedParameter2( const QString & ) ), SLOT( setText( const QString & ) ) );
}
 

Мысль понятна? 
А кто, что и в какой вложенности будет менять в SetupWidget дело десятое. Пусть сам SetupWidget будет сообщать о изменениях. И mainWindow не нужно ничего знать про внутренности setupWidget.
Мы можем что угодно менять в SetupWidget, пока будет не изменен интерфейс mainWindow сможет с ним работать.

[Igors]

Мысль понятна? 
А кто, что и в какой вложенности будет менять в SetupWidget дело десятое. Пусть сам SetupWidget будет сообщать о изменениях. И mainWindow не нужно ничего знать про внутренности setupWidget.
Мы можем что угодно менять в SetupWidget, пока будет не изменен интерфейс mainWindow сможет с ним работать.

На простых примерах отлично проходит все что угодно А если, например

Код:

struct Settings {
  double mRatio;
  ...
};

void SetupWidget::DoSomething( void )
{
  int mode = GetCurrentMode();
  ...
  if (useSettings) {
   Settings theS; 
   MainWindow::Instance()->BuildSettings(&theS, mode);
   if (theS.mRatio != 1.0) {
    ...
   }
  }
}

Хорошо бы подать, например, указатель на Settings в SetupWidget, но не выходит - нужен метод а не данные. BuildSettings должно знать много всего и место ей вроде в MainWindow. Мы можем послать сигнал вместо Instance() - да, но что это в принципе меняет?

[BRE]

BuildSettings должно знать много всего и место ей вроде в MainWindow.

Действительно? BuildSettings должно находиться в ГЛАВНОМ ОКНЕ программы? Хм... 
Ты правда так думаешь? А может для setting лучше сделать отдельную сущность, к которой будет доступ и у mainWindow и у SetupWidget?