НБ>Tom, что имеется в виду под 'извращаться' — то что я делаю, неверно в принципе?
Абсолютно правильно. То, как вы пытаетесь решить проблемму, это ,если более мягко, абсолютно не по комовски. Правильное решение — это организовать обмен при помощи IStream (именно так делает урловый моникёр, а задача у него такая же — читать данные из сети и иногда извещать об этом эксплорер) который либо прежде надо реализовать (тут можно предусмотреть различные вырианты кэширования), либо (если лень) используйте реализацию на файл (вариантов миллион). Основная идея такая: В ваш поток передаётся IStream (благо про маршалинг вы уже знаете), который туда пишет (и никаких блокировок, а если ещё и самому IStream написать на память например, которую иногда можно скидывать в файл если читающий запаздывает, что то меня в сторону виртуальной памяти понесло...). Далее тот, кому надо читать из него спокойно читает. Итд... Тут я думаю всё понятно.
НБ>'писать свой маршалер' — что вы имеете в виду ?
То и имею. Кидать события через ConnectionPoint, но использовать ручной маршалинг для событийного интерфейса, а там опять же вариантов много.
Выбирать вам, так как любое (даже не очень красивое) решение можно довести до работающего варианта, вот только потом, когда скажут: "А напиши ты нам ещё..." часто приходится переписывать заново.
Здравствуйте Tom, Вы писали:
Tom>То и имею. Кидать события через ConnectionPoint, но использовать ручной маршалинг для событийного интерфейса, а там опять же вариантов много.
ИМХО, жирно будет — использовать для этого дела ручной маршалинг, как это определает статья Секреты маршалинга
Есть компонент (ATL), а в нем отдельный 'worker thread', который время от времени рождает события, об которых надо сообщать клиенту на VB. Для этого посылает WM_MY окну компонента, оно зажигает событие. Зажигать Еvent из 'worker thread' нельзя (он не должен тормозиться)
Проблема : Если во время обработки одного события в VB (висмт MsgBox) на компонент падает второе WM_MY, он зажигает событие, но это второе просто 'проглатывается' в VB
Вопрос : Есть какой-нибудь простой метод дождаться, пока первый Event отработает, и только потом бросать на клиента второй ? Или делать это надо как-то иначе ?
Здравствуйте bnk, Вы писали:
bnk>Есть компонент (ATL), а в нем отдельный 'worker thread', который время от времени рождает события, об которых надо сообщать клиенту на VB. Для этого посылает WM_MY окну компонента, оно зажигает событие. Зажигать Еvent из 'worker thread' нельзя (он не должен тормозиться) bnk>Проблема : Если во время обработки одного события в VB (висмт MsgBox) на компонент падает второе WM_MY, он зажигает событие, но это второе просто 'проглатывается' в VB bnk>Вопрос : Есть какой-нибудь простой метод дождаться, пока первый Event отработает, и только потом бросать на клиента второй ? Или делать это надо как-то иначе ?
Event обрабатывается синхронно. Т.е. пока твой конрол и VB не обработали первый, второй евент не возникнет. Может как второй WM_MY не доходит до окна контрола?
Здравствуйте Максим Алексейкин, Вы писали:
МА>Event обрабатывается синхронно. Т.е. пока твой конрол и VB не обработали первый, второй евент не возникнет. Может как второй WM_MY не доходит до окна контрола?
Максим, проблема в том что второй евент возникает. Я проверял в дебаггере, ситуация следующая: Входит в обработчик WM_MY, запускается Fire_MY(..), после чего, не выходя из этого обработчика , входит в него повторно ха-ха и снова делает Fire_MY()
Происходит енто, я думаю, потому, что WM_MY's посылаются компоненту той самой 'worker thread' (асинхронно), а когда компонент ожидает 'окончания евета' в Fire_MY(), он радостно диспатчит все WM_xx, и входит в обработчик повторно.
В чем и вопрос, с какой стороны это безобразие можно объехать
Здравствуйте bnk, Вы писали:
bnk>Здравствуйте Максим Алексейкин, Вы писали:
МА>>Event обрабатывается синхронно. Т.е. пока твой конрол и VB не обработали первый, второй евент не возникнет. Может как второй WM_MY не доходит до окна контрола?
bnk>Максим, проблема в том что второй евент возникает. Я проверял в дебаггере, ситуация следующая: Входит в обработчик WM_MY, запускается Fire_MY(..), после чего, не выходя из этого обработчика , входит в него повторно ха-ха и снова делает Fire_MY() bnk>Происходит енто, я думаю, потому, что WM_MY's посылаются компоненту той самой 'worker thread' (асинхронно), а когда компонент ожидает 'окончания евета' в Fire_MY(), он радостно диспатчит все WM_xx, и входит в обработчик повторно. bnk>В чем и вопрос, с какой стороны это безобразие можно объехать
Попробуй ограничить доступ к Fire_MY() при помощи критической секции. Т.е. пока не вернулся из первого евента не делать следующие.
Удачи.
Здравствуйте bnk, Вы писали:
bnk>Максим, проблема в том что второй евент возникает. Я проверял в дебаггере, ситуация следующая: Входит в обработчик WM_MY, запускается Fire_MY(..), после чего, не выходя из этого обработчика , входит в него повторно ха-ха и снова делает Fire_MY()
bnk>В чем и вопрос, с какой стороны это безобразие можно объехать
Поставь критсекцию на вызов Fire_MY():
CComAutoCriticalSection cs; // global
...
cs.Lock();
Fire_MY();
cs.Unlock();
Либо то же самое через объект, лочащий при создании и т.п.
Здравствуйте George_Seryakov, Вы писали:
GS>Здравствуйте bnk, Вы писали:
GS>Поставь критсекцию на вызов Fire_MY():
Спасибо за совет, но это не проходит, т.к. ниточка, входящая в обработчик WM_MY, одна и та же при первом и при втором вхождении :). Так что при попытке войти в CS во второй раз все просто повисает.
Насчет
GS> CComAutoCriticalSection cs; // global
Мне думается, что CComAutoCriticalSection + Single-thread-appartament = Nothing
Мне пока удалось изобрести вот какой объезд на эту проблему :-
list<pair<WPARAM, LPARAM> > m_queue;
LRESULT CCmdShell::OnMY(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
m_queue.push_back(make_pair(wParam,lParam));
if (m_messages.size() == 1) // inside only at 'first' entry
{
while (m_queue.size() > 0) // size may be added with 'recursive' calls
{
pair<WPARAM,LPARAM> p = m_queue.front();
Fire_MY(...); // <-- 'recursive' call from here
m_queue.pop_front();
}
}
}
Здравствуйте bnk, Вы писали:
bnk>Есть компонент (ATL), а в нем отдельный 'worker thread', который время от времени рождает события, об которых надо сообщать клиенту на VB. Для этого посылает WM_MY окну компонента, оно зажигает событие. Зажигать Еvent из 'worker thread' нельзя (он не должен тормозиться) bnk>Проблема : Если во время обработки одного события в VB (висмт MsgBox) на компонент падает второе WM_MY, он зажигает событие, но это второе просто 'проглатывается' в VB bnk>Вопрос : Есть какой-нибудь простой метод дождаться, пока первый Event отработает, и только потом бросать на клиента второй ? Или делать это надо как-то иначе ?
Проблемма состоит в том, что вы АБСОЛЮТНО ИЗВРАЩЁННО реализуете механизм событий. Для таких вещей есть ConnectionPoint..., причём я решал задачу полностью похожую на вашу при помощи ConnectionPoint. (особых проблемм там быть не должно) Если решитесь переделать, то могу помочь кодом (стандартная реализация механизма точек стыковки из ATL вам не подойдёт, так как вы будете вызывать события не из того потока, в котором VB будет "садится" на события и придётся воспользоваться маршалингом, но это довольно просто)
Здравствуйте Tom, Вы писали:
Tom>Проблемма состоит в том, что вы АБСОЛЮТНО ИЗВРАЩЁННО реализуете механизм событий. Для таких вещей есть ConnectionPoint...,
Многоуважаемый Tom, я думаю, что знаю, что такое ConnectionPoint, и с чем ее едят. В письме я подразумевал под 'зажечь event' именно вызов через ConnectionPoint. Я понимаю, что можно зажечь event из второй thread, и знаю, как отмаршалить InterfacePointer для этого. Проблема в том, что Зажигать Event из этой thread нельзя, т.к., повторяю, этот thread Не должен тормозиться, а именно это и произойдет, если сделать вызов на ConnectionPoint оттуда.
Здравствуйте bnk, Вы писали:
bnk>Есть компонент (ATL), а в нем отдельный 'worker thread', который время от времени рождает события, об которых надо сообщать клиенту на VB. Для этого посылает WM_MY окну компонента, оно зажигает событие. Зажигать Еvent из 'worker thread' нельзя (он не должен тормозиться) bnk>Проблема : Если во время обработки одного события в VB (висмт MsgBox) на компонент падает второе WM_MY, он зажигает событие, но это второе просто 'проглатывается' в VB bnk>Вопрос : Есть какой-нибудь простой метод дождаться, пока первый Event отработает, и только потом бросать на клиента второй ? Или делать это надо как-то иначе ?
Здравствуйте Ivan, Вы писали:
I>ЭТО Q178078 случайно не про твою ситуацию ?
Нет, к сожалению Здесь компонент создается из MSAccessa. Но события действительно _НЕ_ случаются, как и должно быть, согласно Q178078. Да я и не хочу, чтобы они случались, пока висит этот чертов MsgBox, но я хочу, чтобы они случились после того, как он ичезнет, черт побери, а не пропали неизвесто где.
Здравствуйте bnk, Вы писали:
bnk>Здравствуйте Ivan, Вы писали:
I>>ЭТО Q178078 случайно не про твою ситуацию ?
bnk>Нет, к сожалению Здесь компонент создается из MSAccessa. Но события действительно _НЕ_ случаются, как и должно быть, согласно Q178078. Да я и не хочу, чтобы они случались, пока висит этот чертов MsgBox, но я хочу, чтобы они случились после того, как он ичезнет, черт побери, а не пропали неизвесто где.
А при выполенении VB кода как exe-шника (не из IDE) они тоже пропадают ?
Здравствуйте Ivan, Вы писали:
I>А при выполенении VB кода как exe-шника (не из IDE) они тоже пропадают ?
Нет, в этом случае они НЕ пропадают , но, согласно тому же Q178078, это не есть хорошо, это есть БАГ у VB, ха-ха.
У меня ситуация близка скорее к описанной в Q196026, но только там не написано, что будет, если worker thread вздумает послать не одно, а несколько сообщений. А будет, похоже, то самое, что они исчезнут, яко тени в полдень, если об этом специально не позаботиться. Я что-то изобрел по этому поводу (см. Re[4] на George_Seryakov), это в общем-то работает, но я не уверен, наколько это есть хорошо...
Здравствуйте bnk, Вы писали:
bnk>Здравствуйте Ivan, Вы писали:
bnk>Нет, в этом случае они НЕ пропадают , но, согласно тому же Q178078, это не есть хорошо, это есть БАГ у VB, ха-ха.
Позволю себе не согласиться. В статье написано , что это поведение by design. Так себя ведет VB IDE.
Ничего страшного в этом нет, главное, что готовое приложение будет работать нормально, а на IDE можно не обращать внимание ( или убрать messagebox из обработчика события)
bnk>У меня ситуация близка скорее к описанной в Q196026, но только там не написано, что будет, если worker thread вздумает послать не одно, а несколько сообщений.
А эта статья ИМХО совсем о другом — когда ты файришь события из другого потока, не замаршалив указатель на синк.К твоей ситуации это неприменимо, так как ты, я так понимаю, файришь события из основного потока.
Здравствуйте Ivan, Вы писали:
I>Позволю себе не согласиться. В статье написано , что это поведение by design. Так себя ведет VB IDE.
К сожалению в статье Q178078 ('98) написано, что это EXE файл ведет себя неправильно(!): 'The behavior in the EXE is incorrect; events should not occur while a Message box is displayed', а в IDE все "хорошо".
А к статье Q196026 это имеет отношение в части того, как предлагается решать проблему маршалинга — сделать окно и послать на него сообщение. Так вот, моя проблема будет, если послать не одно, а несколько сообщений. Во время того, как в VB отрабатывается первый ConnectinoPoint, почему-то диспатчатся остальные посланные сообщения, и начинает отрабатывать второй, который и игнорируется в VB.
Странно, в моей статье (которая на сайте www.microsoft.com) написано вот что
Symptoms
Running a project in the IDE that displays a message box prevents events from occurring. However, when you compile and run the same project as an executable file (EXE), the events occur while the message box is displayed.
Cause
The behavior in the EXE has changed with Microsoft Visual Basic 5.0 and 6.0 so that it is different from earlier versions of Microsoft Visual Basic.
Здравствуйте bnk, Вы писали:
bnk>А к статье Q196026 это имеет отношение в части того, как предлагается решать проблему маршалинга — сделать окно и послать на него сообщение. Так вот, моя проблема будет, если послать не одно, а несколько сообщений. Во время того, как в VB отрабатывается первый ConnectinoPoint, почему-то диспатчатся остальные посланные сообщения, и начинает отрабатывать второй, который и игнорируется в VB.
Здравствуйте Ivan, Вы писали:
I>Про "incorrect" там ничего нет
Странно, но факт. В моем MSDN написано вот что:
Last reviewed: November 20, 1998
SYMPTOMS
Running a project in the IDE that displays a message box prevents events from occurring. However, when you compile and run the same project as an executable file (EXE), the events occur while the message box is displayed.
CAUSE
The behavior in the EXE is incorrect; events should not occur while a Message box is displayed (as with earlier versions of Microsoft Visual Basic).
На www.microsoft.com стоит дата публикации 'First Published: Dec 15 1997'
Может быть, они там редко обновляют статьи ?
Здравствуйте bnk, Вы писали:
bnk>На www.microsoft.com стоит дата публикации 'First Published: Dec 15 1997' bnk>Может быть, они там редко обновляют статьи ? :-
У меня MSDN — April 2002 и там то же самое, что и на www.microsoft.com
Я сталкивался с такой проблемой — VB "глотает" события, когда в обработчике вызывается MessageBox и, действительно, это происходит только в IDE, а при запуске как exe — не "глотает". Ну а "by design", так "by design". Советую не обращать внимания на эту странность IDE
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, Вы писали:
НБ>>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 ? Вы бы код привели ?
А вообще хорошая дискуссия!
: Есть какой-нибудь простой метод дождаться, пока первый Event отработает, и только потом бросать на клиента второй ? Или делать это надо как-то иначе ?
и снова делает Fire_MY()
, но, согласно тому же Q178078, это не есть хорошо, это есть БАГ у VB, ха-ха. 
(которая на сайте www.microsoft.com) написано вот что
Задача то стоит в том чтобы евенты обрабатывались асинхронно от работы потока, который читает из порта. А тут получается так: поток пишет в стрим, потом через механизм ConnectionPoint рожает евент, обработчик евента читает из стрима, А ПОТОК ТО ВИСИТ. Где асинхронность? 
