Есть Dialog based приложение, из которого читается файл. При этом приложение выжирает все доступные ресурсы процессора во время открытия при этом GUI подвисает и ProgressBar, показывающий степень открытия не отображается. Единственное, что приходит в голову вызывать по таймеру OnPaint(), правда не помогает.

Буду очень признателен совету.

Если я правильно понял вопрос (то есть у тебя все подвисает =)), то:
посмотри, как происходит чтение файла. Очень часто, просто там случается зацикливание, хотя ты думаешь, что все должно быть легко. Не факт, конечно, что поможет, но ты все равно сначала проверь.

У меня происходит чтение и индексирование файлов, размер которых несклько GB. Делается это построчно циклом while поэтому высокая загрузка системы имхо вполне логична. Проблема в том, что мне надо часть используемых ресурсов перекинуть на отрисовку окна с ProgressBar-ом.

Точно не уверен, но может попробовть сделать потоком?
Скажем рабочий поток будет читать файл и у него будет какой-нибудь флаг о том, насколько он выполнен. А в соответствии с этим флагом в обчном режиме будет происходить отрисовка прогресс-бара

Спасибо, но что-то очень громостко. Ведь то, что имеем дело с открытием файла не принципиально, это может быть любая, жрущая ресурсы операция (например, подсчет числа Пи и т.п.). Должны же быть методы оставить 2-3% процессорных ресурсов на прорисовку окна.  

И как ты себе это представляешь, если все должно выполняться в одном потоке? Ты понимаешь, что такое поток управления? Вот идет твой цикл while, и пока ты из него не выйдешь, ничего другого (в рамках потока) выполняться не может. Либо предусматривай вставки внутри while (типа PeekMessage-DispathMessage), либо читай в потоке.
То же самое относится к любой "жрущей ресурсы" операции. 

Если чесно, не особо  . 


А нельзя ли в двух словах как это делают?

triclosan, все сообщения MFC обрабатываются в основном потоке приложения, в т.ч. WM_PAINT, WM_COMMAND (специально выделил эти два). Так вот, если ты из обработки сообщения (например, кнопку нажал) вызываешь долгую обработку, то пока ты не выйдешь из этого обработчика, НИ ОДНОГО ДРУГОГО сообщения обработано не будет. Т.е., проще говоря, WM_PAINT (запрос рисования) приходить-то будет, но обрабатываться - нет, а только поставится в очередь сообщений. Поэтому, создание другого потока - единственная возможность.

Добавлено @ 10:29 

MSDN и поиск рулит!
В двух словах - описываешь либо глобальную функцию потока, либо RUNTIME CLASS и вызываешь

Но про потоки лучше сначала почитай, там много тонкостей 
Вот здесь
Удачи

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

Dart и Earnest спасибо ребята! Кое-что получилось, но не полностью.

1) Функция должна быть глобальной либо static методом класса. Не в том не в другом случае я не могу обратиться к членам и методам класса MyClassDlg из котрого я ее вызываю. Как это сделать? 

2) Я делаю так:



При этом месседжбоксы начинают появляться только по завершении выполнения Indexing(). Догадываюсь, что должно помочь вызывание Indexing() в отдельном потоке, хотя не логично...

Самый простой способ получить контроль над каким-либо объектом в потоке, передать его в качестве параметра
еще раз:

Вот это то, что тебе надо.
Функция не обязательно должна быть описана как static или глобальная.
Второй метод вызова потока - с использованием RUNTIME CLASS - только учти, что сам объект класса создается именно при старте потока. Такой метод очень удобен, когда надо вызвать, например, немодальный диалог, в котором данные обрабатываются независимо от основного приложения. При этом убивать поток надо тоже в этом классе.


Поставь Sleep перед Indexing - а лучше ПОЧИТАЙ ПРО ПОТОКИ!
2 Earnest, 

Я исходил из того, что чел своих потоков не создавал. Я исходил из того, что в MFC основное окно принадлежит одному потоку и все мессаги сыплются именно в него 

Это сообщение отредактировал(а) Dart - 22.8.2006, 18:10

Вобщем сделал так:

все-таки создал static метод класса МyClassDlg вызываю таким путем 

обращаюсь к методам класса МyClassDlg путем компонента http://www.codeproject.com/threads/memberthread.asp 

На моей машине все отлично работает, а на некоторых других вылетает с ошибкой при закрытии потока. Поток закрываю путем возвращения "0" функцией UINT МyClassDlg::proc1. Могут ли ошибки на других машинах быть вызваны опцией THREAD_PRIORITY_TIME_CRITICAL? Если нет, то чем  ? Создаю поток proc1 из потока окна, может надо создавать раньше?...

Возможно, надо использовать на других машинах "мои" Dll-ки? Только вопрос - все, что юзает приложение или только некоторые  ...

Может кто-то даст ссылки, на то как можно использовать дамп памяти ошибки.