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

[Igors]

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

В окне или нет, но очень может быть что в классе который намного мощнее SetupWidget.

А может для setting лучше сделать отдельную сущность, к которой будет доступ и у mainWindow и у SetupWidget?

Ну сама Setting на "сущность" не очень тянет - пассивные данные, struct. Здесь по-моему хорошо подойдет "implementation" техника (немногое что мне понравилось в Жабе). После тщательного обдумывания конечно.

Так что я бы человека за "архитектуру" не осуждал, это может быть очень непросто и иногда лучше "поступиться принципами"

[BRE]

это может быть очень непросто и иногда лучше "поступиться принципами"

По моему, это девиз Microsoft. 

[off]
IMHO
При ООП нельзя сесть за компьютер, открыть ТЗ и как пианист начать строчить что вижу. Для ООП больше подходит процесс длительного проектирования, которое потом выльется в более компактный и эффективный код, с большим количеством повторного использования кода. Нужно выделять сущности, продумывать их взаимодействие (интерфейсы). А иначе, процесс будет превращаться, чем "дальше в лес" тем "больше костылей".
[/off]

[Rcus]

Точно, а то что рефакторинг зародился в среде программистов SmallTalk это совпадение ага
Начинали с qobject_cast, а пришли к Waterfall vs Agile

[BRE]

Точно, а то что рефакторинг зародился в среде программистов SmallTalk это совпадение ага

Ты имеешь ввиду рефакторинг кода во время разработки?
При эволюции системы он скорее всего понадобиться. Но...
Если в системе есть датчик, то нужно описать сущность датчик, которая не должна ничего знать о главном окне, о базе данных, куда все показания должны сохраняться и о подобных сущностях. Если в какой то момент разработки из класса датчика нужно вытащить работу с железом и поместить ее в другую сущность "железо", с которой в дальнейшем будет работать датчик, то в этом нет ничего плохого, остальная часть системы как работала с датчиком так и будет работать. Если меняется интерфейс для работы датчиком, то эти изменения коснутся только сущностей, которые на прямую работают с ним. А при правильной архитектуре это будут далеко не все классы системы.
Сейчас же сплошь и рядом пишут комбобоксы, которые напрямую лезут к железу, таблицы которые напрямую работают с базами данных и т.д. А когда просишь людей уберите этот GUI и прицепите ncurses, т.к. на машине которая будет стоять рядом с прибором (для мониторинга) не установлены X, они широко раскрывают глаза и удивленно отвечают, что у нас весь функционал размазан по GUI и одно без другого не работает. Становиться грустно.
Поэтому, я убежден, что при разработке новой системы проектированию необходимо уделять максимум времени, что бы потом использовать минимум костылей. 

[Igors]

что бы потом использовать минимум костылей. 

Ага, значит наличие и необходимость костылей Вы все-таки признаете Вы описали классический случай "сделайте версию application с командной строкой без UI" - это всегда хорошая проверка архитектуры на вшивость. Но я не могу согласиться с Вами что все будут (и должны) делать это пока жизнь не заставит. Планировать перед стартом конечно нужно, но никогда всего не предусмотришь, хорошие, гибкие зависимости обычно получаются со второго-третьего раза. Возвращаясь к qobject_cast: очень может быть что "костыля" с взятием указателя MainWidow хватит на несколько лет и никаких проблем не возникнет - например если человек пишет серию плагинов. Зачем же грузить его замысловатой конструкцией с множественным наследованием, чистыми виртуалами и.т.п., что (по моему мнению) правильно и корректно но ... нужно ли оно ему?

Ну вот, мы с Вами опять свалились во флуд, умолкаю

[BRE]

Вы описали классический случай "сделайте версию application с командной строкой без UI" - это всегда хорошая проверка архитектуры на вшивость.

Не обязательно с командной строкой. Главное, что бы функционал был отделен от GUI, тогда к нему можно и командную строку приделать и Qt/wxWidget/Gtk...
Если абстракцию можно выделить в сущность, то ее нужно выделить. Не нужно все что можно пихать в MainWindow, он должен отвечать только за главное окно, включая меню, тулбар и т.д. Также комбобокс должен уметь только вывести список строк и просигнализировать о том какую строку выбрал пользователь, больше он ничего не должен уметь делать!

Ну вот, мы с Вами опять свалились во флуд, умолкаю

Лучше на ты.
С флудом согласен, тоже умолкаю. 

[Krow]

мужики, отсыпьте а?! я тоже так хочу..

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

но вернёмся к заданному вопросу! суть была такова, во вновь созданный класс передаются некоторые переменные которые известны классу mainWindow. вот и был вопрос, как достать их из mainWindow в child.. сначала делал это с помощью парентов, а потом уже переменные стал при инициализации child'a передавать..
создавать отдельную сущность для хранения переменных не хочу. оно пока не требуется в этой программе.
да и всё же был вопрос в том почему не работает qobject_cast. ведь последовательность парентов что в этом классе (не работает каст) что в другом (в котором работает) одинакова!
при чем я писал раньше, инклуды у обоих чайлдов одинаковы..

[BRE]

мужики, отсыпьте а?! я тоже так хочу..

Вчера все закончилось. 

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

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

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

Вот сейчас самое время начать переделывать, такие цепочки парентов как раз об этом говорят.

но вернёмся к заданному вопросу! суть была такова, во вновь созданный класс передаются некоторые переменные которые известны классу mainWindow. вот и был вопрос, как достать их из mainWindow в child.. сначала делал это с помощью парентов, а потом уже переменные стал при инициализации child'a передавать..

Если переменные из mainWindow являются константами для child - передавай их при конструировании child, если в процессе работы эти переменные могут меняться и об этом изменении должен узнавать child сделай связь через сигналы. Тогда ты избавишься от жестких связей между объектами mainWindow и child.

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

Попробуй посмотреть, что возвращает каждый из parent() в твоих случаях.

Код

C++ (Qt)
QObject *parent1 = parent();
Q_ASSERT( parent1 );
qDebug() << parent1;
 
QObject *parent2 = parent1->parent();
Q_ASSERT( parent2 );
qDebug() << parent2;
 
QObject *parent3 = parent2->parent();
Q_ASSERT( parent3 );
qDebug() << parent3;
 

[Krow]

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

[BRE]

ды, вопрос конечно не совсем по разделу но всё же, чтобы не открывать новую тему. можите написать пример как правильно инициализировать транзации в БД?

bool QSqlDriver::hasFeature ( DriverFeature feature ) const + QSqlDriver::Transactions
bool QSqlDatabase::transaction ()
bool QSqlDatabase::commit ()
bool QSqlDatabase::rollback ()

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

Код

C++ (Qt)
// Убьется сам
{
	QSqlQuery q;
	...
}
 
// Убъем руками
{
	QSqlQuery *q = new QSqlQuery;
	...
	delete q;
}
 

[Krow]

bool QSqlDriver::hasFeature ( DriverFeature feature ) const + QSqlDriver::Transactions
bool QSqlDatabase::transaction ()
bool QSqlDatabase::commit ()
bool QSqlDatabase::rollback ()

а правильно вызывать как? опять же сори просто с ними ещё не сталкивался..  и есть ли в этом механизме проверка успешна ли транзакция или нет..

Код

C++ (Qt)
// Убьется сам
{
	QSqlQuery q;
	...
}
 
// Убъем руками
{
	QSqlQuery *q = new QSqlQuery;
	...
	delete q;
}
 

ага, пасиб. так и думал, но на всякий случай переспросил..
delete я так понимаю любой объект убивает?

[BRE]

а правильно вызывать как? опять же сори просто с ними ещё не сталкивался..

Посмотри в assisten документацию по модулю QtSql. Так есть раздел Transactions с примером использования.
В общих чертах:
* Начинаешь транзакцию QSqlDatabase::database().transaction()
* Выполняешь запросы
* Если произошла ошибка, то вызываешь QSqlDatabase::database().rollback(), которая откатит все до состояния перед началом транзакции.
* Иначе (все хорошо) фиксируешь все в базе QSqlDatabase::database().commit()

и есть ли в этом механизме проверка успешна ли транзакция или нет..

Так эти функции все результат возвращают.

[Krow]

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

[Krow]

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

Код:

object_cast<mainWindow *>(parent()->parent()->parent())->ui.actNumberSklad->setText(dirCount);

вообще нифига не даёт.. просто тихое молчание без вылезаний в qDebug()

[Igors]

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

Код:

object_cast<mainWindow *>(parent()->parent()->parent())->ui.actNumberSklad->setText(dirCount);

вообще нифига не даёт.. просто тихое молчание без вылезаний в qDebug()

Уберите порнуху (parent()->parent()->parent()) - тогда и поговорим