Hi Flex0!

> Судя по твоим ответам ты даже не понял, что я спрашивал.

А ты ничего не спрашивал, ты УТВЕРЖДАЛ, однако убедительных доводов к своим
утверждениям не привёл. То что "в C# это делается ..." не есть убедительный
довод.

> Что ты там застыкуешь? Значение вернешь по _RetInt(...) И называешь это
> стыковкой.

_Evaluate(), _Execute() - вызывая любую функцию или метод объекта. Если не
веришь - возьми с Foxclub.ru решение FoxSubclass - перехват WM_ сообщений
для VFP8 и более ранних. То что это оформлено в виде COM-сервера сути не
меняет - механизм обратного вызова там именно через FOXAPI. Т.е. можно и
простую fll сделать.
Я не использую библиотеку от Mike Korneev (mkFox.fll), но насколько я
понимаю там тоже применена такая схема - и это 100% не COM.

Про синхронную работу с сокетами я опять таки ничего не понял. Ты не в курсе
что в фоксе можно использовать напрямую вызовы WS2_32.Dll функций? В
частности создать сокет, и проверять его через select() дабы не попасть в
состояние блокировки? Что можно использовать например OVERLAPPED (т.е.
асинхронный) IO с сокетами? Проверять статус сокета тоже можешь как угодно -
хоть по таймеру опрашивать, хоть WSAWaitFor* использовать, хоть заставить
его выдавать WM_ сообщение (WSAAsyncSelect) и его отлавливать из фокса (если
это оконное приложение конечно)...
При этом для ленивых программистов, не желающих вникать в тонкости работы с
сокетами в Win есть простой как грабли MS WinSock контрол - влёгкую
позволяющий нарисовать асинхронную сетевую прогу.
Вот меня скажем замучил спам, а имеющиеся в наличии (ну точнее найденные в
Инете) программы чистки почтового ящика через POP3 меня не устраивают - они
либо напрочь не дружат с русскими MIME-кодированными заголовками, либо
падают, либо не поддерживают POP3 коннекцию (обидно потратить 10 минут на
закачивание 100 заголовков и выбор неСПАМа из них, чтобы потом получить
"сокет был отсоединён"), не кэшируют принятые заголовки (т.е. порвалась
связь - качай заново все заголовки), не используют Pipelining (т.е. жёстко
работают по схеме - запрос-ответ а это выливается в 5-10 минут на получение
заголовков, и даже банальное удаление 100 писем занимает более 5 минут -
т.к. послали DELE запрос - ждём ответа) - тогда как все используемые мной
сервера нормально работают в поточном режиме - сокращая тем самым время
получения инфы в РАЗЫ.
Так это я к чему - нарисовал я себе простенькую утилитку используя MS
WinSock контрол - без проблем - всё замечательно работает - можно открыть
хоть 10 соединений с разными серверами и они все ОДНОВРЕМЕННО будут качать
данные - т.е. никаких блокировок или "синхронного вызова", никакой
"линейности" - и при этом я даже
НЕ ПЫТАЛСЯ создавать дополнительные потоки - т.е. вся работает в рамках
штатного рантайм-режима фокса - в одном потоке (не считая конечно, что фокс
реально несколько потоков для своих нужд создаёт - программа исполняется в
одном)...
Если доделаю эту прогу до "товарного вида" (чтоб не стыдно было за возможные
досадные ошибки, плюс "грязный" код), то выложу на foxclub... Чтобы потом
разные деятели не болтали что "это невозможно потому что я сказал" :)

> минимум #import... и как мини минимум знание маршалинга. Что ? Ты это
> пишешь так же как меня упрекнул в неполноценности, в легкую ?

Если я (т.е. некий абстрактный фокс-программист) могу написать самую обычную
COM компоненту (не используя FOXAPI), то вообще никаких проблем нет и быть
не может - пример такой компоненты выкладывал Михаил Дроздов - я считал что
в фоксе есть какая-то серьёзная проблема с подключением собственных
обработчиков событий при некоторых условиях, Михаил же показал что это
скорее недоработки тех компонент (или тех "мастеров создания COM
компонент"), что я использовал ранее. Однако про это мы ведь речи не ведём
:) Т.к. ясен пень что ты станешь громко возвещать что "это не фокс, это
неправильно" и т.д.

> Ну тогда мне вообще странно слышать заявления от ваих коллег о каких-то
> там сервисах (кроме Sergey Sh c его Веб - сервисами), так что не надо
> путать Х с пальцем.

К чему это сказано, я не понял. Если программа работает как WinNT Service,
под заданным аккаунтом (от LocalSystem до специально созданного доменного
аккаунта - без разницы), при logoff состоянии системы - т.е. в отсутствие
всяческих интерактивных пользователей - естественно под управлением SCM - то
что это такое? Или напрягает использование враппера srvany? Ну в принципе
можно в fll поместить требуемые системные функции - ServiceMain и HandlerEx
(точки входа, сам их функционал можно опять таки в фоксе оставить) дабы
можно было получить их адреса для стыковки с SCM... Только я не думаю что
это реально необходимо в 90% случаев...

> За что ж ты так отец и учитель малолеток против дядьки в пэкло прешь :)

Иногда почтенный возраст является минусом - твои годами сложившиеся
стереотипы просто не позволяют адекватно вести дискуссию. Упёртость ни к
чему хорошему не ведёт. Конструктива то никакого...

> Я на фоксе пишу так давно, что когда я начал ты видио еще не зачат был (
> без обид).

И что из этого? FPD не в счёт (т.к. это СОВЕРШЕННО другой язык, и о нём речи
тут не идёт), а VFP всего-то чуть более 10 лет... Кстати NET-у и того
меньше, а вот поди-ж ты как его превозносят тут некоторые :) Хотя наверняка
действительно масштабных разработок на нём и нету то...

> Просто хочу донести: нефиг тут пиликать и строить себя героями упершись в
> 1 среду программирования. Усек ?

А кто упёрся то? Давай объективно - я не говорил что NET плох, что на нём
нельзя чего-то сделать, что нужно всем срочно переходить на фокс... Это как
раз противоположная сторона всё время твердит, причём разумных
доводов/фактов не приводит - в основном одна болтовня... Я лишь говорю что
некоторые задачи делать на NET невыгодно (кстати говоря писать драйвера и
системные компоненты тоже, для этого Managed-код не годится - по крайней
мере пока не выйдёт новая ОС от MS). Что-то будет банально медленнее
работать, что-то потребует на порядок больше кода написать... На фоксе всё
аналогично - да, какие-то вещи делать сложнее и/или кода больше, или нужно
привлекать сторонние средства...

> А у меня они работают по средством VFP + COM VFP + FLL c передачей данных
> в фокс по событию портов через ранее связывание компонентов.

Ну и славненько :) Зачем же тогда было говорить что фокс надо на помойку и
срочно всё переделывать под C# или там ещё что-то :)

> И смотри, обсирать не надо, я слишком злой человек чтобы прощать обиды.

Извиняюсь, если это было так воспринято (я не собирался никого оскорблять),
однако если перечитать твои сообщения (особенно последние), то все мои слова
кажутся (мне) банальной констатацией печального факта... Ты же сам идёшь на
обострение.

Posted via ActualForum NNTP Server 1.2

Hi Flex0!

Раз уж Сергей удалил явную чушь из темы, то напишу пожалуй... Хотя вряд-ли
это что-то изменит.

> 1) _Evaluate(), _Execute() в потоках не работает;

Кто-то говорил про потоки? Организовать взаимодействие твоих служебных
потоков (если уж они нужны) с основным - который собственно и будет дёргать
методы фокса - в рамках той самой fll, на C который под это заточен - это
очень сложно или даже невозможно? Скажи это автору vfpmtapp.dll - компонента
создающая потоки и запускающая в них фоксовый код - думаю ты в курсе про
это.
И вообще при чём тут ИЗНАЧАЛЬНЫЙ предмет? Про параметры аналогично - никакой
связи с начальной темой.

> 3) WM_ - сообщений ( их кроме WM_ еще пару десятков тысяч):)

Это как это так? Я исключительно про оконные сообщения писал, а WM_ это
просто предложение MS по именованию данных констант.

> ну перехвати мне сообщение прихода символа в COM порт из фокса,
> асинхронно, через событийно - управляемый интерфейс.

Такого "оконного собщения" в винде нет - можно настроить Overlapped IO и
использовать Wait* для проверки состояния объекта event, или если тебя
интересует именно событие изменения состояния COM порта, то WaitCommEvent -
всё с теми-же самыми Overlapped структурами и "ожиданием" либо периодической
проверкой состояния. Иного применения в однопоточной среде фокса
сложно представить. Если же кому-то лень рисовать всю эту низкоуровневую
бодягу (а надо быть большим оригиналом, чтобы так извращаться если есть уже
готовые решения) то есть простой бесплатный контрол MSCOMM - он позволяет в
том числе и асинхронное функционирование системы - т.е. именно "событийно -
управляемый интерфейс". Естественно что у него есть свои особенности, и даже
недостатки. Но тогда можно поискать сторонние контролы.
Кстати говоря великий и ужасный NET в принципе не содержит класса для работы
с COM-портом. MS просто решило что это неактуально и всё :) Впрочем найти
готовую компоненту-враппер над соответствующим АПИ (если знать где искать
конечно) не составляет проблем. Если же ты станешь утверждать, что все
программисты на NET САМИ будут писать такие вещи, погружаясь в дебри Win32 -
то я, если и поверю в это, просто посочувствую несчастным адептам NET.
Помимо изучения всего многообразия NET классов, им ещё и WinAPI оказывается
нужен в таком объёме, а может и знания DDK :)

> 4) FoxSubclass - редокстный изврат, очень. И до сих пор глючный. Только
> ради того, чтобы им не пользоваться стоит выучить C++, хотя на уровне
> WIN32api.

Речь шла про то, что задача решаема в принципе - причём масой
разнообразнейших способов - и это не единственный.

> Понимаю. Не понял. Ну вот когда поймешь разницу между блокирующим сокетом
> и не блокирующем, когда посмотриь в строну струткры OVERLAPPED и увидишь,
> что фокс тут просто отдыхает ( хотя скажу тебе по секрету что с сокетами
> из фокса можно работать через =FREAD(), FWRITE() ), тогда потов с жалобами
> на AFAIK фокса будет меньше.

Я знаю разницу между блокирующим и неблокирующим сокетами, и про
WSAAsyncSelect я написал, и про select - который хоть и блокирующая
операция, но зато с таймаутом, и про OVERLAPPED IO... Я не вижу никаких
проблем при работе с OVERLAPPED струкутрами и с Event-ами. Да, запустить
фоксовый код в отдельном потоке напрямую нельзя - потому рекомендацию MSDN
типа "забейте на проблемы блокировок - ведь блокируется лишь один поток -
остальное всё работает" видимо не стоит применять в фоксе (если делать всё
чисто АПИ-ными средствами конечно).
Кроме того я уже писал
При этом для ленивых программистов, не желающих вникать в тонкости
работы с
сокетами в Win есть простой как грабли MS WinSock контрол - влёгкую
позволяющий нарисовать асинхронную сетевую прогу.
И пример приводил - ничего нигде не блокируется и не "висит". Несмотря на то
что Я ЛИЧНО ни строчки кода на C не написал, и даже АПИ нигде не
использовал.

> И я не использую. Хотя исходники 2000 года у меня имеються, в силу
> совместной работы с этим гуру в одной конторе. Только COM - в то время там
> не пахло. Вообще ! Максимум работа с множествами битовых масок (из самого
> крутого).

При чём тут COM? Речь шла о вызове фоксового кода из fll - ты же написал

>>> Что ты там застыкуешь? Значение вернешь по _RetInt(...) И называешь это
>>> стыковкой.

Это однако не так. Про что что-то там выглядит "некрасиво, убого и т.п."
прошу не напоминать - оно работает и точка. А о красоте лучше говорить
применительно к другим вещам, а не к какому-то там коду :)

> Герой, извратился. А ведь есть такие COM котрые и Systev services.

Есть много чего разного в этом мире, только не надо постоянно перепрыгивать
с одного на другое. Было конкретное высказывание

>>> 5) Ну напиши на VFP системный сервис допустим, не СOM exe а именно
>>> сервис,
>>> чтоб права имел и стратовал даже если сервер отлогинен под установленной
>>> учетной записью

И конкретный ответ.

> На счет Веба. - как бы вы сервисы на фоксе не писали ( в и мы тоже) но им
> еще нужно и рулить однако. а фоксе до Remoting слишком далеко.

Опять страшными словами пытаются подменить простую как грабли задачу. В чём
проблемы? Нельзя через DCOM вызвать метод и получить назад результат? Нет,
это не Remoting ну и что? Ну если моя машина ездит на солярке, то теперь
надо застрелится, т.к. "на бензине это круче, это современнее, вся
прогрессивное человечество во главе с MS ездит на бензине..." :)
Если что-то РАБОТАЕТ, то глупо говорить про то что оно "не по той
технологии" сделано, или "морально устарело".
Кстати для особых "ценителей" - у нас написали системный сервис на NET для
взаимодействия с простым, примитивным VFP dll сервером - с целью
"последующего Remoting" ибо COM+ им "не катит" потому что "вчерашний день"
(а на самом деле больше из-за кривой работы NET с COM Interop) - и даже
работает кое как, правда кривенько - в частности с многопоточностью там
полная ж... а заниматься отладкой как всегда недосуг. Главный вывод -
никаких преимуществ это не даёт. Абсолютно! А вот лишних глюков (т.к. всё-же
нету у нас целого штата как в MS для тестирования и отладки, а написать свой
собственный COM+, пускай и в самом примитивном виде - это не так то и
просто).
P.S. То что Remoting это не нечто "революционно новое, чего доселе не
существовало" (хотя там MS реклама говорит про ЛЮБУЮ технологию - будь то
даже банальное колесо), а банальное развитие RPC/DCOM/COM+ ты наверное
спорить не станешь? Схемки работы там кстати походу один в один копируются
из одного раздела MSDN в другой :) Называется - найди 10 отличий.

Posted via ActualForum NNTP Server 1.2

Hi Sergey!

Дык вроде же сразу было сказано - СЕГОДНЯ NET (даже бета версии 2.0) не
удовлетворяет всех потребностей типичного программиста СУБД в плане СКОРОСТИ
и УДОБСТВА разработки - клиентская схема работы с данными убога, кивать на
то что "только сервер" должен обрабатывать данные могут лишь упёртые
апологеты, которые просто иного НЕ МОГУТ сделать (а может быть даже просто
представить не могут)... Когда же сделают более удобные средства (совсем не
обязательно это должно быть дублирование VFP) именно по локальной обработке
данных - тогда и можно будет реально сказать что VFP устарел и утратил все
свои преимущества над другими средами. Тогда действительно можно будет НОВЫЕ
проекты на нём начинать делать. Переписывать же то что и так хорошо
работает - ну это нарушение первого принципа программирования и пустая
трата времени :)

Posted via ActualForum NNTP Server 1.2