ОреЛ писал(а):Вопрос к Максиму:
Будет ли внесены когда-либо (желательно в ближайших версиях) для серверных плагинов прием событий Публикация/Редактирование/Удаление объявления/комментария?
На данный момент возможно лишь получение данных о разделах ДО, обо всех объявлений раздела, но нет приема события Публикации или Редактирования или Удаления объявлений или комментария к нему.
P.S.: приношу извинения за повтор вопроса.
Невнимательно прочитал. Прием таких событий реализуем.
dark писал(а):Плагин делает все что надо, но ошибка остается.
Опишите пожалуйста подробнее что именно делает плагин успешно и где именно сохранилась ошибка.
Работа в одном потоке - это наиболее простой, понятный и стабильный для разработчика плагина вариант. Он позволяет без проблем синхронно обмениваться данными между плагином и программой. Для многопоточности необходимо защищать данные от параллельной работы с ними. Программа и плагины образуют собой единое приложение. Если нет понимания всех аспектов многопоточности - ни в коем случае нельзя с ней связываться. Ошибки будут неминуемо, причем труднодиагностируемые.
Я лично, помучившись с разбиением на потоки, забил на данную идею. Основная часть ошибок у меня была в момент попытки инициировать событие в чате при помощи соответствующей функции. Мне пока не совсем ясны принципы, по которым работают DLL-плагины, и как грамотно разбить свою часть кода на потоки, но коль разработчики этого не предусмотрели, придётся как-то ухищряться, пока для себя решил вернуться к ботам, это самое простое. Получается работать будут 2 независимые (по процессорному времени) программы, обмениваться через ip-протокол и бог с ним.
Как уже говорилось выше чтобы подружить плагин с потоками надо использовать функции typeCommFortProcess и typeCommFortGetData в основном потоке.
У объекта TThread есть метод Synchronize который позволяет запустить переданную процедуру в основном потоке.
Так как typeCommFortProcess не возвращает никаких данных то использование вместе с Synchronize не должно вызывать проблем.
Тяжелее с typeCommFortGetData, для получения результата надо:
1) вызвать функцию через Synchronize.
2) приостановить поток дождаться получения результата (уйти в бесконечный цикл пока не установится определенный флаг)
3) в основном потоке после получения результата от typeCommFortGetData обязательно скопировать буфер с результатом в свою память.
Во первых мы не знаем когда будет очищен этот буфер, во вторых для работы через критические секции лучше все же использовать свою память.
4) в потоке войти в критическую секцию и обработать результат.
Ну, а в идеале чат в следующих версиях сам должен определять в основном ли потоке вызываются typeCommFortProcess и typeCommFortGetData и действовать соответствующим образом.
Такой вопрос: Вот допустим плагин подал запрос на активацию, когда активацию принимают какое нибудь событие происходит?
Чтобы плагин знал когда учетку активировали и действовал дальше. Знаю про способ подавать заявку каждые N секунд и смотреть ответ по ID ответа 1090. Но все же есть более красивое решение?
Забросил, всем спасибо, исходники раздаю кому надо https://github.com/ZigZagkms
Как обычный пользователь, так и виртуальный могут проверить состояние активации только попыткой авторизации. Предполагается, что ручная обработка заявки на активацию может занять значительное время и не стоит клиента все это время нервировать окном "Пожалуйста, подождите...". Более предпочтительный вариант - "Пожалуйста, зайдите позже". Плагин унаследовал этот принцип.
Пароль учетной записи
ID: 1060
Блок данных (исходящий): текст(имя пользователя)
Блок данных (входящий): текст(32 символьный MD5 хэш-код пароля)
Если пользователь не зарегистрирован, то вместо MD5 хэш-кода во входящий блок данных будет записана пустая строка.
не получается, т.к. еще не авторизован.
Так как же узнать пароль на стадии авторизации? Чтобы можно было отклонять авторизацию в зависимости от внешних совпадений логин\пароль
Забросил, всем спасибо, исходники раздаю кому надо https://github.com/ZigZagkms
Пароль учетной записи
ID: 1060
Блок данных (исходящий): текст(имя пользователя)
Блок данных (входящий): текст(32 символьный MD5 хэш-код пароля)
Если пользователь не зарегистрирован, то вместо MD5 хэш-кода во входящий блок данных будет записана пустая строка.
не получается, т.к. еще не авторизован.
Так как же узнать пароль на стадии авторизации? Чтобы можно было отклонять авторизацию в зависимости от внешних совпадений логин\пароль
