Описание для Qt4, для Qt5 по идее ничего не должно изменится (подробнее ищи в её документации

нет, в справке:

QTreeWidgetItem *item= tree->currentItem();

QTreeWidgetItem *parent = item->parent();
     int index;

     if (parent) {
         index = parent->indexOfChild(tree->currentItem());
         delete parent->takeChild(index);
     } else {
         index = treeWidget->indexOfTopLevelItem(tree->currentItem());
         delete tree->takeTopLevelItem(index);
     }

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

а куда выводишь? в винде в командную строку?
Тогда конвертируй QString к "IBM-866"

QTextCodec *outCodec = QTextCodec::codecForName("IBM-866"); // Добавь
...
qDebug() << outCodec->fromUnicode(stream.readLine()); // Измени

а зачем ты к QObject * приводишь? Так ты из QVariant-а только указатель на QObject и сможешь вынуть.

См. доку по
T QVariant::value () const
и void QVariant::setValue ( const T & value )
Этого достаточно

Два замечания:
1) чтобы демка собралась с Qt4 нужно поправить код [attachment=1939:patch0.zip]
2) С дизайнером не разобрался, какое-то месиво из полей наложенных друг на друга, не понятно как это создано, как будет выглядеть и как редактировать.

Напрашивается сделать класс описывающий и устройство и виджет для его управления.
Добавление устройства - создание экземпляра класса (объекта), отображение странички с его настройками вызовом функции класса widget(), которая создаст виджет со всем его содержимым и вернёт указатель.

Ну а данные хранить в виде полей этого класса (вместо отдельной структуры.

Если класс обозвать Device, то список устройств: QList<Device*>

class Device: public QObject
{
Q_OBJECT

    explicit Device(QObject parent=0);
    ~Device(){}
    
    
    QWidget* widget();
    
    void setData1(Type1 value);
    Type1 data1();
    //...
    void setDataN(TypeN value);
    TypeN dataN();


private:
    Type1 _data1;
    // ...
    TypeN _dataN;

}

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

Меня реализация QSettings бесит давно и основательно.
Всё что нужно было сделать это конструктор:
QSettings ( const QIODevice & iodevice, QObject * parent = 0 )
вместо
QSettings ( const QString & fileName, Format format, QObject * parent = 0 )

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

Выход из положения - зарегистрировать свой формат, через
registerFormat()

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

[attachment=1873:screen_radiobutton.png]
[attachment=1874:radiobutton.ui.zip] (отрежь фиктивное расширение)

П.С. делал в Qt 4.7.4

меняются, поведение зависит от настроек.
Запустите "Example and Demos" выберите пункт "Demonstrations" -> "Mainwindow"
потаскайте DockWidget-ы
[attachment=1869:screen.png]

Вставь в цикл: QCoreApplication::processEvents()

Amadey, используй тэг code при оформлении сообщений содержащих фрагменты исходных кодов

У Экселсиора простой установщик есть, попробуй им

Тут правильнее речь вести об объекте (экземпляре класса). В каком потоке ты его создаёшь, в том он и будет жить.

class MyLib : public QObject
MishaUA, не вижу у тебя инициализации структуры w

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

class MyWidget : public QWidget
{
public:
    MyWidget (arg1, arg2, ...);

}

MyWidget* creatMyWidget(arg1, arg2, ...)
{
    return new MyWidget(arg1, arg2, ...)
}

    QLibrary    *lib = new QLibrary("d:/MyLib1.dll", this);
    qDebug() << lib->load();

    typedef QWidget* (*CreatMyWidget) ();
    CreatMyWidget    creatMyWidget = (CreatMyWidget)(lib->resolve("widget"));
    QWidget    *w = creatMyWidget();
    ...

к стати говоря, чтобы не было глюков, лучше манипуляции делать через экземпляр QMdiSubwindow, т.е.:

QMdiSubWindow *sub = ar->addSubWindow(child);
sub->show(); // командуем субокну, а не виджету

По мотивам документации, написана статья в нашей Вики: Развертывание приложений Qt в MS Windows

Если ты хочешь проверить успешность запроса, то смотри что возвращает exec(), а не активность/неактивность. Часто isActive() будет возвращать Ложь
Нет
Транзакции лучше применять всегда явно.

Но драйвер Qt для Firebird убогий, в нём нельзя задавать тип транзакции.

на мой вгляд это:
лишнее условие
потому что, когда ты не начинаешь транзакцию явно, то транзакция создаётся не явно, т.е. будет пачка транзакций вместо одной, на каждый "бинд". Это даже на SQLite очень хорошо заметно (для ~50 вставок скорость увеличивается в 2-3 раза)


Я обычно оборачиваю в транзакцию, если циклов потенциально может быть больше 5.


У Firebird-а есть точки сохранения (savepoints) и здесь они имеются ввиду. Просто для надёжности, а вдруг связь с сервером прервётся. Но их не поддерживает оригинальный драйвер Qt. На прог.орге человек выкладывал свой драйвер Firebird-а, вроде он их поддерживает.


Это всёго лишь экземпляр класса QSqlQuery, но не запрос с точки зрения СУБД.
Нужно лишь такое:

QSqlDatabase::database().transaction(); // Начали транзакцию
q.exec(squery); // выполнили запрос
QSqlDatabase::database().commit();// зафиксировали, или откатились

Для FB откатыватся при ошибках сильно рекомендую, иначе мертвые транзакции так и останутся в БД, т.к. FB хранит версии своих состояний.

достаточно

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

QString aaa = QObject::tr(QT_TR_NOOP("Hello"));

после

QApplication::installTranslator(&translator);

И, кстати, У тебя масло масленное получилось, используй либо макрос, либо QObject::tr()

у Хелен Бори есть
вот собственно и не думай, оптимизирует сама СУБД, обрати внимание на примеры Qt - QSqlQuery всегда локальная переменная.

Применительно к Firebird.
Из Qt в Qt-драйвер БД отправляется срока prepare и пачка (массив) аргументов, этот драйвер прям как есть всё отправляет в Firebird, т.е. строка prepare и массив аргументов.
Firebird по строке prepare строит план запроса и сохраняет его, затем используя массив аргументов сам "биндит" их в план.

В большинстве случаев можно полагать, что сделав с двух разных машин и программ один и тот же prepare Firebird постарается воспользоватся уже подготовленным (с предыдущего события) планом запроса.

Firebird кэширует план запроса, в прочем MySQL тоже должен так делать. Собственно времени больше всего уходит именно на построение плана запроса.

prepare полезно делать в ситуации, когда ты собираешься несколько наборов данных одинаковым запросом отправлять.

П.С.
Обрамить всю пачку prepare-bind в транзакцию - существенно увеличить скорость выполнения этой пачки (для любой БД), а для Firebird-а ещё и меньше мусорить, т.к. он версии состояний хранит.

П.П.С.
Т.к. Firebird версионник, он работает сильно не так как MySql. Недействительным план запроса может стать в других ситуациях.





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

это обращение к члену битового поля (Си)

Глянь QBitArrayВ Qt это не нужно, т.к. есть оператор сдвига в СИ
>>
и
<<
Выдвигаемый бит запоминаешь, потом его "в зад" добавляешь, компилятор это дело просекает и использует соответствующие ассемблерные инструкции.

Да это не страшно, FireBird кэширует подготовленные запросы. (они именно в таком виде и улетают в БД из твоей программы)

по всей видимости это произошло потому, что QSqlQuery будучи членом класса создаётся тогда же когда создаётся экземпляр класса DBFunctions, а он в свою очередь создаётся до соединения с БД. Соответственно этот QSqlQuery пытается работать с недействительным соединением.

В обще его лучше оставить в покое (т.е пусть он будет локальным в функции), заодно и имя ему дать короткое - q.

в представлении ловить или во viewport() представления.

Нашёл!

Форма:

T::operator R();

Означает оператор приведения типа:

(R)

Для определенных пользователем преобразований возвращаемый тип задается неявно и совпадает с именем оператора.

Т.е.

QUuid::operator QString()

для

QString s;
QUuid q;
s = (QString)q;

а

QUuid::operator GUID()

для

GUID w;
QUuid q;
w = (GUID)q;

В Qt есть поддержка POSIX-сигналов, но для Виндовоза видимо придётся писать своё с использованием WinAPI.