Цитата(SasaVitebsk @ Jun 9 2011, 13:16)
1 - я уже понял в полном объёме. И вот тут у меня несколько вопросов. Надо ли вообще дизайнер? Или единожды делаешь размещение и лучше больше к нему не возвращаться? Он там хидер генерит автоматически и в случае изменений, соответственно его херит. Так есть вариант просто использовать другой хидер, взявши генерируемый за основу.
Вообще, имхо, нужен. Иногда надо разместить виджеты на форме и визуальный режим тут очень кстати. Но это, в общем-то, и всё. Не нужно от дизайнера хотеть кодогенерации, код лучше писать самому. С него достаточно того, что он позволяет настроить геометрию графических объектов - делать это в коде менее удобно, т.к. обычно приходится делать несколько итераций, чтобы добиться приемлемого вида.
Сам дизайнер держит всю информацию об объектах на форме в .ui файле. Он также генерит заголовок ui_xxx.h и может вставлять код (слоты в основном) при команде "Перейти к слоту...". Заголовок ui_xxx.h руками править не надо.
Цитата(SasaVitebsk @ Jun 9 2011, 13:16)
)) Не пинайте больно - я ещё сквозную идею не ухватил пакета. В дельфях форма менялась по ходу написания неоднократно. Часто так и писалось. Накидал компонентов - обработал, накидал ещё.
Ну, и тут так же. Только тут нет на форме невизуальных компонентов. Тут форма - это чисто для создания внешнего вида. Это у Борланда форма частично использовалась в качестве инструмента кодогенерации - можно было создавать объекты и подключать их к работе прямо мышкой. Потому оно и RAD система. А тут всё традиционно. По большому счёту это правильно, хотя после той расслабухи немного ломает.
Цитата(SasaVitebsk @ Jun 9 2011, 13:16)
Только мне слик не нравится. Вопрос: Зачем среду сборки менять???
Насчёт слика - это вы зря.
Систему сборки я хочу менять потому, что меня тошнит от make и makefiles. Наелся этого. Давно юзаю SCons и очень этим доволен. Вот и хочу поднять сборку на его основе. Закончу этот проектик и попробую перетащить. В принципе, на SConc'е руление опциями проекта будет почти таким же, как и в их .pro файле.
Цитата(SasaVitebsk @ Jun 9 2011, 13:16)
И ещё один вопрос. В одном случае добился (!!) что абсолютно правильный проект вызывал ошибку при сборке. Причём ошибку VS почему-то. С предложением отослать )). Насколько сам пакет устойчиво работает???
У меня бывали падения a-la Segmentaion Fault, но во всех случаях сам был дурак. Как правило к этому приводят ошибки работы с памятью. Тут надо быть аккуратным. И иметь в виду, что ни один виджет не должен создаваться до инициализации приложения (создания объекта QApplication). Иначе работать не будет, а будут только неприятности в виде падений и глюков. Такая там идеология, надо быть в рамках.
Цитата(SasaVitebsk @ Jun 9 2011, 13:16)
3. SQL пока не нужен, но не исключаю естественно. Мне бы больше по работе с железом. Например с портами.
С портами не привелось пока работать. Но думаю, что принципиальных проблем тут быть не должно. Допускаю, что какие-то вопросы возникнут, но это всё обычные рабочие моменты.
Цитата(SasaVitebsk @ Jun 9 2011, 13:16)
4. Насчёт отладки. Я решил, что просто не разобрался. Но пока мне показалось, что отладка ещё хуже чем в D7. Ну она уже и там далеко не на высоте. Насколько я заблуждаюсь?
Отладчик там убогий. Он очень тормозной и весьма глючный. Мне сказали, что он портирован с линуха и там он работает не в пример лучше.
В принципе, сам-то дебаггер там - это GDB, а в оболочка предоставляет только фронт-энд к нему. Фронт-энды к GDB есть и другие, и получше. Слик, кстати, тоже умеет быть фронт-эндом к GDB. Люди, которые пробовали эту связку, отзывались очень похвально (знаю такого человека лично). Когда я переползу на свою среду (слик+сконс), тоже попробую.
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Уход от Delfi, на конторе
Jun 8 2011, 07:29
