Добрый день! Есть клиент-серверное решение использующее сокеты Winsock.OCX
Нужно на клиенте перейти на API-шный вариант. Всякие socket()-connect()-sendData() победил.
Остался вопрос по приему данных от сервера.
Наверное можно по колхозному: запустить таймер и каждые 500 мс проверять буфер приема.
Но хочется сделать грамотно.
Создаю событие WSACreateEvent(),WSAEventSelect(), уведомление о событии WSAWaitForMultipleEvents()
и обработчик WSAEnumNetworkEvents().
Как вызвать метод/процедуру на VFP для обработки данных от сервера при наступлении события от WinApi ?

я как то с этого начинал. сейчас не помню ничего

Написать на си fll где всю низкоуровневую работу и реализовать. Или на дотнете сборку с COM интерфейсом (regasm и иже с ним).

А на самом деле нужны голые сокеты? С железками какими-то работа, что ли?

Может у вендора есть уже готовые компоненты высокоуровневого обмена - хоть COM, хоть дотнетовские, которые в приницпе можно либо обернуть для вызова как COM, либо через wwDotNetBridge прикрутить (тоже та ещё задачка, но вполне решаемая).

Артём
я как то с этого начинал. сейчас не помню ничего

Пример, к сожалению, на WinSock.OCX - так я умею.
Должен же быть какой-нибудь BINDEVENT(),EVENTHANDLER(),RAISEEVENT() ?

А не вломы просто запустить HTMLHTTP-запрос(ы), и опрашивать ответы в режиме поллинга?

С чего ты взял что речь про HTTP протокол? Маловероятно что кто-то будет его на сокетах реализовывать.

Пожалуйста, если можете - объясните :
1)как реализовать ожидание приема данных на сокете
с использованием (например) WSACreateEvent(),WSAEventSelect(), WSAWaitForMultipleEvents(),WSAEnumNetworkEvents() и прочей API
так, чтобы клиентский модуль мог заниматься "своим делом" и не крутил бессмысленно таймер.
2)возможно ли это событие привязать к обработчику (метод формы) с помощью
BINDEVENT(),EVENTHANDLER(),RAISEEVENT().

###

Проблема решена. Может "на что сгодится":
После connect():
WSAAsyncSelect(hSocket,HWndf,WM_SOCKET_EVENT,FD_READ) && со своим уникальным WM_SOCKET_EVENT
В Init() основной формы:
BINDEVENT(hWnd,WM_SOCKET_EVENT, this, "my_receive")
Метод my_receive основной формы:
LPARAMETERS iKodEvent,iWM_SOCKET_EVENT,ihSocket,iFlag
...
nRecv = recv(hSocket, @cRecv, READ_SIZE, nFlags) && recv() из WinAPI
return



Исправлено 1 раз(а). Последнее : Hushper, 23.11.20 16:59

Hushper
Проблема решена.

Igor Korolyov
С чего ты взял что речь про HTTP протокол? Маловероятно что кто-то будет его на сокетах реализовывать.

Я с ними не умею. У них (сокетов) есть "асинхронный" режим ? т.е режим когда "спрошу об окончании приема , когда появится возможность" ?

Есть. В винсок активиксе - через его event-ы, в АПИшных сокетах - ну вот через эти все вышеописанные WSACreateEvent и т.д.
Проблема в том что фокс по большей части однопоточен (и вынести обработку чего-либо в отдельный поток достаточно сложно), и запросто можно "терять" event-ы - особенно в такой низкоуровневой работе - буфер там не резиновый, и запустив какой-нить SQL-запросец пока "ждём ответа от сокета", можно запросто этот ответ и прозевать, т.к. дело до обработки события может дойти этак через секунд 20, а то и больше

Можно запустить 10 одинаковых EXE-шников фоксовых (с опросником одного сокета, и сбором инфы от него в буфер)), а уже из них собирать инфу главным EXE-шником, который может и часовые SQL-запросы делает...

Один сокет они не смогут опрашивать, конечно. А так то да - это один из вариантов реализации отсутствующей в фоксе многопоточности - через многопроцессность

> Один сокет они не смогут опрашивать, конечно
Блин! Каждый EXE опрашивает один, конечно! Или один дополнительный EXE опрашивает все, но больше ничем не занимается, ...блин!