Структура программы

[Junk]

Делаю программу, которая опрашивает доступность определенных хостов путем icmp-сообщений. Т.е. приходится работать с сокетами и на WinAPI.
Есть класс главного диалога
class CMainDlg : public CSimpleDialog<IDD_MAINDLG>, public CWinDataExchange<CMainDlg>
в котором описаны функции отображения всей информации о текущем положении удаленных хостов. Функция работы с сокетами тоже является частью этого класса
MESSAGE_HANDLER(WM_SOCKET, OnSocketOperation)
Сложность состоит в том, что я создал отдельный поток чтения сообщений, пришедших на сокет чтобы не стопорить основное выполнение программы. И не знаю как так ухитриться, чтобы информация пришедших сообщений отображалась в диалоге. Т.е. как сослаться обратно на гланый диалог

[asker]

Я делал подобное, используя MFC, так что скажу - может поможет.
Насколько я тебя понял у тебя есть рабочий поток и есть основной поток, который отвечает за отображение приходящих сообщений.
Если да, то когда ты создаешь поток, то вторым параметром передаешь указатель на что-нибудь, пусть это что-нибудь будет структура, в которой будет член - хендл окна, в котором ты хочешь отображать инфу о приходе сооб.-ий.
А в функции которая ждет сообщения после соотв. строки добавь PostMessage(хендл, WM_READ_MSG,...).
В диалоге создай метод OnReadMsg(...) отвечающий за отображение данных.
WM_READ_MSG - это #define WM_USER+<твое_число>
Да незабудь добавить в карту сообщений.
Но это в MFC

Надеюсь поможет, удачи

[Junk]

Asker,
что значит В диалоге создай метод OnReadMsg(...) отвечающий за отображение данных.?
как конкретно в главном диалоге ловить сообщение WM_READ_MSG?
Пробовал поймать в OnNotify() и в OnCmdMsg(), не выходит. Туда, видно, такие сообщения не посылаются. Где еще можно попробовать?

[nikedeforest]

Смысл состоит в том, что тебе надо создать свое пользовательское сообщение WM_USER+<число>. В функции обработки сообщений диалога ты напишишь реакцию на это сообщение (в твоем случае будет производится отображение информации в диалог). А в потоке чтения ты будешь посылать это сообщение диалогу, когда тебе необходимо будет выводить какую-либо инфу.
Надеюсь понятнее стало.

[Junk]

Нет, не стало
ON_COMMAND(WM_READ_MSG, OnReadMsg) тоже не помогает. КАК мне поймать это сообщение???

[nikedeforest]

Ну а как ты все остальные сообщения ловишь? Так и это лови. Говори подробнее, что у тебя не получается, если есть ошибки, то какие.
Нахрен тебе ON_COMMAND() ?

Код:

//В самом начале файла напиши
#define WM_READ_MSG WM_USER+15;

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
	
	PAINTSTRUCT ps;
	HDC hdc;

	switch (message) 
	{
	case WM_CREATE:
   
		break;

	case WM_COMMAND:

               break;
      case WM_READ_MSG:
//здесь пиши код по выводу инфы в диалог
               break;

А там, где у тебя поток напиши

Код:

PostMessage(<хендл диалога>,WM_READ_MSG,<твой параметр, сам решай что пихать>,<тоже самое>);

[Junk]

Значит для MFC надо вызывать DegWindowProc()!
Так сразу бы и сказал.

Спасибо, nikedeforest. Теперь все заработало

[Alex437]

Нет, не стало
ON_COMMAND(WM_READ_MSG, OnReadMsg) тоже не помогает. КАК мне поймать это сообщение???

Надо ON_MESSAGE, а не ON_COMMAND

[Diletant]

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

[Alex437]

Для MFC-приложений обычно не рекомендуется так делать.
Из МСДН:

As a general rule, a thread can access only MFC objects that it created. This is because temporary and permanent Windows handle maps are kept in thread local storage to help maintain protection from simultaneous access from multiple threads. For example, a worker thread cannot perform a calculation and then call a document's UpdateAllViews member function to have the windows that contain views on the new data modified. This has no effect at all, because the map from CWnd objects to HWNDs is local to the primary thread. This means that one thread might have a mapping from a Windows handle to a C++ object, but another thread might map that same handle to a different C++ object. Changes made in one thread would not be reflected in the other.

There are several ways around this problem. The first is to pass individual handles (such as an HWND) rather than C++ objects to the worker thread. The worker thread then adds these objects to its temporary map by calling the appropriate FromHandle member function. You could also add the object to the thread's permanent map by calling Attach, but this should be done only if you are guaranteed that the object will exist longer than the thread.

[Diletant]

Вот это

Функция работы с сокетами тоже является частью этого класса

я воспринял именно как:

a thread can access only MFC objects that it created.

[Alex437]

Функция работы с сокетами тоже является частью этого класса

Но работать-то с этим классом предполагается из другого потока. Так что безопаснее посылать сообщения.

Хотя в целом возможно это не такой уж однозначный вопрос. Я не так давно обсуждал эту тему на другом форуме и там продвинутые форумчане в основном сошлись на том, что инфа в статье, из которой я приводил цитату, несколько преувеличена. Что мол "map from CWnd objects to HWND" используется для получения указателя на класс по хэндлу окна, но не наоборот, поэтому при передаче указателя не должно быть проблем. И что мол в статье никакой аргументации толком нет.
Но я все же не решаюсь закрыть глаза на эту статью и передавать указатель. В общем было бы интересно разобраться в этом вопросе.