Re[6]: Как получить сообщение из неуправляемой dll - .NET

Здравствуйте, OLLEGator, Вы писали:

OLL>Соответственно есть описание структуры, передающейся на вход:
OLL>struct AsyncQuery
OLL>{
OLL><...> параметры запроса, не омеющие отношения к теме
OLL>HANDLE handle ; — дескриптор окна или потока — получателя информации

Если можно окна , то все просто. Создай невидимое окно(форму) и передай его дескриптор. Это окно и получит сообщение, лови его потом в Control.WndProc .

Меня , правда, одно настораживает. Как это "окна или потока" ? Они там внутри определят, что именно передали ? Вообще-то это возможно (дескрипторы потоков суть малые числа, про дескрипторы окон такое не скажешь), но не очень уж надежно.

OLL>BOOL is_thread ; — true — если получатель информации — поток; если получатель — окно — false
OLL>uint32 msg ; — номер уведомляющего сообщения
OLL>uint32 answer_size ; — размер в байтах буфера под получаемые данные
OLL>void* answer_buf ; — указатель на буфер под получаемые данные
OLL>} ;

OLL>2. Вот как это было мною реализованно:

OLL> AQ.handle = new IntPtr(Thread.CurrentThread.ManagedThreadId);

ManagedThreadId — вовсе не хендл.

Gets a unique identifier for the current managed thread.

Если нужен хендл текущего потока — придется ИМХО использовать Win API. См. в сторону GetCurrentThread, она вернет псевдохендл. Его можно и передать, но только если уверен, что посылка пойдет в том же потоке. Если не уверен — нужно из него сделать настоящий хендл — DuplicateHandle. Не забудь потом CloseHandle.

Здравствуйте, OLLEGator, Вы писали:

Наверное проще сделать наследника от NativeWindow и переопределить в нем WndProc для отлова нужного события( которое наверное нужно зарегестрировать уже не помню)
В WndProc получении нужного Msg получить данные.
http://msdn.microsoft.com/ru-ru/library/system.windows.forms.nativewindow.wndproc.aspx

Здравствуйте, Serginio1, Вы писали:

S>Получи номер сообщения через RegisterWindowMessage и передай его своей длл,

RegisterWindowMessage используется для того, чтобы другие процессы смогли получить идентификатор сообщения по его имени. То есть если два процесса вызовут RegisterWindowMessage с одним именем сообщения, то они получат один и тот-же идентификатор и смогут его использовать для связи друг с другом. В данном-же случае в её вызове нет ни необходимости, ни смысла.

Здравствуйте, OLLEGator, Вы писали:

OLL>Вот, нашёл в самом ДотНет System.Diagnostics.Process:

OLL>

using System.Diagnostics;
OLL>//----------------------------------------------------
OLL>AQ.handle = Process.GetCurrentProcess().Handle;

Это хендл процесса, а не потока.

OLL>Это может заработать? А то я уже запутался... Хендл... Псевдохендл... Поток.... Процесс.... Бррр!!....

Не обижайся, но с этого и надо бы начинать. Ты взялся за программирование не в рамках чистой .Net, а с выходом на неуправлеямый код. Чтобы что-то сделать в этой области. надо понимать Win API, иначе ты ничего путного не сделаешь. Почитай книгу Рихтера по Win32 приложениям (не по .Net!), там все это подробно рассматривается.

P.S. Псевдохендл — это просто величина, которую можно использовать вместо настоящего хендла для вызова функций, требующих этот хендл, но только в рамках своего потока или процесса. Иными словами, в потоке A псевдохендл текущего потока может быть использован для ссылки на поток A, а в потоке B он же окажется ссылкой на поток B. В то время как настоящий хендл потока A можно использовать для ссылки на поток A где угодно в пределах данного процесса.

Здравствуйте, OLLEGator, Вы писали:

OLL>Да и не то что бы я сам очень хотел выходить из ДотНет на неуправляемый код, но пришлось. Там ещё предстоит отдельно разобраться с той самой асинхронной функцией. Ведь эта dll для доступа к комплексу, который для меня -- чёрный ящик.

Я так понимаю, что ты должен вызвать что то из этой DLL, она должна положить что то в буфер который передается в answer_buf
а сообщение ловится через посылку его в окно?
Через создание наследника NativeWindow создаешь окно, у которого получаешь дескриптор окнапредварительно создав его в конструкторе
через

this.CreateHandle(new CreateParams());

Создаешь массив и пинишь его и получаешь его адрес

byte [] buffer = new byte[100*100];
GCHandle gch = GCHandle.Alloc( buffer,GCHandleType.Pinned );
var data = gch.AddrOfPinnedObject(); // получаешь ссылку на массив

Получи номер сообщения через RegisterWindowMessage и передай его своей длл,
и его же отлавливай в WndProc наследника NativeWindow

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Меня , правда, одно настораживает. Как это "окна или потока" ? Они там внутри определят, что именно передали ? Вообще-то это возможно (дескрипторы потоков суть малые числа, про дескрипторы окон такое не скажешь), но не очень уж надежно.

Для этого есть
[b]BOOL is_thread ; — true — если получатель информации — поток; если получатель — окно — false[/b]

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Serginio1, Вы писали:

S>>Получи номер сообщения через RegisterWindowMessage и передай его своей длл,

А>RegisterWindowMessage используется для того, чтобы другие процессы смогли получить идентификатор сообщения по его имени. То есть если два процесса вызовут RegisterWindowMessage с одним именем сообщения, то они получат один и тот-же идентификатор и смогут его использовать для связи друг с другом. В данном-же случае в её вызове нет ни необходимости, ни смысла.

Это будет все же надежнее. Представь себе, что некое иное приложение пошлет сообщение с WM_APP+x бродкастом всем окнам. Да, это дурной стиль, но все же лучше от него защититься.

Есть dllвидимо на С++.
В ней запускается асинхронный метод чтения, который при появлении данных кидает сообщение в указанный поток.
Есть 2 вопроса.
1. Как бы ему указать поток, если он принимает HENDLE, а едиственное, что мною было найдено подходящего в C# -- IntPtr, который непонятно откуда брать, да и его ли.....
2. Как отловить это сообщение? Как я понял, для использования WaitHandle, его должна использовать и передающая и принимающая сторона. GetMessage, используемый в С++ я в C# не нашёл, как и его аналогов.

Пожалуйста, помогите, уже не первый день бьюсь.

нормально начальные условия задачи описывай...

Здравствуйте, OLLEGator, Вы писали:

OLL>Есть dllвидимо на С++.
OLL>В ней запускается асинхронный метод чтения, который при появлении данных кидает сообщение в указанный поток.
OLL>Есть 2 вопроса.
OLL>1. Как бы ему указать поток, если он принимает HENDLE, а едиственное, что мною было найдено подходящего в C# -- IntPtr, который непонятно откуда брать, да и его ли.....
OLL>2. Как отловить это сообщение? Как я понял, для использования WaitHandle, его должна использовать и передающая и принимающая сторона. GetMessage, используемый в С++ я в C# не нашёл, как и его аналогов.

OLL>Пожалуйста, помогите, уже не первый день бьюсь.

С помощью DllImport импортировать функции WinAPI. Более хорошего решения я не знаю.

C>С помощью DllImport импортировать функции WinAPI. Более хорошего решения я не знаю.
Да, но это только первый шаг. Потом импортированная функция даже асинхронно запускается и как-то работает (есть функция, которая проверяет состояние).
Но эта функция должна посылать в основной поток сообщения, но непонятно, чем их отлавливать.

Более подробно сейчас опишу проблему в ответе на сабж.

Здравствуйте, OLLEGator, Вы писали:

OLL>Есть dllвидимо на С++.
OLL>В ней запускается асинхронный метод чтения, который при появлении данных кидает сообщение в указанный поток.
OLL>Есть 2 вопроса.
OLL>1. Как бы ему указать поток, если он принимает HENDLE, а едиственное, что мною было найдено подходящего в C# -- IntPtr, который непонятно откуда брать, да и его ли.....
OLL>2. Как отловить это сообщение? Как я понял, для использования WaitHandle, его должна использовать и передающая и принимающая сторона. GetMessage, используемый в С++ я в C# не нашёл, как и его аналогов.

OLL>Пожалуйста, помогите, уже не первый день бьюсь.

стоит обратить внимание на использование хуков, а также на чтение данных из shared memory
очень будет в тему
http://msdn.microsoft.com/en-us/magazine/cc188966.aspx
удачи

Я писал:
OLL>Есть dllвидимо на С++.
OLL>В ней запускается асинхронный метод чтения, который при появлении данных кидает сообщение в указанный поток.
OLL>Есть 2 вопроса.
OLL>1. Как бы ему указать поток, если он принимает HENDLE, а едиственное, что мною было найдено подходящего в C# -- IntPtr, который непонятно откуда брать, да и его ли.....
OLL>2. Как отловить это сообщение? Как я понял, для использования WaitHandle, его должна использовать и передающая и принимающая сторона. GetMessage, используемый в С++ я в C# не нашёл, как и его аналогов.

OLL>Пожалуйста, помогите, уже не первый день бьюсь.

БОЛЕЕ ПОДРОБНОЕ ОПИСАНИЕ ПРОБЛЕМЫ.

1. Есть функция, которая описанна следующим образом:
uint32 WINAPI QueryAsync( AsyncQuery* query ) ; Асинхронная функция посылки запроса в БД. (База специальная, можно работать только через эту dll)
Возвращает управление сразу после проведения необходимых операций, до того как начнется процесс передачи запроса. Возвращаемое значение — идентификатор этого запроса в Библиотеке.
Библиотека сообщает клиенту о состоянии запроса и поступлении данных посылкой сообщения, указанного клиентом.

Соответственно есть описание структуры, передающейся на вход:
struct AsyncQuery
{
<...> параметры запроса, не омеющие отношения к теме
HANDLE handle ; — дескриптор окна или потока — получателя информации
BOOL is_thread ; — true — если получатель информации — поток; если получатель — окно — false
uint32 msg ; — номер уведомляющего сообщения
uint32 answer_size ; — размер в байтах буфера под получаемые данные
void* answer_buf ; — указатель на буфер под получаемые данные
} ;

2. Вот как это было мною реализованно:

[StructLayout(LayoutKind.Sequential)]
    unsafe public struct AsyncQuery
    {
        public /*??*/IntPtr/*??*/ handle;
        [MarshalAs(UnmanagedType.Bool)]
        public bool is_thread;
        public UInt32 msg;
        public UInt32 answer_size;
        public void* answer_buf;
    }

[DllImport("rtdbconm.dll", EntryPoint = "_QueryAsync@4")]
        public static extern UInt32 RTDBQueryAsync(ref AsyncQuery query);

 public unsafe void TestRunAsync()
        {
            //coздание буфера для получения данных
            uint* pIDAnswerMemo = stackalloc uint[IDArr.Length*3];

            //Сборка запроса
            AsyncQuery AQ = new AsyncQuery();
            AQ.type = 31;
            AQ.oicat = oi;
            AQ.TStart = t;
            AQ.TStop = 0;
            AQ.step = 0;
            AQ.mask = 0;
            AQ.mask_on = 0;
            AQ.mask_send = 0;
            AQ.query_size = (uint)(sizeof(uint) * IDArr.Length);
            AQ.query_buf = pIDArrMemo;
            AQ.handle =  new IntPtr(Thread.CurrentThread.ManagedThreadId);
            AQ.is_thread = true;
            AQ.msg = MMI_Message;
            AQ.answer_size = (uint)(sizeof(OI_Temp) * IDArr.Length);
            AQ.answer_buf = pIDAnswerMemo;

            //Запуск запроса
            uint AQ_id = OIKdllConnect.RTDBQueryAsync(ref AQ);
            Console.WriteLine("ID запроса -- " + AQ_id.ToString());

            // Проверка состояния запроса
            if (OIKdllConnect.RTDBAsyncIsConnect(AQ_id)) <...> // Тут видно, что запрос запущен и активен.

            //!!!!! Вот тут как-то надо ловить сообщения, которые посылает этот запрос  :maniac: 

            //Следующая конструкция не работает, только проверяет работу запроса:
            EventWaitHandle wait = new AutoResetEvent(false);
            for (byte i = 1; i <= 100; i++) // Во время этого цикла запрос падает. Всё время через разное количество итераций (от 50 до 70)
            {
                bool rezult = wait.WaitOne(1);
                if (!rezult) Console.WriteLine("не попали....");

                if (OIKdllConnect.RTDBAsyncIsConnect(AQ_id))
                    Console.WriteLine("И всё-таки он крутится!!...");
                else
                {
                    Console.WriteLine("Сдулся.... (((((  i=" + i.ToString());
                    break;
                }
            }

        }

Вывод: (некоторые текстовые выводы не показанны в тексте,частично они замененны на комментарии)

Сборка запроса
Запуск запроса
ID запроса -- 1
И всё-таки он крутится!!...
не попали....
И всё-таки он крутится!!...
не попали....
И всё-таки он крутится!!...
не попали....
И всё-таки он крутится!!...
не попали....
И всё-таки он крутится!!...
не попали....
Сдулся.... ((((( i=61

ВОПРОСЫ:
1. Как правильно передать ссылку на запускающий поток?
2. Как бы мне отловть сообщения (если они, конечно, дойдут)?....

Некоторые комментарии.
1. При обявлении AsyncQuery.handle как Int32 и передачи в него Thread.CurrentThread.ManagedThreadId, поток не падает, а работает, пока его не закроешь (закрывается штатно, с задерхкой не более секунды). При существующем объявлении поток падает в интервале 50-70 итераций, или ровно между 200 и 250 мс, если выставить ожидание на 50.
Возможно это происходит из-за приходящих в разное время событий, либо из-за длительности работы параллельных потоков системы.
2. Как я понял, EventWaitHandle надо использовать на обоих концах, а не только на приёме, как получилось у меня. Видимо по-этому и не работает.
3. Вот тут описанна функция, которой можно поймать сообщение. При чём, эта же функция показанна в примере для С++. Но как это реализовать на C#, уме не приложу.

З.Ы. Если нужны уточнение, скажите, а то мне не очень видно, как это со стороны видно. Да и не очень понятно, как тут можно редактировать.

Здравствуйте, DuШes, Вы писали:

DШ>Здравствуйте, OLLEGator, Вы писали:

OLL>>Есть dllвидимо на С++.
OLL>>В ней запускается асинхронный метод чтения, который при появлении данных кидает сообщение в указанный поток.
OLL>>Есть 2 вопроса.
OLL>>1. Как бы ему указать поток, если он принимает HENDLE, а едиственное, что мною было найдено подходящего в C# -- IntPtr, который непонятно откуда брать, да и его ли.....
OLL>>2. Как отловить это сообщение? Как я понял, для использования WaitHandle, его должна использовать и передающая и принимающая сторона. GetMessage, используемый в С++ я в C# не нашёл, как и его аналогов.

OLL>>Пожалуйста, помогите, уже не первый день бьюсь.

DШ>стоит обратить внимание на использование хуков, а также на чтение данных из shared memory
DШ>очень будет в тему
DШ>http://msdn.microsoft.com/en-us/magazine/cc188966.aspx
DШ>удачи
Спасибо. Уже появились мысли.

Более полное описание проблемы с кодом и замечаниями в моём ответе на САБЖ.

Здравствуйте, Аноним, Вы писали:

А>нормально начальные условия задачи описывай...

Описал как можно подробнее условия (с кодом) в ответе на САБЖ.

Может Это поможет http://www.rsdn.ru/forum/dotnet/616700.flat.aspx#616700

Здравствуйте, Pavel Dvorkin, Вы писали:

OLL>>2. Вот как это было мною реализованно:

OLL>> AQ.handle = new IntPtr(Thread.CurrentThread.ManagedThreadId);

PD>ManagedThreadId — вовсе не хендл.

PD>Gets a unique identifier for the current managed thread.

PD>Если нужен хендл текущего потока — придется ИМХО использовать Win API. См. в сторону GetCurrentThread, она вернет псевдохендл. Его можно и передать, но только если уверен, что посылка пойдет в том же потоке. Если не уверен — нужно из него сделать настоящий хендл — DuplicateHandle. Не забудь потом CloseHandle.

Вот, нашёл в самом ДотНет System.Diagnostics.Process:

using System.Diagnostics;
//----------------------------------------------------
AQ.handle = Process.GetCurrentProcess().Handle;

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

PD>Если нужен хендл текущего потока — придется ИМХО использовать Win API. См. в сторону GetCurrentThread, она вернет псевдохендл. Его можно и передать, но только если уверен, что посылка пойдет в том же потоке. Если не уверен — нужно из него сделать настоящий хендл — DuplicateHandle. Не забудь потом CloseHandle.

БЛИН!!... я этот GetCurrentThread даже подключить не могу. Не могу найти.

Здравствуйте, OLLEGator, Вы писали:

PD>>Если нужен хендл текущего потока — придется ИМХО использовать Win API. См. в сторону GetCurrentThread, она вернет псевдохендл. Его можно и передать, но только если уверен, что посылка пойдет в том же потоке. Если не уверен — нужно из него сделать настоящий хендл — DuplicateHandle. Не забудь потом CloseHandle.

OLL>БЛИН!!... я этот GetCurrentThread даже подключить не могу. Не могу найти.

Оно Вам не нужно. Эта DLL для отправки сообщения потоку использует PostThreadMessage — иного просто нет — а эта функция принимает именно Thread ID, не Handle.

Сразу предупрежу — я не спец в NET, я его попросту не знаю. Просто сейчас ради любопытства полистал MSDN, и вроде как получается, что без импорта GetMessage или PeekMessage путь у Вас только один — подключить System.Windows.Forms. Далее либо создаёте потомка класса NativeWindow, либо реализатора интерфейса IMessageFilter, которого нужно зарегистрировать вызовом Application.AddMessageFilter. В обоих случаях сам Message Loop запускается вызовом Application.Run, а прерывать его видимо нужно вызовом Application.ExitThread

PS Я бы лучше GetMessage или PeekMessage импортировал

PD>Это хендл процесса, а не потока.

PD>Не обижайся, но с этого и надо бы начинать. Ты взялся за программирование не в рамках чистой .Net, а с выходом на неуправлеямый код. Чтобы что-то сделать в этой области. надо понимать Win API, иначе ты ничего путного не сделаешь. Почитай книгу Рихтера по Win32 приложениям (не по .Net!), там все это подробно рассматривается.

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

Ещё раз спасибо за хорошие советы.

ЗЫ. Все нужные функции, вроде бы, нашёл и подключил. А не ловится и запрос в том комплексе отваливается. ((((

Здравствуйте, Serginio1, Вы писали:

S>Для этого есть
S>[b]BOOL is_thread ; — true — если получатель информации — поток; если получатель — окно — false[/b]

Верно. Я не заметил

Но все же, для потока нужен не дескриптор, а ID. И тут два варианта возможны. Либо надо передавать именно дескриптор, а они из него ID получат, либо все же надо подсунуть ID вместо дескриптора. На Win API такие шутки не в диковинку. ИМХО надо оба варианта пробовать.

Но твой вариант с окном лучше.

Здравствуйте, Pavel Dvorkin, Вы писали:
Поздно нашел, оказывается уже все что нужно ему здесь описано http://rsdn.ru/forum/dotnet/3435889.flat.aspx#3435889 как с NativeWindow так и через IMessageFilter.

Здравствуйте, OLLEGator, Вы писали:

OLL>ЗЫ. Все нужные функции, вроде бы, нашёл и подключил. А не ловится и запрос в том комплексе отваливается. ((((

Ваша проблема в том, что Thread.CurrentThread.ManagedThreadId возвращает нечто левое, а вовсе не системный ThreadID. Вот так работает

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.Runtime.InteropServices;

namespace ConsoleApplication1
{
    [StructLayout(LayoutKind.Sequential)]
    unsafe public struct AsyncQuery
    {
        public /*??*/IntPtr/*??*/ handle;
        [ MarshalAs (UnmanagedType.Bool)]
        public bool is_thread;
        public UInt32 msg;
        public UInt32 answer_size;
        public void* answer_buf;
    }

    unsafe public struct TPoint
    {
        public Int32 X;
        public Int32 Y;
    }

    unsafe public struct TMsg
    {
        public IntPtr hwnd;
        public UInt32 message;
        public UInt32 wParam;
        public UInt32 lParam;
        public UInt32 time;
        public TPoint pt;
    }

    class Program
    {
        public const UInt32 MM_MESSAGE = 0x8001;

        [DllImport("D:\\Program Files\\Borland\\Delphi7\\Projects\\0Proba\\AsyncNetTest\\BIN\\AsyncTest.dll", EntryPoint = "QueryAsync")] 
        public static extern Int32 RTDBQueryAsync(ref AsyncQuery query);

        [DllImport("user32.dll", EntryPoint = "PeekMessageA")]
        public static extern bool PeekMessage(
            ref TMsg lpMsg,      // message information
            IntPtr hWnd,           // handle to window
            UInt32 wMsgFilterMin,  // first message
            UInt32 wMsgFilterMax,  // last message
            UInt32 wRemoveMsg      // removal options
        );

        [DllImport("user32.dll", EntryPoint = "GetMessageA")]
        public static extern bool GetMessage(
            ref TMsg lpMsg,      // message information
            IntPtr hWnd,           // handle to window
            UInt32 wMsgFilterMin,  // first message
            UInt32 wMsgFilterMax  // last message
        );

        [DllImport("Kernel32.dll", EntryPoint = "GetCurrentThreadId")]
        public static extern UInt32 GetCurrentThreadId();
        unsafe static void Main(string[] args)
        {
            byte * pBuf = stackalloc byte[100];
            AsyncQuery AQ = new AsyncQuery();
            // AQ.handle = (IntPtr)Thread.CurrentThread.ManagedThreadId;
            AQ.handle = (IntPtr)GetCurrentThreadId();
            AQ.is_thread = true;
            AQ.msg = MM_MESSAGE;
            AQ.answer_size = 100;
            AQ.answer_buf = pBuf;

            Int32 Ret = RTDBQueryAsync(ref AQ);
            if (Ret != -1)
            {
                TMsg Msg = new TMsg();
                while (GetMessage(ref Msg, IntPtr.Zero, 0, 0 ))
                {
                    if(Msg.message == MM_MESSAGE)
                    {
                        Console.WriteLine("Operation is completed");
                        Console.ReadLine();
                        break;
                    }
                }
            }
        }
    }
}

PS Можете меня поздравить — это моя первая "программа" на C#

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Serginio1, Вы писали:

S>>Получи номер сообщения через RegisterWindowMessage и передай его своей длл,

А>RegisterWindowMessage используется для того, чтобы другие процессы смогли получить идентификатор сообщения по его имени. То есть если два процесса вызовут RegisterWindowMessage с одним именем сообщения, то они получат один и тот-же идентификатор и смогут его использовать для связи друг с другом. В данном-же случае в её вызове нет ни необходимости, ни смысла.
Ух давненько я с винапи не работал. Спасибо. Уже потом сам понял когда написал.

Здравствуйте, Аноним, Вы писали:

А>PS Можете меня поздравить — это моя первая "программа" на C#

Поздравляю. Но это не твоя первая программа на C#, а просто консольное Win API приложение, переведенное на C#

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Это будет все же надежнее. Представь себе, что некое иное приложение пошлет сообщение с WM_APP+x бродкастом всем окнам. Да, это дурной стиль, но все же лучше от него защититься.

А Вы представьте себе, что потолок обвалится

Ну может же такое быть, но это не значит, что надо срочно расставлять подпорки по квартире, тем более, что всё равно не помогут. От дурного стиля защититься невозможно.
В часности, это стороннее приложение с тем-же успехом может отправить broadcast с идентификатором из диапазона, возвращаемого RegisterWindowMessage. С дуру. Это стороннее приложение просто может вызвать RegisterWindowMessage с тем-же именем. Но к данному случаю это не относится, если сообщение отправляется потоку — бродкастов потокам не бывает. Тем не менее, и это не гарантия — дурное сторонне приложение вполне способно с дуру отправить своё сообщение нашему потоку. В общем, RegisterWindowMessage никоим образом не гарантирует от опасности нарваться на дурака, а значит и смысла в его использовании нет. Кто захочет, тот нагадит.

PD>Поздравляю. Но это не твоя первая программа на C#, а просто консольное Win API приложение, переведенное на C#

Разве от этого оно превратилось в приложение на бейсике или яве

Здравствуйте, Pavel Dvorkin, Вы писали:

И кстати, совсем ведь забыл, даже проверять пришлось

Сообщения с номером WM_USER и выше система просто не рассылает бродкастом, так что выбор в качестве сообщения WM_APP + x уже гарантирует от этого

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Pavel Dvorkin, Вы писали:

А>И кстати, совсем ведь забыл, даже проверять пришлось

Сообщения с номером WM_USER и выше система просто не рассылает бродкастом,

При чем тут система ? Я из своего приложения его разошлю

так что выбор в качестве сообщения WM_APP + x уже гарантирует от этого

От чего гарантирует ? От того, что некое глупое приложение его не пошлет ?

Здравствуйте, Аноним, Вы писали:

А>А Вы представьте себе, что потолок обвалится

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

А>В часности, это стороннее приложение с тем-же успехом может отправить broadcast с идентификатором из диапазона, возвращаемого RegisterWindowMessage. С дуру.

Ты его номер сначала получи

>Это стороннее приложение просто может вызвать RegisterWindowMessage с тем-же именем.

Дизассемблить мое приложение будешь в поисках этой строки или же API Mon запустишь для этой цели ?

>Но к данному случаю это не относится, если сообщение отправляется потоку — бродкастов потокам не бывает.

Верно, но обсуждался еще и вариант посылки окну.

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

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

PD>>Поздравляю. Но это не твоя первая программа на C#, а просто консольное Win API приложение, переведенное на C#

А>Разве от этого оно превратилось в приложение на бейсике или яве

Нет

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Pavel Dvorkin, Вы писали:

А>>И кстати, совсем ведь забыл, даже проверять пришлось

Сообщения с номером WM_USER и выше система просто не рассылает бродкастом,

PD>При чем тут система ? Я из своего приложения его разошлю

PD>так что выбор в качестве сообщения WM_APP + x уже гарантирует от этого

PD>От чего гарантирует ? От того, что некое глупое приложение его не пошлет ?

Сами Вы не можете ничего разослать. Вы можете только попросить систему сделать это.

Вы не поняли. Я это тоже не сразу вспомнил, даже проверять пришлось. Попытка выполнить SendMessage(HWND_BROADCAST, MsgId, ...) с MsgId из диапазона от WM_USER до 0xC000 — 1 ни к чему не приводит, сообщение просто не рассылается. И это и есть гарантия.

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

В общем, дело явно перешло в разряд "спор ради спора", а мне такие дискуссии не интересны. Хотите регистрировать, регистрируйте на здоровье

	От:	Pavel Dvorkin
	Дата:	19.06.09 07:53
	Оценка:	+2

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	20.06.09 13:18
Оценка:	+2

	От:	Аноним
	Дата:	22.06.09 13:30
	Оценка:	+1 -1

	От:	Pavel Dvorkin
	Дата:	22.06.09 05:51
	Оценка:	+1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	22.06.09 11:32
Оценка:	+1

	От:	OLLEGator
	Дата:	18.06.09 17:26
	Оценка:

	От:	OLLEGator
	Дата:	23.06.09 13:38
	Оценка: