открыл этот бинарник программой dependency walker - там все зависимости только от MS-библиотек, от Qt нету вообще...

9+ МБ, при статической сборке в VisualStudio получается 12+ Мбайт (у мелокомягких всегда жира больше...  )

собирал и динамически, получалось приложение ~700 кБайт, как и должно быть (размер моей библиотеки ~650 кБайт)
глюк победил, действительно была предыдущая версия библиотек сбоку, и в PATH вкралась незаметная ошибка, все поправил, запускается, но тем не менее вопрос, почему оно лазит в DLL

переменные среды проверял, вроде все верно, ссылки только на QTDIR=c:\qt\2009.03\qt и в PATH только туда же маршрут прописан

рядом с .exe никаких .dll нет вообще

но почему оно вообще обращается к своим .dll если приложение собрано (по идее должно быть собрано) статически?

На QGraphicsScene присутствует некоторая схема. Она изображается в соответствующем QGraphicsView. Когда сцена больше, чем вьюпорт, и мы изменяем текущий элемент так, что он остается виден во вьюпорте, то вместо того, чтобы просто перейти на другой элемент, QGraphicsView перемещает вьюпорт так, чтобы новый элемент оказался на той же позиции в окне, что был предыдущий. То есть, при любых перемещениях окно вьюпорта ползает над схемой, даже если просто переместились в ней на близко расположенный соседний элемент. Это очень здорово для каких-нибудь карт, или просмотра фотографий, но нам совершенно не подходит. Что сделать - не знаем, пробовали разные варианты. Как заставить вьюпорт перемещаться на схемой тогда и только тогда, когда текущая позиция оказалась вне вьюпорта?

такой эффект получаю, когда устанавливаю курсор программно, если курсор устанавливать кликом мыши, то он устанавливается, но вьюпорт не перемещается (как и должно быть)

где собака порылась?

собираю приложение в QtCreator 1.2.1 от Qt 4.5.3, сборка статическая, файл .pro имеет вид:


сборка в профиле Debug, библиотека собрана в аналогичном профиле, приложение собирается статически, получается .exe размером 9+ мегабайт, но при запуске выдает транспарант


с таким ни разу не сталкивался, как это победить?

пробовал собирать динамически, тоже самое

кстати, если не указать библиотеки QtGuid4 и QtCored4, то почему-то автоматически подставляются их версии без отладчика QtGui4 и QtCore4, и все равно не работает

все уже давно работает вот в таком варианте

хм... вроде я так тоже пробовал...

хотя мог пропустить этот вариант от усталости в пятницу

так тоже нельзя

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

в описание qmake я смотрел, способа это сделать не нашел, если есть, ткните меня носом

пришлось функции в переходнике на С передавать, причем достаточно одного переходника, у него параметр "указатель на функцию", ее тип уже нормально приводится

в смысле?

retval = add_ptr( (void*) mvardel); // ??

такое он тоже не пропускает, ругань про недопустимое преобразование типа (*)(int,int) в void*

для работы с библиотекой, написанной на С, надо заносить по указателю void* указатели на функции-колбэки (они написаны на С)

вот такое вот

    extern "C" void* add_ptr( void* );
    extern "C" void mvardel( int,int );
....
    retval = add_ptr( reinterpret_cast<void*>(mvardel) );


MinGW, как баран, уперся и ругается, что ISO C++ запрещает преобразовывать указатель на функцию в указатель на объект

при чем тут Qt? при том, что проект переносится на Qt и отлаживается в QtCreator, соответственно используется qmake

бубны и чтение мануалов не помогает - возможности отключить контроль этого преобразования у компилятора в файле проекта qmake найти не удалось, искать такой ключ у GCC даже не стал, потому как не вижу как передать влоб ключи компилятору из проекта

есть тут прямой путь?

или только в обход идти, создавая функции-переходники на С, и втыкая их между колбэками и кодом на С++, и add_ptr вызывать в переходниках
это придется на каждый колбэк переходник делать, их несколько десятков, и вызываются они из разных мест, все перепахивать надо...

/*причем Visual Studio это все пропускает даже без замечаний и все прекрасно работает*/

траблы продолжаются...

в виндах не хочет работать символьная отладка, ни в какую - уже и Каспера отключал, и защиту COMODO, и пересобирал несколько раз бинарник - ничего не помогает

gdb и само приложение висят в памяти, но при запуске на отладку остановка не на контрольной точке, а непонятно где, при этом появляется сообщение Signal recieved, при попытке "войти в функцию" появляется Running... и можно ждать до бесконечности

это так и должно быть, или у кого-нибудь в виндах отладка работает?
....
фухх... это дырка в COMODO v3, с ним GDB не работает

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

хелп!

только начал работать с QtCreator, уже наткнулся - в проекте надо использовать сторонние библиотеки, их хидеры включил в .pro файл, но это не влияет на передачу компилятору - в командной строке компилятору маршруты к этим хидерам не передаются, в результате все <xxx.h> не подключаются, переносить их нельзя - там исходники должны браться частично из двух разных проектов, у них свои инклюды и т.д.

облазил весь Creator - где указать дополнительные маршруты к хидерам, не нашел, пытался прописать их с ключами -I в Projects/Build steps/Make - нифига, в minGW make они передаются, но дальше в gcc уже нет

и где тут указывать маршруты к файлам заголовков?...

там все разрабатывалось с начала 90-х годов, какая тут нафик архитектура?...

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

а если его отделить от приложения, то надо разработать для них интерфейс коммуникации, отработать канал связи между ними - это все дополнительные время и деньги, но... такая функциональность никому не нужна, она не дает ничего полезного, кроме возможности сделать отладчик на целиком бесплатном Qt, что тут же будет компенсировано затратами (зарплатами) на реализацию...

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

то есть, сейчас интегрировать отладчик в приложение - технически и организационно гораздо проще

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