Алекс Jenter - Программирование на Visual C++. Архив рассылки Страница 6

 // всю необходимую работу

 // результат запихиваем в память,

 // а адрес на нее – в lpResult

 AfxGetMainWnd()->PostMessage(IID_WORKER_THREAD_END, 0, lpResult);

 // возвращаем код успеха (а вообще это на ваш вкус)

 return 0;

}

void CMyApp::OnStartExecution() {

 // заполняем lpData нужными данными, и вызываем ..

 CWinThread *pThread = AfxBeginThread(WorkerThreadFunction, lpData);

 if (!pThread) {

  // Не смогли запустить поток.

  // Правда обычно этот код не выполняется :)).

  // Я до сих пор не знаю ситуации, когда поток

  // может не запуститься, кроме low memory.

  AfxMessageBox(_T("Can't start thread."));

 }

}

LRESULT CMyApp::OnWorkerThreadEnd(WPARAM wParam, LPARAM lpResult) {

 // тутачки обрабатываем завершение расчетов.

}

Замечания:

1. Объявлять обработчик сообщения ID_WORKER_THREAD_END надо через ON_MESSAGE макрос 

2. Потоков запускать можно сколько душе угодно (если хватает памяти :)) ).

3. Повторюсь: важно понимать, что доступ к данным может быть одновременным из разных потоков. Поэтому необходима синхронизация. чтобы не получилось ситуации, что один поток пишет, а второй читает в одно время – как результат, можно разрушить логическую целостность данных. Поэтому в приведенных примерах лучше сбрасывать данные в отдельный блок памяти и передавать указатель на него. И функция рабочего потока, и обработчик сообщения завершения должны освобождать передаваемую им память.

A4. Самым естественным способом решения задачи n1 является создание дополнительного потока в процессе, который собственно и будет выполнять ту самую длительную операцию. С другой стороны – основной поток должен ожидать завершения операции. Для этого в Win32 существует функция WaitForSingleObject, одним из параметров которой задается описатель ожидаемого потока. Но в этом случае ждущий поток не может обрабатывать сообщения своего окна, так как ему система перестает выделять процессорное время. Здесь можно придумать много разных способов: во-первых, совсем можно обойтись и без функции WaitForSingleObject, создав глобальную переменную, которая при запуске потока инициализируется в false, а по его завершении – в true (или наоборот); можно, кроме того, используя функцию WaitForSingleObject, задавать ей вместо INFINITE лимит времени, по истечении которого будет возобновлено исполнение потока – вся байда проводится в цикле, при каждой итерации которого производится обработка сообщений окна;

Ну вот, на вопрос получены очень хорошие ответы. А о  многозадачности мы еще обязательно поговорим в одном из выпусков. Главное понять – это не так сложно , как кажется! ;)

Q. Можно ли переопределенный обработчик событий сделать подставляемым (inline)? (автор тот же)

На этот вопрос пришел только один ответ, но, на мой взгляд, исчерпывающий, причем тоже от Олега, который умудрился ответить на все заданные в предыдущем выпуске вопросы:

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

Q. Вопрос про ресурсные строки: "…при нажатии на клавишу "Пропустить" программа идет дальше и вываливается на следующей операции загрузки строки с теми же симптомами и так до тех пор, пока не будут загружены все строки. После этого выполнение программы продолжается в нормальном режиме и все остальное работает как надо (строки все-таки загружаются!). В Release-версии программа пролетает это место без спотыканий."

(Полностью  вопрос Евгения см. в предыдущем выпуске, который можно найти по адресу http://subscribe.ru/archive/comp.prog.visualc)

A1. Скорее всего, приложение преобразовано из обычного в MFC и преобразовано некорректно. Нельзя использовать ресурсные функции CString в не-MFC приложении, потому что они требуют специальной инициализации. Другие функции будут работать, а эти нет. Инициализация всех внутренних переменных происходит при инициализации приложения в вызовах AfxWinInit() и прочих служебных функций в AfxWinMain(). Можно посоветовать или сгенерировать приложение заново или использовать код вида:

CString s;

::LoadString(g_hInstance, 12345, s.GetBuffer(256), 256);

s.ReleaseBuffer();

A2. По вопросу о CString::LoadString: Скорее всего, эта функция вызывается до статической инициализации библиотеки MFC. Например, это может произойти в конструкторе объекта, объявленного статическим. Все тот же пресловутый theApp…. :-) Микрософт рекомендует переносить все действия по инициализации в InitInstance, собственно для чего эта ф-ция и предназначена.

A3. А по поводу вопроса в рубрике "В поисках истины" – похоже, что зачитка данных идет в конструкторе CMyApp, а не в InitInstance. Предположение насчет некорректной инициализации похоже правильно.

Огромное всем, кто не поленился  написать ответ, особенно  Олегу – он у нас сегодня рекордсмен!

Ну вот, кажется на все вопросы получены ответы. Полная идиллия… только вот уже поступили новые вопросы… ;)

Q. Просто кульно, что ты взялся за эту рассылку, а то, как ты и говорил, в инете нет рассылок по MSVC++. Сам я за ним сижу уже два года, и всё более углубляясь внутрь, возникают всё новые вопросы ;) Но я ещё маленький ;) Хочу задать тебе вопрос: как делать окна нестандартной формы? Например, круг (как у диска Компьютерры – там окно обычное, но с помощью прозрачности виден только круг, так?)

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

Должен констатировать, что проблема курсоров не закрыта – пришел еще один вопрос:

Q. Хочу поблагодарить за прекрасную рассылку, надеюсь почерпнуть много интересной и полезной информации. Хочу задать несколько вопросов:

1.Что касается курсоров – как все-таки загружать 256-цветный курсор в приложении? Т.е. проблема в том что в редакторе ресурсов можно сделать либо только черно-белый курсов, либо еще и цветной, но при этом LoadCursor загружет только ч.б. Скорее всего ларчик просто открывается, но все же?

2. Еще вопрос, скорее всего тоже очень популярный. Версия Debug работает без проблем, а при запуске версии Release появляется сообщение о недопустимой операции. Хотелось бы знать в чем проблема и пути ее решения.

А вот по второму вопросу хочу порекомендовать посмотреть ответ на вопрос Евгения – чуть выше. Как правило, отказ работать debug-версии значит, что все-таки что-то у вас не так, и для вас же  будет лучше выяснить, в чем именно проблема. Это может быть связано, например, с инициализацией, с памятью и еще с уймой других вещей.

Q. Спасибо за рассылку – наконец-то свершилось! А то по VB их уже несколько, а по VC++ не было до недавнего времени ни одной. У меня есть вопрос по обработке события WM_KEYUP. Играя с диалогом, обнаружил, что он сам никак не реагирует на нажатия клавы. Как решение, использовал следующий способ: для каждого типа контрола делал свой класс, который реагирует на WM_KEYUP, и в обработчике этого события пересылал сообщение окну диалога. Например, для кнопок создал класс CMyButton, наследуемый от CButton, и в функции CMyButton::OnKeyDown() пересылаю сообщение родительскому окну как GetParent()->SendMessage(…). То же самое для других типов контролов по аналогии.

Но такой способ отдаёт некоторой горбатостью, может быть существует какое-то более элегантное решение?

Жду ваших писем с ответами!

Пока все.

Всего вам доброго!

Программирование на Visual C++

Выпуск №6 от 02/07/2000

Здравствуйте, уважаемые подписчики!

Фирма Microsoft  недавно выпустила очередной, четвертый пакет исправлений для Visual Studio 6.0 – Service Pack 4. Он устраняет некоторые ошибки в продуктах VS, а также производит ряд  обновлений.

В Visual C++ 6 исправления касаются STL, MFC, CRT, IDE, самого компилятора, отладчика, и многих других частей, т.е. практически всего.

Следует заметить, что среди исправленных ошибок встречаются действительно критические, которые могут помешать работе. Например, частое использование realloc на маленьких блоках памяти вызывало memory access violation (конфликт при попытке доступа к памяти), а DllMain выбрасывала unhandled exception, если в течение DLL_THREAD_DETACH возникала нехватка памяти. MFC AppWizard неправильно связывал данные с программой при использовании OLE DB ODBC provider и Access.