| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
События компонента и Application.ProcessMessages [D6]
Германн © (2007-02-26 02:53:00)Опять я задаю очередной "дурацкий вопрос". Модераторы его переместят в нужную конференцию, надеюсь.
Суть вопроса в том, что мне нужно внутри функции вызвать метод некоего компонента, дождаться возникновения некоего события, которое будет обработано "обработчиком данного компонента для этого события" и завершить функцию с возвращением результата и var-переменных по результатам работы вышеописанного обработчика? Всегда ли мне поможет использование Application.ProcessMessages?
(2007-03-01 21:35:00) [1]Удалено модератором
(2007-03-01 08:44:00) [2]Удалено модератором
DiamondShark (2007-02-28 13:39:00) [3]Всё уже придумано за нас.
например, такой набор функций:
//Блокирующее синхронное чтение
GetMyData(var data: TMyData): Integer;
//Стартует асинхронное чтение
BeginGetMyData(var data: TMyData): TGetHandle;
//Завершает/дожидается/отменяет асинхронную операцию
//возвращает статус
EndGetMyData(handle: TGetHandle; timeout: DWORD; cancel: BOOL): Integer;
а о "неблокируемости интерфейса", равно как и о наличии такового вообще, пусть болит голова у клиента.
jack128 (2007-02-28 10:48:00) [4]Германн © (27.02.07 1:12) [12]
И как я в подобном случае смогу обеспечить "неподвисание" интерфейса вызывающей программы?
Технически можно, но лично я бы за циклы выборки сообщений в DLL не только руки, но кое что другое бы отрорвал.
ALS (2007-02-27 19:44:00) [5]>обеспечить "неподвисание" интерфейса вызывающей программы
MsgWaitForMultipleObjects(Ex) может помочь
Германн (2007-02-27 18:51:00) [6]2 Leonid Troyanovsky © (27.02.07 18:37) [16]
> Возможно, что я тоже неправильно понял замысел, но здесь
> просится
> не функция, возвращающая результат (которая не может быть
> выполнена основным потоком асинхронно), а подписка на событие
> (если я меня не попутал склероз).
> IMHO, в дельфийских примерах было нечто подобное, в разделе
> COM+.
>
> Также возможно, что требования могут удовлетворены и [13].
>
>
> Все же приятно, когда удается ответить без снижения, IMHO,
>
> уровня таинственности.
Да нет тут никакой таинственности. Но есть данное заказчиком ТЗ. В нем описаны функции, которые должна содержать DLL. Пример функции приведенный в [12] не придуман мною, а скопирован из ТЗ. И я не могу в нем ничего менять :(
Leonid Troyanovsky (2007-02-27 18:37:00) [7]
> Германн © (27.02.07 01:12) [12]
> То бишь выполняя данную функцию DLL должна сформировать
> посылку в устройство (некий набор байт), дождаться ответа
> устройства, принять ответ, декодировать ответ, записать
> данные в status_des и возвратиться из функции.
Возможно, что я тоже неправильно понял замысел, но здесь просится
не функция, возвращающая результат (которая не может быть
выполнена основным потоком асинхронно), а подписка на событие
(если я меня не попутал склероз).
IMHO, в дельфийских примерах было нечто подобное, в разделе COM+.
Также возможно, что требования могут удовлетворены и [13].
Все же приятно, когда удается ответить без снижения, IMHO,
уровня таинственности.
--
Regards, LVT.
Германн (2007-02-27 10:55:00) [8]
> Джо © (27.02.07 03:22) [13]
>
> Передавай в эту функцию адрес колбека, коий и будет вызываться
> по получении приема и дешифровки данных. А чтение/запись
> выполнять асинхронно.
> Если я вообще понял, о чем речь :-)
>
Ты правильно понял. Но это уж пусть заказчик думает. Помучится и авось научится. :)
GrayFace (2007-02-27 10:35:00) [9]Попробуй объяснить это заказчику.
Джо (2007-02-27 03:22:00) [10]Передавай в эту функцию адрес колбека, коий и будет вызываться по получении приема и дешифровки данных. А чтение/запись выполнять асинхронно.
Если я вообще понял, о чем речь :-)
Германн (2007-02-27 01:12:00) [11]Спасибо всем принявшим участие.
Короче мой сабж был бредовой попыткой обеспечить как-либо асинхронную работу с ком-портом в бредовой задаче. Я уже осознал практически полную невозможность этого.
Для особо любопытных озвучу задачу. Некая контора захотела использовать наши устройства в своей системе. Устройства подключаются к компьютеру через Ком-порт. Мы не против передачи своих протоколов связи и систем команд другим организациям, но эти люди не захотели сами в своей(их) программе работать с Ком-портом. Вместо этого меня попросили написать DLL, которая и реализует эту работу с Ком-портом. Например в этой DLL должна быть функция:
bool GetStatus(unsigned int adress, status_des * status) – доложить состояние.
adress – адрес контроллера на линии.
status – указатель на структуру, в которую надо записать данные о состоянии контроллера.
Возвращаемое значение говорит об успехе операции.
То бишь выполняя данную функцию DLL должна сформировать посылку в устройство (некий набор байт), дождаться ответа устройства, принять ответ, декодировать ответ, записать данные в status_des и возвратиться из функции.
И как я в подобном случае смогу обеспечить "неподвисание" интерфейса вызывающей программы?
Ш-К (2007-02-26 23:33:00) [12]Вообще-то надо уходить от линейности в таких случаях. Самописные WaitFor-ы не есть гуд.
Kolan (2007-02-26 21:51:00) [13]Имхо там где есть работа с портом ожидание данных находится так глубоко, что Application.ProcessMessages там делать нечего.
У меня выходит так:
1. Компонент для записи и чтения данных через КОМ порт
2. Уровень на котором реализуется запрос-ответ. Тут же делаю ожидание если не пришло ниче — тайм аут.
3. Уровень на котором апередаются и принимаются уже не байты а объекты-пакет конкретного формата.
4. Уровень протокола. Тут Все ф-ции устр-ва. Например: «Инициализация», «Запись коэффициента».
5. Уровнь системы в целом. Тут ф-ции системы. Например «Начать измерение». Этот уровень пользуется предыдущем.
5. А вот только тут конкретные функции можно подцепить к кнопкам на форме…
Amoeba (2007-02-26 21:40:00) [14]Опиши задачу конкретно. Пока что вся информация на уровне общих мест.
jack128 (2007-02-26 18:09:00) [15]Германн © (26.02.07 13:33) [5]
Придется мне тогда переходить на столь мною нелюбимую синхронную работу с компортом. :(
А чего ты хочешь дождаться то?? Пока данные не придут с порта?? Тогда Application.ProcessMessages те ну никаким боком не поможет.
Германн (2007-02-26 15:46:00) [16]
> Зачем? Надо то тебе чего? Может поможем..
> Тебе дождаться данных надо, а если нет то сообщить о таймауте?
>
> - Елси так то есть мариванты..
Да знаю я все эти варианты. Вопрос о компоненте был лишь для того, чтобы уменьшить количество рутинной писанины для задачи, имхо обреченной быть выброшенной в корзину.
Kolan (2007-02-26 14:50:00) [17]> Придется мне тогда переходить на столь мною нелюбимую синхронную
> работу с компортом.
Зачем? Надо то тебе чего? Может поможем..
Тебе дождаться данных надо, а если нет то сообщить о таймауте?
- Елси так то есть мариванты..
Германн (2007-02-26 13:33:00) [18]Да. Дурацкое это дело - воду решетом вычерпывать :) Придется мне тогда переходить на столь мною нелюбимую синхронную работу с компортом. :(
Рамиль (2007-02-26 13:01:00) [19]
> дождаться возникновения некоего события
Этого ProcessMessages не сделает.
Kolan (2007-02-26 12:57:00) [20]> Всегда ли мне поможет использование Application.ProcessMessages
По идеи Application.ProcessMessages должно быть внутри "некоего компонента". Получится так сделать?
| |
Страницы: 