Мне кажется, у тебя немножко каша в голове по поводу "синхронный/асинхронный". Если ты что-то вызываешь, и чтобы получить результат, тебе не надо ждать специально, а вызов СРАЗУ даст тебе результат, это -- синхронный вызов. Так работает SendMessageXXX. Если ты что-то вызываешь, а потом другим вызовом тебе придёт результат -- это Асинхронный вызов. Так организован PostMessage.

это всё понятно. Я имел ввиду не синхронный обмен сообщениями, а синхронный обмен данными - получил запрос, синхронно отправил ответ. В данный момент у меня это на пайпах реализовано, но вот решил на сообщениях сделать, посколку это показалось мне проще. И в тех ситуациях, когда "клиенту" не надо дожидаться ответа от "сервера", всё прекрасно работает

это всё понятно. Я имел ввиду не синхронный обмен сообщениями, а синхронный обмен данными - получил запрос, синхронно отправил ответ. В данный момент у меня это на пайпах реализовано, но вот решил на сообщениях сделать, посколку это показалось мне проще. И в тех ситуациях, когда "клиенту" не надо дожидаться ответа от "сервера", всё прекрасно работает

Ну, я тебе всё расписал выше. Тут проблема чисто техническая, что LRESULT только обратно сериализуется в другой процесс. Если хочешь совсем синхронный обмен, надо использовать DCOM и маршалинг данных туда-сюда.

Скажи лучше, каков результат обработки первого сообщения в сервере, процессе A ? Тип, размер данных.

тип - строка с жсоном, размер соотв. динамический. Передаётся в COPYDATASTRUCT

это всё понятно. Я имел ввиду не синхронный обмен сообщениями, а синхронный обмен данными - получил запрос, синхронно отправил ответ. В данный момент у меня это на пайпах реализовано, но вот решил на сообщениях сделать, посколку это показалось мне проще. И в тех ситуациях, когда "клиенту" не надо дожидаться ответа от "сервера", всё прекрасно работает

Какие данные пересылаются?

тип - строка с жсоном, размер соотв. динамический. Передаётся в COPYDATASTRUCT

В json что?

тип - строка с жсоном, размер соотв. динамический. Передаётся в COPYDATASTRUCT

Ну, вот, чтобы её передать обратно, надо маршалить в другой процесс. В его память. А никак. Так что невозможно это организовать строго синхронно, этот обмен

В json что?

Да всякая специфичсекая фигня {"Command":"подвинуть кнопку с именем Button1 на 2 пикселя вправо, что-то в этом роде"}

Да всякая специфичсекая фигня {"Command":"подвинуть кнопку с именем Button1 на 2 пикселя вправо, что-то в этом роде"}

О. Названия методов и аргументы. Лучше сразу в DCOM.

О. Названия методов и аргументы. Лучше сразу в DCOM.

строго говоря протокол - jsonrpc2

О. Названия методов и аргументы. Лучше сразу в DCOM.

спасибо, а то я не настоящий сварщик. гляну.

спасибо, а то я не настоящий сварщик. гляну.

Лучше сразу сюда пиши @supapro

строго говоря протокол - jsonrpc2

Можно ещё на TCP сокетах реализовать, но лучше сразу в DCOM.

Можно ещё на TCP сокетах реализовать, но лучше сразу в DCOM.

В шаблонах студии должны быть шаблоны сервера и клиента. На IDL языке нужно будет описать интерфейсы взаимодействия. У меня где-то был рабочий пример, но сходу не найду. Есть 2 вида серверов, которые выполняются в exe -- с библиотекой типов и без. С библиотекой типов будет меньше кода, но чуть сложнее писать, т.к. нужна реализация IDispatch.

В шаблонах студии должны быть шаблоны сервера и клиента. На IDL языке нужно будет описать интерфейсы взаимодействия. У меня где-то был рабочий пример, но сходу не найду. Есть 2 вида серверов, которые выполняются в exe -- с библиотекой типов и без. С библиотекой типов будет меньше кода, но чуть сложнее писать, т.к. нужна реализация IDispatch.

спасибо

Без библиотеки типов создаётся отдельная dll stub/proxy, исходные файлы для которой автоматически генерируются из idl описания.

Можно ещё на TCP сокетах реализовать, но лучше сразу в DCOM.

Я бы вот не связывался с этим говном. DCOM имею в виду.

Эта dll должна быть рядом с сервером и клиентом. Тогда заморачиваться с IDispatch не придется.

Я бы вот не связывался с этим говном. DCOM имею в виду.

Сколько раз ты его использовал? Так, чтоб работало?

Лучше сразу сюда пиши @supapro

Не надо такие вопросы в СУПУ. Там изучают язык С++, а не вопросы его применения.

Сколько раз ты его использовал? Так, чтоб работало?

Слава богам, НОЛЬ!

Не надо такие вопросы в СУПУ. Там изучают язык С++, а не вопросы его применения.

Ааааа. Не тому ответил

Слава богам, НОЛЬ!

(да нет же, не ноль :( )

Без библиотеки типов создаётся отдельная dll stub/proxy, исходные файлы для которой автоматически генерируются из idl описания.

Парень хочет JSONRPC. Ты его тянешь в DCOM... Ну ... блин... ФЕЕРИЧНО!

Лучше сразу сюда пиши @supapro

@bertolu4i ^ это сообщение не тебе

@bertolu4i ^ это сообщение не тебе

Да всё равно, кому оно

Парень хочет JSONRPC. Ты его тянешь в DCOM... Ну ... блин... ФЕЕРИЧНО!

Ну если хочет jsonrpc, то пусть идет в tcp/ip

Парень хочет JSONRPC. Ты его тянешь в DCOM... Ну ... блин... ФЕЕРИЧНО!

чес гря у меня на пайпах код и так довольно простой, но хотелось бы его ещё сильнее упростить и добавить гибкости. А не усложнить)

(да нет же, не ноль :( )

Так ноль или не ноль?

В шаблонах студии должны быть шаблоны сервера и клиента. На IDL языке нужно будет описать интерфейсы взаимодействия. У меня где-то был рабочий пример, но сходу не найду. Есть 2 вида серверов, которые выполняются в exe -- с библиотекой типов и без. С библиотекой типов будет меньше кода, но чуть сложнее писать, т.к. нужна реализация IDispatch.

Ну, ты тут всё перепутал, а так да. Есть автоматные сервера ( с Dispаеср) и неавтоматные. Автоматные можно юзать из VB.

Ну если хочет jsonrpc, то пусть идет в tcp/ip

Ну, ты же знаешь, почему умерли CORBA, DCOM и такое вот всё, и везде царствует этот долбаный идиотский WEB?

чес гря у меня на пайпах код и так довольно простой, но хотелось бы его ещё сильнее упростить и добавить гибкости. А не усложнить)

Ну и отсавайся на пайпах или лучше TCP

чес гря у меня на пайпах код и так довольно простой, но хотелось бы его ещё сильнее упростить и добавить гибкости. А не усложнить)

Гибкости добавит DCOM (уберет прослойку сериализации jsonrpc). Быстрое решение - переход от пайпов к tcp/ip взаимодействию. Или к именованным пайпам. Именованные пайпы будут ненадежны, если клиентов > 1

Ну, ты тут всё перепутал, а так да. Есть автоматные сервера ( с Dispаеср) и неавтоматные. Автоматные можно юзать из VB.

Где я что перепутал?

Гибкости добавит DCOM (уберет прослойку сериализации jsonrpc). Быстрое решение - переход от пайпов к tcp/ip взаимодействию. Или к именованным пайпам. Именованные пайпы будут ненадежны, если клиентов > 1

Так он потом ВЗВОЕТ всё это говно отлаживать!

Ребята , может подскажите , вообщем есть библиотека OpenCV (С++), в своем приложени вызываю функцию из этой либы, на пример приминение фильтра к изображению, пока происходит обрабтка , ни какой отзывчивости у приложения, кто нибудть может подсказать , как можно при думать, отображение прогресса? это только можно сделать добавлением кода в исходники OpenCV ?

Где я что перепутал?

ну typelibrary нужна не только лишь для IDispatch...

Так он потом ВЗВОЕТ всё это говно отлаживать!

Ты точно в DCOM разбираешься?

Ребята , может подскажите , вообщем есть библиотека OpenCV (С++), в своем приложени вызываю функцию из этой либы, на пример приминение фильтра к изображению, пока происходит обрабтка , ни какой отзывчивости у приложения, кто нибудть может подсказать , как можно при думать, отображение прогресса? это только можно сделать добавлением кода в исходники OpenCV ?

1) ЧТобы не лагало, в другом потоке обработку пускай 2) У фильтров нет прогресса

Ну и отсавайся на пайпах или лучше TCP

Что может быть лучше TCP/IP? TCP-over-UDP!

Ты точно в DCOM разбираешься?

НЕТ ! НЕ РАЗБИРАЮСЬ И НЕ ХОЧУ!

НЕТ ! НЕ РАЗБИРАЮСЬ И НЕ ХОЧУ!

Ну так зачем орёшь тогда?

Ну так зачем орёшь тогда?

он просто не совсем адекватен

Да, я неадекватен, когда людям в 21ов веке рекомендуют перейти на DCOM....

1) ЧТобы не лагало, в другом потоке обработку пускай 2) У фильтров нет прогресса

Спасибо

он просто не совсем адекватен

ты зря кстати, Илья жестковато, но обычно по делу)

ну typelibrary нужна не только лишь для IDispatch...

Автоматные сервера (и шаблоны в студии для них) реализуют IDispatch. Это главное отличие в этих шаьлонах, и это нужно учитывать. То, что такие сервера компилят .tlb файл автоматически и регистрируют его в системе - это вторично. А так я неавтоматный плюсовый COM сервер, например из Delphi могу использовать. То, что VB умеет общаться только с автоматными серверами - это его проблема. C#, кстати, тоже умеет обходиться без библиотеки типов.

Да, я неадекватен, когда людям в 21ов веке рекомендуют перейти на DCOM....

Вот мне тоже показалось, что это говно мамонта. Когда-то делал, сейчас даже вспоминать не хочу.

НЕ ну уж лушче Google Protobuf взять...

Но с учётом того, что у парня JSON...

Да, я неадекватен, когда людям в 21ов веке рекомендуют перейти на DCOM....

Следуя твоей логике, давайте выкинем физику, т.к. она очень старая. То, что в винде вечно устареть не может.

НЕ ну уж лушче Google Protobuf взять...

Да ладно, Ильюха, вся офисная автоматизация на COM-e

НЕ ну уж лушче Google Protobuf взять...

grpc!

Ну или его, да.

В общем, я всё.

Да ладно, Ильюха, вся офисная автоматизация на COM-e

+1

Я что читаю какие-то буквы, смотрю на DCOM и представляю себе, что я буду кросспрограммное средство типа COM использовать для собственных клиент-серверов...

Мне кажется, если чел имел опыт с всей этой машинерией, то это одно. Если это будет первый опыт, то может и не надо.

Да в винде чтобы .lnk файл создать, COM нужен!

Я что читаю какие-то буквы, смотрю на DCOM и представляю себе, что я буду кросспрограммное средство типа COM использовать для собственных клиент-серверов...

Никто не говорил о кроссплатформенности.

Никто не говорил о кроссплатформенности.

Я про то, что COM технология для работы с аппликухами которые вообще совсем не ваши, и там вечно п*ц какой-то

Нужны современные средства - добро пожаловать в Rest API, gRPC и прочие новые проекты

Я про то, что COM технология для работы с аппликухами которые вообще совсем не ваши, и там вечно п*ц какой-то

да, с этим согласен, с каждой новой версией офиса у нас парень, поддерживающий интеграцию с офисом, умывается кровавыми слезами.

Я про то, что COM технология для работы с аппликухами которые вообще совсем не ваши, и там вечно п*ц какой-то

Если понять, как COM работает, "п*ц" превращается в простой код. Просто его много на с++

Если понять, как COM работает, "п*ц" превращается в простой код. Просто его много на с++

А если вам надо интерфейс отозвать потому что связанная сущность сдохла а номинальная COM апиха вам такого не предлагает?

Если понять, как COM работает, "п*ц" превращается в простой код. Просто его много на с++

ну, ATL значительно упрощает мышиную возьню

ну, ATL значительно упрощает мышиную возьню

И содержит тонну define'ов :)

И содержит тонну define'ов :)

ну, что есть

А если вам надо интерфейс отозвать потому что связанная сущность сдохла а номинальная COM апиха вам такого не предлагает?

В чем сложность? Вернуть E_NOTIMPLEMENTED при запросе интерфейса сущности, например.

В чем сложность? Вернуть E_NOTIMPLEMENTED при запросе интерфейса сущности, например.

Вы не поняли. У вас у сущности забрали интерфейс и держат, а сущность с вашей стороны сдохла

ты зря кстати, Илья жестковато, но обычно по делу)

я любя ?

Вы не поняли. У вас у сущности забрали интерфейс и держат, а сущность с вашей стороны сдохла

Так нельзя в com. Если счётчик ссылок > 0, сущность должна жить. Или должен жить переходник, который будет проверять существование сдыхающей сущности и после этого на все вызовы методов возвращать исключения.

Если сдох СОМ сервер, то COM сам это будет делать на стороне клиента

Так нельзя в com. Если счётчик ссылок > 0, сущность должна жить. Или должен жить переходник, который будет проверять существование сдыхающей сущности и после этого на все вызовы методов возвращать исключения.

Вот про переходник это как раз то, что вы пишете

Вот про переходник это как раз то, что вы пишете

А что это за архитектура, где сущности сдыхают сами по себе?

А что это за архитектура, где сущности сдыхают сами по себе?

Диалог пользователем закрыт

Это даже не переходник, это костыль получается

Диалог пользователем закрыт

Диалоговое окно существует до вызова CloseHandle, даже после своего визуального закрытия

Диалоговое окно существует до вызова CloseHandle, даже после своего визуального закрытия

Если вы будете продлевать жизнь сущности "диалог" вы обвешиваетесь костылями на все события диалога

Если вы будете продлевать жизнь сущности "диалог" вы обвешиваетесь костылями на все события диалога

Например?

Диалоговое окно существует до вызова CloseHandle, даже после своего визуального закрытия

Представьте что у вас в диалоге остался незакрытый future, а он уже свой MessageLoop вырубил

Даже std::thread является полудохлой сущностью, если исполняемый поток завершился.

Представьте что у вас в диалоге остался незакрытый future, а он уже свой MessageLoop вырубил

MessageLoop в COM сервере работает всегда, пока работает COM сервер.

MessageLoop в COM сервере работает всегда, пока работает COM сервер.

MessageLoop в менюшке, например, свой, особенный и очень специфический

И в одном потоке. Создавать его в другом потоке только приводит к путанице, но возможно. Сама сушность "диалог" (handle) может жить и без message loop