bnk>Многоуважаемый Tom, я думаю, что знаю, что такое ConnectionPoint, и с чем ее едят. В письме я подразумевал под 'зажечь event' именно вызов через ConnectionPoint. Я понимаю, что можно зажечь event из второй thread, и знаю, как отмаршалить InterfacePointer для этого. Проблема в том, что Зажигать Event из этой thread нельзя, т.к., повторяю, этот thread Не должен тормозиться, а именно это и произойдет, если сделать вызов на ConnectionPoint оттуда.
В таком случае многоуважаемый bnk вы должны не извращаться, а писать свой маршалер. Хотя...
Спасибо, Vi2, у меня к вам вот какой вопрос: Т.к. Мой компонент в STA, то, кажется, вызов на ConnectionPoint должен его блокировать, пока он не отработает. Однако, он диспатчит WM_MY, пока отрабатывает ConnectionPoint. В этом и проблема, я думаю. Вопрос: Можно как-нибудь запретить диспатч WM_MY, пока отрабатывает вызов ? Это бы сразу все решило.
Здравствуйте bnk, Вы писали:
bnk>Спасибо, Vi2, у меня к вам вот какой вопрос: Т.к. Мой компонент в STA, то, кажется, вызов на ConnectionPoint должен его блокировать, пока он не отработает. Однако, он диспатчит WM_MY, пока отрабатывает ConnectionPoint. В этом и проблема, я думаю. Вопрос: Можно как-нибудь запретить диспатч WM_MY, пока отрабатывает вызов ? Это бы сразу все решило.
Я с окнами не в ладах. Может быть Ivan сможет ответить?
Здравствуйте bnk, Вы писали:
bnk>Здравствуйте Ivan, Вы писали:
I>>Советую не обращать внимания на эту странность IDE
bnk>Я бы наплевал на IDE, но объект-то используется из Access (VBA). А там то же самое, что и с IDE.
Может имеет смысл попробовать вместо MessageBox использовать модальный диалог (как описывается в Q178078 ) ? События то глотаются только для MessageBox'а
Здравствуйте Ivan, Вы писали:
I>Может имеет смысл попробовать вместо MessageBox использовать модальный диалог (как описывается в Q178078 ) ? События то глотаются только для MessageBox'а
Чертов MsgBox, чтоб его раскорячило
Кстати, я спрашивал у Vi2, он предложил у вас спросить, цитирую: bnk>Спасибо, Vi2, у меня к вам вот какой вопрос: Т.к. Мой компонент в STA, то, кажется, вызов на ConnectionPoint должен его блокировать, пока он не отработает. Однако, он диспатчит WM_MY, пока отрабатывает ConnectionPoint. В этом и проблема, я думаю. Вопрос: Можно как-нибудь запретить диспатч WM_MY, пока отрабатывает вызов ? Это бы сразу все решило.
Vi2> Я с окнами не в ладах. Может быть Ivan сможет ответить?
Здравствуйте Tom, Вы писали:
Tom>В таком случае многоуважаемый bnk вы должны не извращаться,
Tom, что имеется в виду под 'извращаться' — то что я делаю, неверно в принципе? Ситуация следующая: этот самый объект завязан на COM-порт(разбирает приходящие данные), и хочется периодически получать от него event-ы по поводу прибытия определенных данных, но чтобы сам он по-прежнему занимался портом. Tom> а писать свой маршалер.
'писать свой маршалер' — что вы имеете в виду ?
Здравствуйте Николай Белых, Вы писали:
НБ>Здравствуйте Ivan, Вы писали:
НБ>Кстати, я спрашивал у Vi2, он предложил у вас спросить, цитирую: bnk>>Спасибо, Vi2, у меня к вам вот какой вопрос: Т.к. Мой компонент в STA, то, кажется, вызов на ConnectionPoint должен его блокировать, пока он не отработает. Однако, он диспатчит WM_MY, пока отрабатывает ConnectionPoint. В этом и проблема, я думаю. Вопрос: Можно как-нибудь запретить диспатч WM_MY, пока отрабатывает вызов ? Это бы сразу все решило.
Можно попробовать вместо оконных сообщений использовать еще 1 доп. поток, который будет посылать сообщения клиенту. С потоком общаться с помощью PostThreadMessage. Этот "поток для событий" попробовать поместить в MTA
НБ>Кстати, я спрашивал у Vi2, он предложил у вас спросить, цитирую: bnk>>Спасибо, Vi2, у меня к вам вот какой вопрос: Т.к. Мой компонент в STA, то, кажется, вызов на ConnectionPoint должен его блокировать, пока он не отработает. Однако, он диспатчит WM_MY, пока отрабатывает ConnectionPoint. В этом и проблема, я думаю. Вопрос: Можно как-нибудь запретить диспатч WM_MY, пока отрабатывает вызов ? Это бы сразу все решило.
Я думаю,проблема все-таки у VB, а управление он просто сразу возвращает, поэтому узнать, когда закончился обработчик событий у VB не получится. ИМХО самое простое решение — использовать модальный диалог "замасированный" под MessageBox
НБ>Tom, что имеется в виду под 'извращаться' — то что я делаю, неверно в принципе?
Абсолютно правильно. То, как вы пытаетесь решить проблемму, это ,если более мягко, абсолютно не по комовски. Правильное решение — это организовать обмен при помощи IStream (именно так делает урловый моникёр, а задача у него такая же — читать данные из сети и иногда извещать об этом эксплорер) который либо прежде надо реализовать (тут можно предусмотреть различные вырианты кэширования), либо (если лень) используйте реализацию на файл (вариантов миллион). Основная идея такая: В ваш поток передаётся IStream (благо про маршалинг вы уже знаете), который туда пишет (и никаких блокировок, а если ещё и самому IStream написать на память например, которую иногда можно скидывать в файл если читающий запаздывает, что то меня в сторону виртуальной памяти понесло...). Далее тот, кому надо читать из него спокойно читает. Итд... Тут я думаю всё понятно.
НБ>'писать свой маршалер' — что вы имеете в виду ?
То и имею. Кидать события через ConnectionPoint, но использовать ручной маршалинг для событийного интерфейса, а там опять же вариантов много.
Выбирать вам, так как любое (даже не очень красивое) решение можно довести до работающего варианта, вот только потом, когда скажут: "А напиши ты нам ещё..." часто приходится переписывать заново.
Здравствуйте Tom, Вы писали:
Tom>То и имею. Кидать события через ConnectionPoint, но использовать ручной маршалинг для событийного интерфейса, а там опять же вариантов много.
ИМХО, жирно будет — использовать для этого дела ручной маршалинг, как это определает статья Секреты маршалинга
Здравствуйте Tom, Вы писали:
НБ>>Tom, что имеется в виду под 'извращаться' — то что я делаю, неверно в принципе? Tom>Абсолютно правильно. То, как вы пытаетесь решить проблемму, это ,если более мягко, абсолютно не по комовски. Правильное решение — это организовать обмен при помощи IStream (именно так делает урловый моникёр, а задача у него такая же — читать данные из сети и иногда извещать об этом эксплорер) который либо прежде надо реализовать (тут можно предусмотреть различные вырианты кэширования), либо (если лень) используйте реализацию на файл (вариантов миллион). Основная идея такая: В ваш поток передаётся IStream (благо про маршалинг вы уже знаете), который туда пишет (и никаких блокировок, а если ещё и самому IStream написать на память например, которую иногда можно скидывать в файл если читающий запаздывает, что то меня в сторону виртуальной памяти понесло...). Далее тот, кому надо читать из него спокойно читает. Итд... Тут я думаю всё понятно. НБ>>'писать свой маршалер' — что вы имеете в виду ? Tom>То и имею. Кидать события через ConnectionPoint, но использовать ручной маршалинг для событийного интерфейса, а там опять же вариантов много. Tom>Выбирать вам, так как любое (даже не очень красивое) решение можно довести до работающего варианта, вот только потом, когда скажут: "А напиши ты нам ещё..." часто приходится переписывать заново.
Что-то я не улавливаю смысла в этой рекомендации Задача то стоит в том чтобы евенты обрабатывались асинхронно от работы потока, который читает из порта. А тут получается так: поток пишет в стрим, потом через механизм ConnectionPoint рожает евент, обработчик евента читает из стрима, А ПОТОК ТО ВИСИТ. Где асинхронность?
МА>Что-то я не улавливаю смысла в этой рекомендации Задача то стоит в том чтобы евенты обрабатывались асинхронно от работы потока, который читает из порта. А тут получается так: поток пишет в стрим, потом через механизм ConnectionPoint рожает евент, обработчик евента читает из стрима, А ПОТОК ТО ВИСИТ. Где асинхронность?
Для тех, кто не улавливает:
Было описано 2 РАЗНЫХ способа решения задачи. В 1 события вообще не использовались, во втором использовались. Надеюсь теперь понятно
Может и жирновато, но:
1. Это правильно
2. Хороший способ разобраться с ручным маршалингом, так как всё равно когдан нибудь придётся.
Подсчитаем за и против
Против:
1. Лень разбираться
2. Больше времени для первой версии
За:
1. Решение проблеммы профессиональным способом
2. Довольно простой support проекта в будущем
3. Овладение очень полезной технологией
Насчет IStream — Все так, но как же сообщить 'тому, кому надо читать', что пора это делать? — сам-то он ведь не догадается, т.е. кажется, это та же самая проблема.
А насчет ручного маршалинга — что-то это кажется слишком тяжеловесно для такой, кажется, простой задачи...
bnk>Насчет IStream — Все так, но как же сообщить 'тому, кому надо читать', что пора это делать? — сам-то он ведь не догадается, т.е. кажется, это та же самая проблема.
Эта уже проблемма синхронизации, а не пропадания сообщений. А решить красиво её можно в реализации IStream. А почему вообще по таймеру не читать ?
Здравствуйте bnk, Вы писали:
GS>>Поставь критсекцию на вызов Fire_MY(): bnk>Спасибо за совет, но это не проходит, т.к. ниточка, входящая в обработчик WM_MY, одна и та же при первом и при втором вхождении . Так что при попытке войти в CS во второй раз все просто повисает.
Сильно. А как ты посылаешь сообщение WM_MY? SendMessage? Попробуй PostMessage.
Здравствуйте Tom, Вы писали: Tom>Эта уже проблемма синхронизации, а не пропадания сообщений. А решить красиво её можно в реализации IStream. А почему вообще по таймеру не читать ?
[b]Можно читать и по таймеру[b].
Но тогда это получается уже поллинг (периодический опрос состояния) COM-порта (serial port)
Тогда зачем COM/ActiveX/компонентная технология?
Пишется простенькая dll или встраиваются ф-ции работы с портом в приложение VB и приложение занимается поллингом по таймеру какого-либо устройства/каких-либо устройств. [b](события не используются)[b]
Проблема в том, что тогда приложение занимается тем, что обслуживает порт, тайм-ауты на порт и т.д. А во время очередного опроса пользователь ждет пока он завершится, либо если произошел сбой связи, тайм-аут порта, и чем больше это время, тем больше пользователь ждет.
Автору темы нужны именно события, т.к. тогда приложение отдает все что связано со связью и портом компоненту. Приложение запускает устройство, устройство информирует приложение, поэтому события не должны теряться, и должны обрабатываться в последовательности поступления.
ИМХО: Это я так понял из дискуссии.
Требовалось решить проблему сохранения и генерации события (ий), возникшего во время обработки первого (N-го). Как же решают ее IStream ? Вы бы код привели ?
А вообще хорошая дискуссия!
Задача то стоит в том чтобы евенты обрабатывались асинхронно от работы потока, который читает из порта. А тут получается так: поток пишет в стрим, потом через механизм ConnectionPoint рожает евент, обработчик евента читает из стрима, А ПОТОК ТО ВИСИТ. Где асинхронность? 
