Russian Qt Forum

Я когда-то задавал подобный вопрос, приемлемого решения не нашлось на тот момент. Но теперь проблема стала снова и серьезно.

Дело в том, что при использовании функции getOpenFileName в стандартном виде:

C++ (Qt)
QFileDialog::getOpenFileName(<object>, <text>, <directory>,
                        <filter_files>));
 

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

Сделал для функций следующие обертки. Не особо помогло. Чуть быстрее открывается, но задержка есть. Пока полного зависания не наблюдалось, но задержка раздражает:

C++ (Qt)
QString getOpenFileName(QWidget* parent = 0, const QString& caption = QString(""),
						const QString& directory = QString(""), const QString& filter = QString(""));
QStringList getOpenFileNames(QWidget* parent = 0, const QString& caption = QString(""),
						const QString& directory = QString(""), const QString& filter = QString(""));

C++ (Qt)
/// Вызов окна диалога для выбора открываемого файла
QString getOpenFileName(QWidget* parent, const QString& caption, const QString& directory,
						const QString& filter)
{
	QFileDialog file_dialog(parent, caption, directory, filter);
	file_dialog.setViewMode(QFileDialog::Detail);
	file_dialog.setResolveSymlinks(false);
	file_dialog.setFileMode(QFileDialog::ExistingFile);
	if(!file_dialog.exec())
		return QString("");
 
	return file_dialog.selectedFile();
}
 
/// Вызов окна диалога для выбора открываемых файлов
QStringList getOpenFileNames(QWidget* parent, const QString& caption, const QString& directory,
						const QString& filter)
{
	QFileDialog file_dialog(parent, caption, directory, filter);
	file_dialog.setViewMode(QFileDialog::Detail);
	file_dialog.setResolveSymlinks(false);
	file_dialog.setFileMode(QFileDialog::ExistingFiles);
	if(!file_dialog.exec())
		return QStringList();
 
	return file_dialog.selectedFiles();
}

Не слишком помогло. Буду благодарен за помощь!!!

QFileDialog::getOpenFileName показывает родной диалог открытия файлов. Вряд ли тут что-то можно сделать. Я так понимаю точно также "тормозят" любые другие (не-Qt) приложения показывающие родные диалоги?

Можно ещё предложить пингануть сервак перед открытием окошка.... :)

>>Можно ещё предложить пингануть сервак перед открытием окошка....
А толку-то, ну отвалилися он, а окошко-то всё равно открывать.

Я так понял она как раз таки с сервака и открывает файлы....

Нет, просто из-за сетевого окружения, диалог открытия файлов задумывается

Да, тормозят. По крайней мере, MFC-шное тоже задумывается... Так использую неродное уже ведь. Использую Qt-шное....

дак Qt то в свою очередь использует родной диалог)

Почитай про уровни модели OSI тебе все станет понятнее http://www.citforum.ru/nets/switche/osi.shtml . Таким образом и Qt и любое другое не мелокмягкое решение будет тормозить, если, конечно, оно не работает сразу на 3-4 уровне OSI. На сколько я знаю есть у мелкомягких такая переменная управляющая временем ожидания ответа от сетевого интерфейса, но тут есть но, если в сети наблюдается систематический недоперепинг, то с коротким временем ожидания система вероятнее руганется об недоступности удаленного хоста, а он может и прощупался бы, еслиб подождали подольше. И вообще СаМБа - это зло. Помоему на виндовс 7 используется уже другой протокол, и мб там такой беды не будет.  

Думаю, что все-таки есть решение этой проблемы. Ведь не тормозит точно абсолютно такое же окошко, что при вызове статической функции getOpenFileNames(), при открытии нового документа Word, Excel! Только что проверил - моментальное открытие.

Не удается найти решение. А просто как воздух необходимо...
Помогите, пожалуйста! Этот стандартный диалог в Word, Excel, Power Point открывается моментально - это ведь значит, что проблему можно вылечить? Уже весь ассистент перелистал в поисках решения...

Assistant ничем не поможет, особенно учитывая что диалог в MFC тоже тормозит при открытии. Решение я вижу только одно - найти как работают Word/Excel/etc, что они делают особенного что диалог открывается моментально и послать патч в Qt Development Frameworks который исправит проблему.

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

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

Да, в отладчике можно увидеть как свора стандартных dll подгружается при открытии.

У меня была проблема на слабенькой машине тормозил сетевой диск. Выкрутился отключив <filters>, пришлось открывать "anyFile". Хотя это может совсем не тот случай. Сочувствую.

Попробую. Правда, разобраться будет не очень легко. Куча кода с макросами... Но .... попробую....

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

С GUI нельзя работать в других потоках

Еще один тест/зацепка: создать его в нативном коде и посмотреть/поэкспериментировать. В Вындоуз ::GetOpenFileName не так уж сложно

Полез в исходники QFileDialog
Некоторое, непродолжительное время (от 3 до 5 секунд (несмертельно, эти задержки незаметны в релизном режиме)) зависает при создании диалогового окна на функции init, а в ней на функции - restoreState

C++ (Qt)
QFileDialog::QFileDialog(QWidget *parent,
                     const QString &caption,
                     const QString &directory,
                     const QString &filter)
    : QDialog(*new QFileDialogPrivate, parent, 0)
{
    Q_D(QFileDialog);
    d->init(directory, filter, caption);
}
 

Ну а далее основательно зависает на функции exec(), а в ней на строчках:

C++ (Qt)
int QDialog::exec()
{
// ...
 
(void) eventLoop.exec();
 
/// ............
}
 

Как поправить данную проблему?

это не проблема. QEventLoop::exec() запускает цикл обработки сообщений. Копай глубже в чем конкретно проблема.

Ну он крутится внутри цикла

C++ (Qt)
while (!d->exit)
            processEvents(flags | WaitForMoreEvents | ProcessEventsFlag(QEventLoop::DeferredDeletion));
 

функции

C++ (Qt)
int QEventLoop::exec(ProcessEventsFlags flags)
{
Q_D(QEventLoop);
    if (d->threadData->quitNow)
        return -1;
 
    if (d->inExec) {
        qWarning("QEventLoop::exec: instance %p has already called exec()", this);
        return -1;
    }
    d->inExec = true;
    d->exit = false;
    d->threadData->eventLoops.push(this);
 
#if defined(QT_NO_EXCEPTIONS)
    while (!d->exit)
        processEvents(flags | WaitForMoreEvents | ProcessEventsFlag(QEventLoop::DeferredDeletion));
#else
    try {
        while (!d->exit)
            processEvents(flags | WaitForMoreEvents | ProcessEventsFlag(QEventLoop::DeferredDeletion));
    } catch (...) {
        qWarning("Qt has caught an exception thrown from an event handler. Throwing\n"
                 "exceptions from an event handler is not supported in Qt. You must\n"
                 "reimplement QApplication::notify() and catch all exceptions there.\n");
        throw;
    }
#endif
 
    QEventLoop *eventLoop = d->threadData->eventLoops.pop();
    Q_ASSERT_X(eventLoop == this, "QEventLoop::exec()", "internal error");
    Q_UNUSED(eventLoop); // --release warning
 
    d->inExec = false;
 
    return d->returnCode;
}
 

это цикл обработки сообщений (блокирующий, поэтому не нагружающий систему). проблема где-то глубже.

Шагать отладчиком в цикле событий очень тяжело и результат не гарантирует  (времена/таймауты при отладке совсем другие). Не хочу быть навязчивым, но сначала надо выяснить "чья" это проблема: Qt или Вындоуз, поэкспериметировав в нативном коде.

Что значит "нативный"? Если в приложениях Word, Excel, etc. диалог (абсолютно тот же самый) открывается сразу и нет тормозов, то разве это проблемы системы?


Ну нифига себе. Крутился в цикле минут 5, но так и не вышел из него. Куда глубже-то?




Тут возник вопрос такой! :) есть ли возможность программно отключать сеть на время работы этого диалога? Т.е. есть ли возможности включения/выключения сети?

Тут возник вопрос такой!  есть ли возможность программно отключать сеть на время работы этого диалога? Т.е. есть ли возможности включения/выключения сети?

Я бы с выводами не торопился, а толкнул бы сначала ::GetOpenFileName и посмотрел. Если задержки нет - то как минимум 1 решение есть (пусть не самое лучшее).

В смысле толкнул? Простите, но я не понимаю таких терминов. Запустил под отладкой, нативный - "родной"? Почему нельзя сказать понятным языком?
Какое решение? Можно поподробнее, пожалуйста! Я ничего не понял из Ваших фраз...

Запустите профайлер и посмотрите в нем.

Замените вызов кутешного диалога на вызов нативного и посмотрите что будет. Если будет также тормозить, то проблема в нативном диалоге (то есть в системе), если не будет тормозить, то проблема в куте.

Сделайте простую функцию, текст возьмите хотя бы отсюда
http://www.daniweb.com/code/snippet217307.html# (http://www.daniweb.com/code/snippet217307.html#) - это первое что Google нашла на "getopenfilename example". Вставьте вызов этой функции в Вашу программу и выполните ее. Это "native" код, т.е. он будет работать только для платформы Вындоуз. Но как минимум это уточнит где что искать и займет 15 минут.

Ура! :) Стандартная функция Windows GetOpenFileName работает отлично! :)
Выходит, что-то у троллей с QFileDialog не так! Надо будет отчет об ошибке отправить!

С поспешным отчетом можно и лохануться (как я убедился на собственном опыте  :)). В Qt есть 2 возможности: нативный файл диалог (о нем все время и шла речь) и собственный Qt файл диалог. Для отчета как минимум нужно проверить (и сообщить) как ведет себя не-нативный (собственный). Ну и конечно можно найти место где их нативный дает тормоза. Но это непросто и, возможно, сведется к дыре в OS. В конце концов, Вас, как пользователя Qt не должны волновать подробности, это 100% корректно. Но "для понту воровского" (нарисовать  черную кошку и.т.п) - все-таки найти  :)

Тормозят оба. А вот Windows функция не тормозит, проверил на нескольких машинах.

... А разве не их задача найти конкретное место ошибки? Просто.... когда находится место ошибки - то 2/3 работы выполнено, как правило (убедился на своем опыте).

Вот реализация "оберток":

C++ (Qt)
/// Вызов окна диалога для выбора открываемого файла
QString getOpenFileName(QWidget* parent, const char* caption, const char* directory, const char* filter)
{
	const int NAME_SIZE = 550;
	char fname[NAME_SIZE] = {0};		///< буфер для имени файла
	bool result = false;
 
#ifdef Q_WS_WIN
	OPENFILENAME ofn;					///< структура диалога открытия файла
	::ZeroMemory(&ofn, sizeof(ofn));
	ofn.lStructSize = 88;
	ofn.hwndOwner = (parent) ? parent -> winId() : 0;
	ofn.lpstrFile = fname;
	ofn.nMaxFile = sizeof(fname);
	ofn.lpstrFilter = filter;
	ofn.nFilterIndex = 0;
	ofn.lpstrFileTitle = 0;
	ofn.nMaxFileTitle = 0;
	ofn.lpstrInitialDir = directory;
	ofn.lpstrTitle = caption;
	ofn.Flags = OFN_EXPLORER | OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
 
	if(::GetOpenFileName(&ofn) == 1) result = true;
#endif // Q_WS_WIN
 
	return (result) ? QString(fname) : QString("");
}
 
/// Вызов окна диалога для выбора открываемых файлов
QStringList getOpenFileNames(QWidget* parent, const char* caption, const char* directory, const char* filter)
{
	const int NAME_SIZE = 5500;
	char fname[NAME_SIZE] = {0};		///< буфер для имени файла
	QStringList list;
 
#ifdef Q_WS_WIN
	OPENFILENAME ofn;					///< структура диалога открытия файла
	::ZeroMemory(&ofn, sizeof(ofn));
	ofn.lStructSize = 88;
	ofn.hwndOwner = (parent) ? parent -> winId() : 0;
	ofn.lpstrFile = fname;
	ofn.nMaxFile = sizeof(fname);
	ofn.lpstrFilter = filter;
	ofn.nFilterIndex = 0;
	ofn.lpstrFileTitle = 0;
	ofn.nMaxFileTitle = 0;
	ofn.lpstrInitialDir = directory;
	ofn.lpstrTitle = caption;
	ofn.Flags = OFN_ALLOWMULTISELECT | OFN_EXPLORER | OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
 
	if(::GetOpenFileName(&ofn) == 1)
	{
		if(ofn.nFileExtension)
			list << QString(fname);
		else if(ofn.nFileOffset)
		{
			QString path(QString(fname) + QDir::separator()), name("");
			for(int i=ofn.nFileOffset, j=ofn.nFileOffset+1; fname[i]!=0 || fname[j]!=0 || j<sizeof(fname); ++i,
				++j)
			{
				if(fname[i] != 0)
					name += QChar(fname[i]);
				if(fname[j] == 0)
					list << QString(path + name),
					name.clear(),
					++i, ++j;
				if(fname[i] == 0 && fname[j] == 0)
					break;
			}
		}
	}
#endif // Q_WS_WIN
 
	return list;
}

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

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

QFileDialog::getOpenFileName использует ту же самую функцию ::GetOpenFileName и тот же набор флагов - вот его исходники http://qt.gitorious.org/qt/qt/blobs/master/src/gui/dialogs/qfiledialog_win.cpp#line243 - в чем может быть разница?

я правильно понимаю что initialDir - начальный каталог для открытия диалогу установлен в сетевой путь? в каком виде - в виде UNC пути (\\server\share\dir), в виде полного пути (\\\?\server\share\dir) или же подключен сетевой диск?

Набор флагов немножко отличается:

C++ (Qt)
    ofn->Flags = (OFN_NOCHANGEDIR | OFN_HIDEREADONLY | OFN_EXPLORER);
 
    if (mode == QFileDialog::ExistingFile ||
         mode == QFileDialog::ExistingFiles)
        ofn->Flags |= (OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST);
    if (mode == QFileDialog::ExistingFiles)
        ofn->Flags |= (OFN_ALLOWMULTISELECT);
    if (!(options & QFileDialog::DontConfirmOverwrite))
        ofn->Flags |= OFN_OVERWRITEPROMPT;

AD, поиграйся с этими флагами.

Также поставь точку останова на вызове GetOpenFileName в функции qt_win_get_open_file_name и глянь где тормозит - до неё или после. В зависимости от результата точку останова перемещай (локализируй место).

Лицензия есть. Хорошо, поищу на досуге. pastor, Спасибо!

Нет, конечно. Диск совсем несетевой. Путь выглядит так, к примеру:
D:\Projects\Src\TransasLogViewer\SourceData\Airplanes\min_vodi.log