Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нем неправильно. Необходимо обновить браузер или попробовать использовать другой.
И ещё одна попытка.
Я думаю что нужно чётко определиться, какой будет алгоритм - Что делать если данные заняты (а они могут быть заняты т.к это общий объект), возвращать ошибку, или ожидать пока доступ освободиться?
Я думаю что нужно чётко определиться, какой будет алгоритм - Что делать если данные заняты (а они могут быть заняты т.к. это общий объект), возвращать ошибку, или ожидать пока доступ освободиться?
Отлично! Уже близко. Вот результат теста. Есть потери:
Сообщение автоматически объединено:
Всё больше сомневаюсь на счёт пункта 4, из моего списка идей - "возможность жизни отправленного сообщения" Пункты 2 и 5, могут вполне это заменить, да и в тестах, оно себя пока не проявляет.
В общем я пришёл к выводу, что нужно делать два режима передачи данных...
* Простой режим, где передаются только строковые значения, тогда можно без проблем организовать двустороннюю коммуникацию с возвратом ответа.
* Расширенный режим, где можно передавать другие типы данных, но с ограничением на возврат (без очереди и цикла отправки).
Хотелось бы увидеть пример того, где может понадобиться передача данных в виде других типов, не строковых.
свойство Data у объекта не уникально, из за этого и конфликт, а чтобы сделать его уникальным, нам нужна функция Assign для объектов, а этого как известно у нас в AutoIt'е нет
В этом плане, у меня были следующие мысли. В моём понимании интеракции, отправитель знает куда хочет отправить своё сообщение и делает это. Это как, в реальной жизни, вы отправляете письмо, но не факт, что вам ответят, и не факт, что сообщение будет прочитано. Нужно иметь сервис, который вам может сказать: "извините, этот получатель так и не появился". Я просто не столкнулся с конкретным программным примером такого взаимодействия, хотя, допускаю, что оно может быть, при определённых задачах. В моём понимании, эта идея, просто, как дополнительный сервис. А сервисы, особенно, когда они востребованы, я считаю, хорошим тоном.
Пока-что это всё мысли в отношении алгоритмов, а вернее домыслы, их я ещё буду менять.
Я нашёл как можно вернуть обратно от SendMessage указатель на структуру, и прочитать данные по нём.
Это упрощает возможность возвращать ответ и передавать как строки, так и массивы.
Я нашёл как можно вернуть обратно от SendMessage указатель на структуру, и прочитать данные по нём.
Это упрощает возможность возвращать ответ и передавать как строки, так и массивы.
v0.4
+ Добавлена поддержка x64.
+ Добавлены и изменены примеры (спасибо Vanguger за "Example #3").
* Теперь отправляемые данные могут содержать любой тип данных за исключением 3D (и выше) массивов, объектов, и структур.
* Более стабильный возврат данных от получателя.
* _AppInteract_Send теперь возвращает только стоковое значение (до 1024 байт) от получателя.
- Убран параметр $sRetAppName у функции _AppInteract_Send в связи с изменением метода возврата.
v0.5
* Убрано ограничение в 1024 байт на возвращаемое значение (спасибо Danyfirex).
* Теперь возвращаемые данные могут также содержать все типы данных кроме 3-ёх мерных (и выше) массивов, объектов и структур.
* Изменено устанавливаемое значение @error в функции _AppInteract_Send.
* Улучшена обработка ошибок.