События компонента и Application.ProcessMessages

← →
Германн © (2007-02-26 02:53) [0]

Опять я задаю очередной "дурацкий вопрос". Модераторы его переместят в нужную конференцию, надеюсь.
Суть вопроса в том, что мне нужно внутри функции вызвать метод некоего компонента, дождаться возникновения некоего события, которое будет обработано "обработчиком данного компонента для этого события" и завершить функцию с возвращением результата и var-переменных по результатам работы вышеописанного обработчика? Всегда ли мне поможет использование Application.ProcessMessages?

← →
Юрий Зотов © (2007-02-26 10:17) [1]

Application.ProcessMessages просто выбирает из очереди сообщения и обрабатывает их. Больше этот метод ничего не делает, так что поможет он, или нет - это зависит от логики построения кода.

← →
Ega23 © (2007-02-26 10:18) [2]

Ну так и вызови, в чём проблема? Поток-то всё равно один, пока метод не отработает - дальше не прыгнешь...
А событие - это совсем не обязательно message

← →
Kolan © (2007-02-26 12:57) [3]

> Всегда ли мне поможет использование Application.ProcessMessages

По идеи Application.ProcessMessages должно быть внутри "некоего компонента". Получится так сделать?

← →
Рамиль © (2007-02-26 13:01) [4]

> дождаться возникновения некоего события

Этого ProcessMessages не сделает.

← →
Германн © (2007-02-26 13:33) [5]

Да. Дурацкое это дело - воду решетом вычерпывать :) Придется мне тогда переходить на столь мною нелюбимую синхронную работу с компортом. :(

← →
Kolan © (2007-02-26 14:50) [6]

> Придется мне тогда переходить на столь мною нелюбимую синхронную
> работу с компортом.

Зачем? Надо то тебе чего? Может поможем..
Тебе дождаться данных надо, а если нет то сообщить о таймауте?
- Елси так то есть мариванты..

← →
Германн © (2007-02-26 15:46) [7]

> Зачем? Надо то тебе чего? Может поможем..
> Тебе дождаться данных надо, а если нет то сообщить о таймауте?
>
> - Елси так то есть мариванты..

Да знаю я все эти варианты. Вопрос о компоненте был лишь для того, чтобы уменьшить количество рутинной писанины для задачи, имхо обреченной быть выброшенной в корзину.

← →
jack128 © (2007-02-26 18:09) [8]

Германн © (26.02.07 13:33) [5]
Придется мне тогда переходить на столь мною нелюбимую синхронную работу с компортом. :(

А чего ты хочешь дождаться то?? Пока данные не придут с порта?? Тогда Application.ProcessMessages те ну никаким боком не поможет.

← →
Amoeba © (2007-02-26 21:40) [9]

Опиши задачу конкретно. Пока что вся информация на уровне общих мест.

← →
Kolan © (2007-02-26 21:51) [10]

Имхо там где есть работа с портом ожидание данных находится так глубоко, что Application.ProcessMessages там делать нечего.

У меня выходит так:

1. Компонент для записи и чтения данных через КОМ порт
2. Уровень на котором реализуется запрос-ответ. Тут же делаю ожидание если не пришло ниче  тайм аут.
3. Уровень на котором апередаются и принимаются уже не байты а объекты-пакет конкретного формата.
4. Уровень протокола. Тут Все ф-ции устр-ва. Например: «Инициализация», «Запись коэффициента».
5. Уровнь системы в целом. Тут ф-ции системы. Например «Начать измерение». Этот уровень пользуется предыдущем.
5. А вот только тут конкретные функции можно подцепить к кнопкам на форме&#133

← →
Ш-К (2007-02-26 23:33) [11]

Вообще-то надо уходить от линейности в таких случаях. Самописные WaitFor-ы не есть гуд.

← →
Германн © (2007-02-27 01:12) [12]

Спасибо всем принявшим участие.
Короче мой сабж был бредовой попыткой обеспечить как-либо асинхронную работу с ком-портом в бредовой задаче. Я уже осознал практически полную невозможность этого.
Для особо любопытных озвучу задачу. Некая контора захотела использовать наши устройства в своей системе. Устройства подключаются к компьютеру через Ком-порт. Мы не против передачи своих протоколов связи и систем команд другим организациям, но эти люди не захотели сами в своей(их) программе работать с Ком-портом. Вместо этого меня попросили написать DLL, которая и реализует эту работу с Ком-портом. Например в этой DLL должна быть функция:
bool GetStatus(unsigned int adress, status_des * status) – доложить состояние. adress – адрес контроллера на линии. status – указатель на структуру, в которую надо записать данные о состоянии контроллера. Возвращаемое значение говорит об успехе операции.
То бишь выполняя данную функцию DLL должна сформировать посылку в устройство (некий набор байт), дождаться ответа устройства, принять ответ, декодировать ответ, записать данные в status_des и возвратиться из функции.
И как я в подобном случае смогу обеспечить "неподвисание" интерфейса вызывающей программы?

← →
Джо © (2007-02-27 03:22) [13]

Передавай в эту функцию адрес колбека, коий и будет вызываться по получении приема и дешифровки данных. А чтение/запись выполнять асинхронно.
Если я вообще понял, о чем речь :-)

← →
GrayFace © (2007-02-27 10:35) [14]

Попробуй объяснить это заказчику.

← →
Германн © (2007-02-27 10:55) [15]

> Джо © (27.02.07 03:22) [13]
>
> Передавай в эту функцию адрес колбека, коий и будет вызываться
> по получении приема и дешифровки данных. А чтение/запись
> выполнять асинхронно.
> Если я вообще понял, о чем речь :-)
>

Ты правильно понял. Но это уж пусть заказчик думает. Помучится и авось научится. :)

> Германн © (27.02.07 01:12) [12]

> То бишь выполняя данную функцию DLL должна сформировать
> посылку в устройство (некий набор байт), дождаться ответа
> устройства, принять ответ, декодировать ответ, записать
> данные в status_des и возвратиться из функции.

Возможно, что я тоже неправильно понял замысел, но здесь просится
не функция, возвращающая результат (которая не может быть
выполнена основным потоком асинхронно), а подписка на событие
(если я меня не попутал склероз).
IMHO, в дельфийских примерах было нечто подобное, в разделе COM+.

Также возможно, что требования могут удовлетворены и [13].

Все же приятно, когда удается ответить без снижения, IMHO,
уровня таинственности.

--
Regards, LVT.

2 Leonid Troyanovsky © (27.02.07 18:37) [16]

> Возможно, что я тоже неправильно понял замысел, но здесь
> просится
> не функция, возвращающая результат (которая не может быть
> выполнена основным потоком асинхронно), а подписка на событие
> (если я меня не попутал склероз).
> IMHO, в дельфийских примерах было нечто подобное, в разделе
> COM+.
>
> Также возможно, что требования могут удовлетворены и [13].
>
>
> Все же приятно, когда удается ответить без снижения, IMHO,
>
> уровня таинственности.

Да нет тут никакой таинственности. Но есть данное заказчиком ТЗ. В нем описаны функции, которые должна содержать DLL. Пример функции приведенный в [12] не придуман мною, а скопирован из ТЗ. И я не могу в нем ничего менять :(

>обеспечить "неподвисание" интерфейса вызывающей программы
MsgWaitForMultipleObjects(Ex) может помочь

Германн © (27.02.07 1:12) [12]
И как я в подобном случае смогу обеспечить "неподвисание" интерфейса вызывающей программы?
Технически можно, но лично я бы за циклы выборки сообщений в DLL не только руки, но кое что другое бы отрорвал.

Всё уже придумано за нас.

например, такой набор функций:

//Блокирующее синхронное чтение
GetMyData(var data: TMyData): Integer;

//Стартует асинхронное чтение
BeginGetMyData(var data: TMyData): TGetHandle;

//Завершает/дожидается/отменяет асинхронную операцию
//возвращает статус
EndGetMyData(handle: TGetHandle; timeout: DWORD; cancel: BOOL): Integer;

а о "неблокируемости интерфейса", равно как и о наличии такового вообще, пусть болит голова у клиента.

← →
имя (2007-03-01 08:44) [21]

Удалено модератором

← →
имя (2007-03-01 21:35) [22]

Удалено модератором

События компонента и Application.ProcessMessages Найти похожие ветки