Мда - чета ТС пошел явно не туда
Сделал бы ActiveX - и вот тебе события какие нада, к примеру


Ну или как там сделаете регистрацию своего ActiveX в том числе и с предпросмотрами или че там понапихано, и не надо никакого FoxAPI и сам ActiveX будет универсален для всех языков

ssa
Вот, уже чуствуется зацикленность. Без FoxAPI прямо никуда?

piva
Ну или как там сделаете регистрацию своего ActiveX в том числе и с предпросмотрами или че там понапихано, и не надо никакого FoxAPI и сам ActiveX будет универсален для всех языков

Так, стоп, стоп, стоп!

В начале обсуждения я об этом говорил, но, возможно, что-то подзабылось, на что-то не обратили внимание и т.д, может и плохо сформулировал, итак:

Речь идет только о Native Win32-реализации! Данная посылка безусловна. Реализация через FoxAPI является обязательным условием поставленной задачи.

Универсальная COM-реализация FastReport существует, ветка называется "FastReport Studio". При желании, можно покупать и пользоваться . На предварительном анализе проекта я довольно много общался с реальными буржуйскими покупателями "FastReport Studio", которые используют его с FoxPro, выясняя заинтересованность в Native-реализации (это к вопросу что-кому нужно). Итак:

- Универсальная COM-реализация, в силу, собственно, своей универсальности, обладает целым рядом недостатков, что приводит к появлению Native-реализаций.
- Native-реализация не универсальна, в том смысле, что затачивается под конкретный язык, но при этом обязана обеспечить полную интеграцию с этим языком на самом низком уровне и, по возможности, с прямым доступом "ко всему в обе стороны".

Обсуждаемый в этом топике проект - это Native-реализация. Какое-либо использование COM я не исключаю, но только в технических целях, и это будет "скрыто" от пользователя в плане использования. FastReport, который используется для Native не является COM-библиотекой.

P.S. Ну и поверьте, я в курсе современных технологий И подозревать, что COM-слона я мог бы и не заметить, не очень серьезно

В таком случае не лучше ли начать с описания своего детища "на самом низком уровне"? Чем оно на этом уровне себя представляет, чего наружу выставляет, чего от окружения требует?

Вообще-то фоксапи вполне себе можно применять и для COM-компонент - просто сама технология COM даёт инструменты описания "событийного интерфейса" и фокс может это использовать, "реализуя" соответствующий интерфейс - как "встроенным в форму" образом (для активиксов, например тот же пресловутый winsock контрол или mscomm, или если "визуальный" брать то MS DateTimePicker - просто видим у объекта метод-обработчик и там пишем свой код), так и "внешним" способом - для чего в старых версиях пользовался хелпер vfpcom, а в новых появилась конструкция DEFINE CLASS ... IMPLEMENTS и функция EVENTHANDLER().
Как мне кажется, это есть наиболее правильный способ цепляния своих "обработчиков событий внешнего компонента". Конечно же можно и через чистое АПИ примерно так как ты описывал, но как-то это криво и несолидно.
Вообще из всех вопросов интеграции для фокса, как мне кажется, единственный который оправдывает "родное средство" - это получение данных из источников (курсоров) - чтобы не парится с адо или ещё чем. Всё прочее вполне эффективно делается "универсальным" образом через COM.

ssa
В таком случае не лучше ли начать с описания своего детища "на самом низком уровне"? Чем оно на этом уровне себя представляет, чего наружу выставляет, чего от окружения требует?

Если под детищем подразумевается FastReport, то напомню, что это не мое детище, а компании Fast Report Inc Я - "внешний" OEM-партнер этой компании. Если же говорить о том, что получается когда я компилю FastReport и свой код вместе, то будем исходить из того, что это dll, и наружу она может "выставить" все, что нам (Фоксу) захочется. Как говорится, любой каприз Собственно, для этого я свой код и пишу

Единственное, полностью Fast в COM я заворачивать не буду, так как это уже давно сделано самим Fast Report Inc.

Igor Korolyov
Вообще-то фоксапи вполне себе можно применять и для COM-компонент - просто сама технология COM даёт инструменты описания "событийного интерфейса" и фокс может это использовать, "реализуя" соответствующий интерфейс - как "встроенным в форму" образом (для активиксов, например тот же пресловутый winsock контрол или mscomm, или если "визуальный" брать то MS DateTimePicker - просто видим у объекта метод-обработчик и там пишем свой код), так и "внешним" способом - для чего в старых версиях пользовался хелпер vfpcom, а в новых появилась конструкция DEFINE CLASS ... IMPLEMENTS и функция EVENTHANDLER().
Как мне кажется, это есть наиболее правильный способ цепляния своих "обработчиков событий внешнего компонента". Конечно же можно и через чистое АПИ примерно так как ты описывал, но как-то это криво и несолидно.

Ну, несколько кривовато это оказалось в виду отсутствия прямых API функций вызова функций и методов. Честно говоря, вчера это для меня стало серьезной неожиданностью (в других Dbase-API эти функции есть). А так все складывалось бы достаточно гармонично

Таким образом, пока видятся два пути, которые, по-моему, мне надо еще поисследовать, возможно сделать некоторые тесты, и т.д.

1. Попытаться "дожать" чистый API, возможно, найти какой-либо workaround вокруг обнаружившейся проблемы.

2. Использовать COM для диспетчеризации событий.

Спасибо за конструктивные размышления. Если появятся идеи о третьем пути, буду премного благодарен

Igor Korolyov
Вообще из всех вопросов интеграции для фокса, как мне кажется, единственный который оправдывает "родное средство" - это получение данных из источников (курсоров) - чтобы не парится с адо или ещё чем. Всё прочее вполне эффективно делается "универсальным" образом через COM.

Да, конечно, прямой доступ к данным и языку - это основная причина появления Native-ов.

Эти самые _Execute и _Evaluate и есть прямой и документированный способ вызова фоксовых процедур из внешнего модуля. Ну такова организация фокса, что он не держит в памяти код - сейчас asd() вызывает один код, а через 5 минут запросто может вызывать совсем другой код из другого модуля (конечно если разработчик так захочет). Единственное что неизменно - это имя, и с ним нет особых проблем. По параметрам - фокс не типизирован ни на каплю, потому ему вообще по барабану сколько и чего ты передаёшь при вызове функции (ну предел числа параметров есть, но "заказать" чтоб их было скажем ровно 3 и все при том числа - невозможно никак)...

Igor Korolyov
Эти самые _Execute и _Evaluate и есть прямой и документированный способ вызова фоксовых процедур из внешнего модуля. Ну такова организация фокса, что он не держит в памяти код - сейчас asd() вызывает один код, а через 5 минут запросто может вызывать совсем другой код из другого модуля (конечно если разработчик так захочет). Единственное что неизменно - это имя, и с ним нет особых проблем. По параметрам - фокс не типизирован ни на каплю, потому ему вообще по барабану сколько и чего ты передаёшь при вызове функции (ну предел числа параметров есть, но "заказать" чтоб их было скажем ровно 3 и все при том числа - невозможно никак)...

Ну, возможно, я "привык", что на уровне API принято разделять функционал, скажем так, EvalMacro() и CallFunction(). Здесь же это объединено. Ну, насчет того, что "не держит в памяти код", может быть действительно, бог с ним, Фоксу виднее. А вот насчет параметров, я имел в виду, что при таком синтаксисе, программисту, который что-то делает на API, чтобы вызвать какую-то функцию с параметрами, необходимо преобразовать все параметры в символьное представление их значений (!)... Посмотрел пример fd3 из поставки Фокса - _Execute и _Evaluate вызываются обильно, параметризуется все именно так.. "символически" Кстати, а каков синтаксис значения массива и есть ли максимум на длину выражения?

Сейчас "в голове крутится" только один workaround, это держать в том же объекте frReportManager некий массив, который текущими параметрами и заполнять (с переменными то проблем нет), выражение же в части параметров строить уже просто перечисляя элементы этого массива. В связи с этим вопрос: нет ли в Фоксе каких-либо областей видимости по коду? То есть, если экземпляр объекта frReportManager создан и работает, то объект будет доступен из любой точки программы?

Спасибо.

SergeySpirin
если экземпляр объекта frReportManager создан и работает, то объект будет доступен из любой точки программы?

Если его не забыли объявить глобальным, то да, будет доступен.

SergeySpirin
В связи с этим вопрос: нет ли в Фоксе каких-либо областей видимости по коду? То есть, если экземпляр объекта frReportManager создан и работает, то объект будет доступен из любой точки программы? Спасибо.

Если привязать объект к глобальной переменной - то будет доступен из любой точки.

Наша фирма, сгоряча, почитав документацию на сайте FastReport'а, купила FastReport Studio 4.
Использовать объекты FastReport, напрямую из фокса, очень геморрно и глючно, ломается на чем не поподя, причем, каждый раз на разном. Особенно много проблем UserDataSet!
Техподдержка у них отвратительная!
Путем переговоров нашего руководства с ихним, получили FastReport VCL.
Сейчас тоже будем чегой-то подобное выдумывать.
Поэтому, можем, по мере приобретения, делиться опытом! ;)

Знеачит концепцию NAtive для VFP уже надо публиковать, и делать какие-то бесплатные беты для тестирования, или определить круг тестирующих уже назрело. Ждем разработчиков

piva
Знеачит концепцию NAtive для VFP уже надо публиковать, и делать какие-то бесплатные беты для тестирования, или определить круг тестирующих уже назрело. Ждем разработчиков

Вы немного забегаете вперед Я сегодня третий день только как сел за работу (на выходных, к сожалению, позаниматься этим не удалось). Для того, чтобы начать что-то тестировать мне необходимо сделать две вещи, а именно:

- написать дельфийскую обертку вокруг FoxAPI.
- написать дельфийский класс FoxDataSet.

Это и есть, кстати говоря, концепция Native. Исходя из опыта других языков, недельки три мне, как минимум, потребуется. Только после этого можно будет начинать тестировать доступ дельфи-dll к данным Фокса. Но, собственно говоря, все это "моя внутренняя кухня". Я уже говорил, что делал это для двух других языков, сделаю и для фокса. А вот в самом Фоксе...

Pliskin
Наша фирма, сгоряча, почитав документацию на сайте FastReport'а, купила FastReport Studio 4.
Использовать объекты FastReport, напрямую из фокса, очень геморрно и глючно, ломается на чем не поподя, причем, каждый раз на разном. Особенно много проблем UserDataSet!
Техподдержка у них отвратительная!
Путем переговоров нашего руководства с ихним, получили FastReport VCL.
Сейчас тоже будем чегой-то подобное выдумывать.
Поэтому, можем, по мере приобретения, делиться опытом! ;)

А вот в самом Фоксе, понятно, что я дилетант. Поэтому, раз уж наши пути так интересно "пересеклись", то мне параллельно было бы очень интересно пообсуждать реализацию fox-класса frReportManager. Ниже декларация этого класса для Харбура (Клиппера). Как грамотно тоже самое сделать на Фоксе?

Ну и, как я сказал, помощникам я обещаю бесплатную лицензию на продукт, поэтому, может быть, вам не торопиться с собственной реализацией Фаста?


CLASS frReportManager
Hidden:
VAR ....

METHOD PrepareCalls

EXPORTED:

VAR bSaveError // Save Error handler
CLASSVAR frSystHandle init 0 // Handle of FastReport-dll
VAR PrintOptions // look frPrintOptions class
VAR PreviewOptions // look frPreviewOptions class
VAR EngineOptions // look frEngineOptions class
VAR ReportOptions // look frReportOptions class
CLASSVAR bDbStruct init NIL

METHOD Init
METHOD FrNotifyError
METHOD SetIcon
METHOD SetTitle
METHOD SetVisualActions
METHOD LoadLangRes
METHOD SetFormatSettings
METHOD DestroyFR

METHOD ShowReport
METHOD ShowPreparedReport
METHOD PrepareReport
METHOD DesignReport
METHOD LoadFromFile
METHOD LoadFromResource
METHOD LoadFromBlob
METHOD LoadFromString
METHOD SaveToFile
METHOD SaveToBlob
METHOD SaveToString
METHOD SetFileName
METHOD Clear
METHOD LoadFPFile
METHOD SaveToFPFile
METHOD AddReport
METHOD SelectReport
METHOD RemoveReport
METHOD ClearReports

METHOD Print
METHOD GetErrors
METHOD DoExport
METHOD LoadStyleSheet
METHOD LoadStyleSheetFromString

METHOD GetProperty
METHOD SetProperty
METHOD SetEventHandler
METHOD AddFunction
METHOD SetObjProperty

METHOD AddVariable
METHOD SetVariable
METHOD GetVariable
METHOD DeleteVariable
METHOD DeleteCategory

METHOD SetScriptVar
METHOD GetScriptVar
METHOD Calc

METHOD SetWorkArea
METHOD SetMasterDetail
METHOD SetResyncPair
METHOD SetUserDataSet
METHOD SetTxtDataSet
METHOD SetFieldAliases
METHOD Resync
METHOD ClearMasterDetail
METHOD ClearResyncPair
METHOD RemoveDataSet
METHOD ClearDataSets
METHOD SetADOConnectStr
METHOD SetADOConnectPartStr

METHOD StartManualBuild
METHOD MemoAt
METHOD SetDefaultFontProperty
METHOD NewPage
METHOD SetManualObjProperty
METHOD LineAt
METHOD PictureAt

METHOD NewReport
METHOD AddPage
METHOD AddBand
METHOD AddGlobalDsToReport
METHOD GetGlobalDSList
METHOD AddMemo
METHOD AddLine
METHOD AddPicture

METHOD IsObjectExists
METHOD CreateFRObject
METHOD EnumAllObjects
METHOD GetPropList
METHOD PrepareScript

METHOD SendMail
METHOD InputBox
METHOD SetTabTreeExpanded

ENDCLASS

CLASS frEngineOptions
HIDDEN:
VAR ....

METHOD PrepareCalls
EXPORTED:
METHOD Init
METHOD SetConvertNulls
METHOD SetDoublePass
METHOD SetPrintIfEmpty
METHOD SetSilentMode
METHOD SetNewSilentMode
METHOD SetMaxMemSize
METHOD SetTempDir
METHOD SetUseFileCache
ENDCLASS

CLASS frPrintOptions
HIDDEN:
VAR ...

METHOD PrepareCalls
EXPORTED:
METHOD Init
METHOD SetCopies(nCopies) INLINE Call_Func_I_I(::_SetCopies, IF(nCopies <> NIL, nCopies, -1))
METHOD SetCollate
METHOD SetPageNumbers
METHOD SetPrinter
METHOD SetPrintPages(nPages) INLINE Call_Func_I_I(::_SetPrintPages, IF(nPages <> NIL, nPages, -1))
METHOD SetShowDialog
METHOD SetReverse
METHOD ClearOptions
ENDCLASS



CLASS frPreviewOptions
HIDDEN:
VAR .....

METHOD PrepareCalls
EXPORTED:
METHOD Init
METHOD SetAllowEdit
METHOD SetButtons
METHOD SetDoubleBuffered
METHOD SetMaximized
METHOD SetBounds
METHOD SetOutlineVisible
METHOD SetOutlineExpand
METHOD SetOutlineWidth
METHOD SetShowCaptions
METHOD SetZoom
METHOD SetZoomMode
METHOD SetModal
METHOD SetPictureCacheInFile
METHOD SetRemoveReportOnClose
ENDCLASS

SergeySpirin
Для того, чтобы начать что-то тестировать мне необходимо сделать две вещи, а именно:

- написать дельфийскую обертку вокруг FoxAPI.
- написать дельфийский класс FoxDataSet.

Есть сомнения, что получится правильно прилинковать библиотеку winapims.lib к дельфи - она не особо
дружит даже с не-микрософтовскими компиляторами C, не то что с дельфи
Учти, что FoxAPI динамически линкуется с MS CRT и в нем уже объявлена DllMain (где собственно и
инициализируются API callback в текущий процесс VFP).
Поэтому "обертка вокруг FoxAPI" скорее всего будет чисто виртуальная и
нужно будет ее инициализировать в момент загрузки fll в VFP

Рома
Есть сомнения, что получится правильно прилинковать библиотеку winapims.lib к дельфи - она не особо
дружит даже с не-микрософтовскими компиляторами C, не то что с дельфи
Учти, что FoxAPI динамически линкуется с MS CRT и в нем уже объявлена DllMain (где собственно и
инициализируются API callback в текущий процесс VFP).
Поэтому "обертка вокруг FoxAPI" скорее всего будет чисто виртуальная и
нужно будет ее инициализировать в момент загрузки fll в VFP

Эту стадию я уже прошел. Поэтому и появились два модуля (С-fll и Delphi-dll) . Для других языков у меня только одна дельфийская dll. Действительно, начал с кавалерийских наскоков сделать все на дельфи... Потерпел фиаско Далее задействовал любимый Borland C++ 5.5.1... успех был такой же Но, нашел у себя в архивах VC++ 6.0. И все заработало.

Насчет DllMain, уже тоже обратил внимание. А насчет инициализации, конечно будут у объекта frReportManager конструктор/деструктор где все будем "загружать/выгружать"

Еще один, если позволите, уточняющий вопрос.

Речь о возможной многопоточности. На уровне FoxAPI вроде нет ничего по этому поводу. В хелпе вижу только по топикам, касающимся типа только всяких OleAutomation и т.п.

Собственно, вопрос, Fox, как средство разработки приложений, на "эту тему может предлагать что-нибудь", или здесь четко однопоточная модель? Другими словами, может ли у пользователя, например, желание возникнуть открыть пять предварительных просмотров отчетов в пяти потоках? Или он всегда откроет их последовательно, в одном потоке?

Для пользователя фокс однопоточный. Внутри себя он обычно несколько потоков организует. В принципе, пользуя COM, можно попытаться и самому потоков наплодить - но вот только многопоточный рантайм по определению невизуальный, так что для просмотра отчётов это крайне маловероятно - а всякие "тяжкие расчёты" выносить в СОМ - вряд-ли это коснётся тебя
P.S. Так как основной рантайм однопоточен, крайне опасно пытаться через фоксапи создавать свои потоки и из них дёргать фоксовый код. Чисто для своих целей, без взаимодействия с рантаймом, конечно же можно
P.P.S. Т.к. обычный фоксовый "просмотрщик отчёта" немодален, то в принципе МОЖНО одновременно и листать отчёт и ещё чего-нить где-нить на формах делать (вот не помню как насчёт сразу кучу превьюшек сделать - т.к. почти не пользуюсь фоксовым репортером) - не знаю насколько это осложнит тебе жизнь - ведь и данные для такого случая нужно будет подтягивать в произвольный момент времени (для фоксового репорта надёжно будет работать только если он в своей датасессии сидит, или чисто по "непользуемому другими" курсору строится).





Исправлено 1 раз(а). Последнее : Igor Korolyov, 16.09.10 02:37

Igor Korolyov
Для пользователя фокс однопоточный...

Ok. Спасибо. Это для меня главное. То есть, сам я использовать потоки не собираюсь, но если бы это "приходило" от пользователя, то потребовало бы от меня дополнительного контроля.

Igor Korolyov
P.P.S. Т.к. обычный фоксовый "просмотрщик отчёта" немодален, то в принципе МОЖНО одновременно и листать отчёт и ещё чего-нить где-нить на формах делать (вот не помню как насчёт сразу кучу превьюшек сделать - т.к. почти не пользуюсь фоксовым репортером) - не знаю насколько это осложнит тебе жизнь - ведь и данные для такого случая нужно будет подтягивать в произвольный момент времени (для фоксового репорта надёжно будет работать только если он в своей датасессии сидит, или чисто по "непользуемому другими" курсору строится).

Ну, в однопоточной модели, несколько отчетов просто будут строиться последовательно по очереди Соответственно, и их предпросмотры будут на экране появляться последовательно. В этом случае проблем быть не должно.

Подскажите, пожалуйста, по массивам.

Правильно ли я понимаю, что массив не может быть возвращаемым значением выражения? И в этом случае возвращается всегда только первый элемент массива?

SergeySpirin
Подскажите, пожалуйста, по массивам.
Правильно ли я понимаю, что массив не может быть возвращаемым значением выражения? И в этом случае возвращается всегда только первый элемент массива?

Да. Правильно.

Обычно массив создается вне процедуры, а в процедуру передается ссылка на массив. Т.е. изменения массива внутри процедуры автоматически меняют значения этого же массива и во-вне процедуры. В этом случае из процедуры просто возвращают флаг успешно или не успешно она отработала.

Однако можно вернуть из процедуры объект, а все необходимые значения оформить как свойства этого объекта. Можно создать и свойство объекта типа массив.

в общем случае нет например


Выдаст ошибку на строчке xx=ret() "AA is not an array", оно и ясно, потому что передали ссылку на массив которого в настоящий момент уже нет, можно сделать так


но это не кузяво ваще-то клепать public массивы
Есть одна смешная дыра в фоксе, если переопределать процедуру на такую, то возвращает массив