Форум » [x]Harbour » Delphi Run-Time for [x]Harbour (размышления). » Ответить
Delphi Run-Time for [x]Harbour (размышления).
Sergey Spirin: Здравствуйте. Все-таки не покидает меня мысль о том, что было бы очень неплохо организовать Delphi Run-Time для [x]Harbour. В очередной раз мысль вернулась в связи с выходом Delphi2010. В этой версии сняты ограничения по rtti-доступу даже к private-секциям классов и т.д., что делало бы задачу еще проще. Собственно, сейчас пожалуй, я могу четче сформулировать, что я имею в виду, и даже немного проиллюстрировать. Вообще, предоставление Дельфи ран-тайма не-дельфи инструменту, не является какой-то уникальной мыслью. Например, инструмент, написанный Алексеем Волковым - Script Builder. Он и будет иллюстрацией того, что я имею в виду под Delphi Run-Time. Script Builder - это Delphi Run-Time для Microsoft Active Scripting (VBScript, JavaScript, ActivePerl, ActivePython). Скачать его можно с: http://www.volkoff.ru/file_download/4/sbpro.exe Script Builder написан на Delphi5 довольно давно (2000-й год) и имеет немного старомодный интерфейс. Но если вы его скачаете и немного "пощупаете", то увидите, что это продукт более качественный, чем те же Xailer или тем более Visual xHarbour. А по уровню предоставляемого ран-тайма и его расширяемости и сравнивать нечего, это, собственно, дельфи. Так вот, под "Delphi Run-Time for [x]Harbour" я подразумеваю аналогичный (но более современный инструмент) для [x]Harbour, который полностью поддерживал бы Unicode (имею в виду визуальные компоненты). ----- Реализация. Ясно, что начинать надо с 2-x сторон. 1) Delphi-часть, сначала собственно ран-тайм, здесь в общем-то все понятно и я могу это реализовать. 2) [x]Harbour-часть, здесь необходима некоторая библиотека, которая бы обеспечивала прозрачный доступ к классам, объектам Дельфи и делала бы их частью своего языка. Здесь моих знаний [x]Harbour явно не хватит. То есть, одному мне такой проект не поднять... Поэтому и пишу Паша, Григорий, Петр и другие уважаемые форумчане! Что вы думаете об этом? О возможном своем участии? Жду ваши комменты Спирин Сергей.
Sergey Spirin: Наиль пишет: Так как времени писать программу нет, то я пишу письма. Одно из них я направил Алексею Волкову с предложением... Наиль, пример ScriptBuilder-а использовался только для иллюстрации принципиальной портируемости delphi run time "во вне". Использовать его сегодня у меня даже особых планов не было. Не расстраивайтесь
Alexey Volkov: Привет, сограждане. Раз уж я оказался каким-то боком причастен к теме, то пожалуй тоже выскажу пару соображений. Во-первых, почему не .net? для нета существуют открытые и вполне жизнеспособные визуальные среды. Далее: 2) [x]Harbour-часть, здесь необходима некоторая библиотека, которая бы обеспечивала прозрачный доступ к классам, объектам Дельфи и делала бы их частью своего языка Я к сожалению с Харбором не знаком совсем, но что-то мне подсказывает, что если есть возможность интегрировать ФастРепорт, то можно интегрировать много чего ещё. COM объекты поддерживается? Если да, то не вижу причин, почему нельзя сделать "объекты Дельфи частью своего языка", в том виде, в котором они представлены в Билдере, в существующей реализации. Для этого у меня есть комовский интерфейс, через который можно подгружать билдеровские апплеты куда угодно, и вызывать формы и скрипты. Теоретически. На практике работает из приложений на Дельфи 7.
Sergey Spirin: Alexey Volkov пишет: Привет, сограждане. Раз уж я оказался каким-то боком причастен к теме, то пожалуй тоже выскажу пару соображений. Привет, Алексей! Забавно, что Вы тоже "здесь оказались" Alexey Volkov пишет: Во-первых, почему не .net? для нета существуют открытые и вполне жизнеспособные визуальные среды. Тут надо учитывать специфику Харбора. Собственно, это 32-х разрядный Клиппер. Сообщество, которое его использует тоже специфично. Большинство, это люди, которые "не смогли", "не захотели" и т.д. перейти на более современные языки/технологии... И небольшой процент людей, это те, кто решил либо подзаработать, либо удовлетворить собственное тщеславие на этом большинстве Каких-то революций в ядре Xарбора при существующей схеме разработки вряд ли стоит ожидать... А без этого смычка нативного Win32 с .net выглядит как-то натянуто... Alexey Volkov пишет: Я к сожалению с Харбором не знаком совсем, но что-то мне подсказывает, что если есть возможность интегрировать ФастРепорт, то можно интегрировать много чего ещё. COM объекты поддерживается? Если да, то не вижу причин, почему нельзя сделать "объекты Дельфи частью своего языка"... Да и с COM не так все просто, хотя он в каком-то виде поддерживается ФастРепорт интегрирован довольно специфично, на чистом Win32, то есть, писался специальный код, чтобы все это соединилось. Показательно то, что FastReport-COM существует же, это FastReport Studio. Казалось бы, а чего не использовать универсальное решение? Но возникает сразу много проблем, например, Харбор использует свой движок данных, доступ к которому типовыми средствами не унифицирован и из Студии, конечно, "родные dbf-ы напрямую" не получить.. и т.д. Также показателен пример, что один из активных разработчиков Xaрбор Pritpal Bedi долго "мучил" Студию, пытаясь из нее что-то "выжать". Но в конце концов плюнул и купил у меня Win32-решение.... А делать нативный доступ к данным на COM-е.., что-то тоже есть сомнения В виду подобных факторов мы в дилоге с Петром в этой теме пришли к выводу, что Win32, это пожалуй наиболее органично для сегодняшнего Харбора. Ну а здесь, на этом поле, одна из самых первоклассных GUI-библиотек это VCL, конечно... К ней взоры и обратились, особенно в контексте изменений RTTI в Delphi2010...
Alexey Volkov: А в чём проблема с доступом к родным dbf-ам? Насколько я помню, мои юзеры использовали фришный компонент TDbf для доступа к клипперовским базам. Правда, только для импорта данных. Не знаю, насколько оно жизнеспособно для полноценной работы. Но наверняка есть подобные компоненты, это надо в первую очередь выяснить и попробовать. Иначе имеет ли смысл вся затея с прикручиванием VCL? А что революционного в RTTI Delphi 2010 по сравнению с предыдущими? в двух словах? я извиняюсь за отсталость, просто очень давно не занимался дельфями и виндой вообще. ИМХО революционным шагом был бы не доступ к приватным членам, а автоматический IDispatch для каждого TComponent "изкаробки". Тогда можно было бы избавиться от большого куска проприетарщины в движке, и от глюков, о которых тут писали, когда правильный код почему-то вдруг отказывается работать...
Alexey Volkov: Ёшкин кот. Они сделали это. http://delphihaven.wordpress.com/2009/09/02/d2010-rtti-and-active-scripting/ Автоматический IDispatch стал реальностью.
Sergey Spirin: Alexey Volkov пишет: А в чём проблема с доступом к родным dbf-ам? Насколько я помню, мои юзеры использовали фришный компонент TDbf для доступа к клипперовским базам. Правда, только для импорта данных. Не знаю, насколько оно жизнеспособно для полноценной работы. Но наверняка есть подобные компоненты, это надо в первую очередь выяснить и попробовать. Иначе имеет ли смысл вся затея с прикручиванием VCL? Здесь Вы не совсем поняли. Понятно, что есть Delphi-компоненты, которые могут работать с dbf-файлами, и что это дает? Практически ничего Вы просто не учитываете, что открытие dbf-файла это именно открытие файла на уровне файловой системы. Счас не знаю, но раньше тот же TDbf был весьма простеньким решением, у него тут же бы в реальной работе начались несовместимости по индексам, блокировкам и т.д. Да, были и солидные решения типа платного Halcyon, но в любом случае, это открытие одного файла В РАМКАХ ОДНОГО ПРИЛОЖЕНИЯ, двумя РАЗНЫМИ DbEngine... Что, по большому счету, недопустимо... Под "нативным доступом" я имел в виду доступ к именно Харбор-DbEngine и работу через нее только одну. В рамках Фаста я написал THarbourDataSet, который и оперирует с Харбор-DbEngine, представляя собой просто оболочку над ней. Достигается это использованием Харбор API, которое представляет собой просто набор процедур и функций, почему я это и назвал чистым Win32 В DRT я просто предлагаю сохранить ту же идеологию. А с какой стороны и для чего "прикручивать" здесь COM не очень понятно... Alexey Volkov пишет: А что революционного в RTTI Delphi 2010 по сравнению с предыдущими? в двух словах? Alexey Volkov пишет: Ёшкин кот. Они сделали это. Ну вот Вы сами себе и ответили Если в двух словах, то Delphi теперь полностью рефлексируемый язык. Я тут выкладывал выше новый пример в постаке "Reflection Browser". В младших версиях такого не сделать (исходник примера строк 30).
Alexey Volkov: Sergey Spirin пишет: Под "нативным доступом" я имел в виду доступ к именно Харбор-DbEngine и работу через нее только одну. В рамках Фаста я написал THarbourDataSet, который и оперирует с Харбор-DbEngine, представляя собой просто оболочку над ней. Достигается это использованием Харбор API, которое представляет собой просто набор процедур и функций, почему я это и назвал чистым Win32 В DRT я просто предлагаю сохранить ту же идеологию. А с какой стороны и для чего "прикручивать" здесь COM не очень понятно... К THarbourDataSet можно привязать грид через TDataSource? И работать с данными корректно с точки зрения DbEngine? Если да, то это замечательно, это полдела. Теперь поясните пожалуйста, в чём вы видите роль DRT в вашей архитектуре? Какую смысловую и функциональную нагрузку будет выполнять DRT? Основной (хотя и настраиваемый) визуальный интерфейс к данным и к некоторым кускам старого нативного кода, либо просто возможность вызова визуальных форм из нативного кода? Надеюсь, вы понимаете, что в первом случае код, который будет лежать непосредственно под формами DRT, будет принципиально отличаться от нативного клиппера, даже если удастся создать синтаксически похожий скриптовый клиппер? Именно притом тут COM. Чтобы в полной мере воспользоваться преимуществами новой реализации RTTI, язык должен быть а) интерпретируемым б) уметь обращаться с IDispatch, т.е. получается ActiveScript релизация клиппера. А если мы ограничиваеся голым Win32 API, то получаем именно то, о чём вы писали выше, а именно: SomeVar := CallConstructor("TForm", "Create") SetProperty(SomeVar, "Width", 800) CallMethod(SomeVar, "ShowModal") достаточно архаичный код, сводящий к минимуму преимущества ран-тайм дизайна. Но в данной дискуссии я вот почему интересовался насчёт COM: в SBuilder COM используется ещё и для интеграции ран-тайм аплетов с нативными приложениями. Run-time Engine предоставляет COM интерфейс, через который можно загружать апплеты и обрщаться к их объектам и переменным. И обратно: нативная аппликация может предоставить ран-тайм модулю некий объект (объекты), видимый в скрипте глобально. Реализация этого объекта - абсолютно предметно-ориентированная вещь. Что нужно, то и реализуйте, что хотите, то и предоставляйте. В чём преимущество такого подхода? Подумайте сами, что проще - писать некие обёртки для всего, что может потребоваться из VCL, или написать один-два специфических COM-объекта и экспортировать их в Run-time Engine, которая уже видит весь VCL? Теперь ключевой вопрос: если вы пишете Win32 библиотеку для сопряжения с FR, то почему бы не попробовать написать аналогичную библиотеку для сопряжения с SB? COM здесь лишь способ коммуникации с Run-time Engine внутри этой библиотеки, вызов CoCreateObject внутри dll природой не запрещено. А для нативного доступа к данным из райн-там апплета используйте свой THarborDataSet, точно так же, как бы вы делали это из Дельфи и из FR. Вот вам и Delphi Run-Time для Харбор. В перспективе и скриптовый клипперо-подобный интерпретатор можно будет прикрутить, чтоб код в визуальной среде генерился похожий. Но тут возникает одно НО: технически это всё интересно и красиво, но нужно ли это людям, которые как вы говорите, сознательно остались в технологиях 20-летней давности? Переход от процедурного к объектному мышлению для многих так и остался непреодолимой преградой, у них никогда не будет понимания важности не языка, а объектной модели. А без этого понимания вас вечно будут просить "допиливать" и усложнять язык, тянуть туда всё больше специфики, чтоб было "так же, как раньше". Никто не будет читать хелп по свойствам, и все будут говорить, что в аксессе проще.
Наиль: Alexey Volkov пишет: даже если удастся создать синтаксически похожий скриптовый клиппер http://www.xbscript.com/ - Вполне себе ActiveScript В остальном я с Алексеем согласен, для того, чтобы писать на одном языке, нужна соответствующая библиотека, которая будет обёрткой над всеми объектами Delphi, а это бесконечный и не благодарный труд. В противном случае может получиться так, что язык станет смесью Харбора и Паскаля. Это то, что я назвал сильнодинамическим методом, т.е. возможность писать программу использующую компоненты Delphi без использвания постороних инструментов и на одном языке. Слабодинамическим методом называю такой вариант, при котором создаётся обёртка только вокруг конкретных форм (окон) Delphi. Под формой подразумевается окно программы с раставлеными на ней визуальными и не визуальными компонентами. Код подобный следующему . SomeVar := CallConstructor("TForm", "Create") . SetProperty(SomeVar, "Width", 800) . CallMethod(SomeVar, "ShowModal") будет генерироваться средой, а связывание основной программы и обёртки будет производиться какой-нибудь библиотекой вроде SAX для XML. Этот метод я расматривал, как основной, пока не познакомился с xbscript, а после знакомства пришел к такому же выводу, как Alexey Volkov: если вы пишете Win32 библиотеку для сопряжения с FR, то почему бы не попробовать написать аналогичную библиотеку для сопряжения с SB? COM здесь лишь способ коммуникации с Run-time Engine внутри этой библиотеки, вызов CoCreateObject внутри dll природой не запрещено. А для нативного доступа к данным из райн-там апплета используйте свой THarborDataSet, точно так же, как бы вы делали это из Дельфи и из FR. Вот вам и Delphi Run-Time для Харбор.
Alexey Volkov: Наиль, а попробуйте это дело инсталлировать, потом возьмите билдер, создайте новую аппликацию, в списке языков должно появиться "xbScript". Интересно пощупать.
Sergey Spirin: Alexey Volkov пишет: К THarbourDataSet можно привязать грид через TDataSource? Конечно, как к любому потомку TDataSet. Alexey Volkov пишет: И работать с данными корректно с точки зрения DbEngine? Естественно. Alexey Volkov пишет: Но в данной дискуссии я вот почему интересовался насчёт COM: в SBuilder COM используется ещё и для интеграции ран-тайм аплетов с нативными приложениями. Run-time Engine предоставляет COM интерфейс, через который можно загружать апплеты и обрщаться к их объектам и переменным. И обратно: нативная аппликация может предоставить ран-тайм модулю некий объект (объекты), видимый в скрипте глобально. Реализация этого объекта - абсолютно предметно-ориентированная вещь. Что нужно, то и реализуйте, что хотите, то и предоставляйте. В чём преимущество такого подхода? Подумайте сами, что проще - писать некие обёртки для всего, что может потребоваться из VCL, или написать один-два специфических COM-объекта и экспортировать их в Run-time Engine, которая уже видит весь VCL? Теперь ключевой вопрос: если вы пишете Win32 библиотеку для сопряжения с FR, то почему бы не попробовать написать аналогичную библиотеку для сопряжения с SB? COM здесь лишь способ коммуникации с Run-time Engine внутри этой библиотеки, вызов CoCreateObject внутри dll природой не запрещено. А для нативного доступа к данным из райн-там апплета используйте свой THarborDataSet, точно так же, как бы вы делали это из Дельфи и из FR. Вот вам и Delphi Run-Time для Харбор. В перспективе и скриптовый клипперо-подобный интерпретатор можно будет прикрутить, чтоб код в визуальной среде генерился похожий. Про COM. Правильно ли я понимаю, что речь о том, чтобы на лету генерить интерфейсы для Харбор приложения, который оно и будет использовать для создания и т.д. объектов, то есть, каждый Дельфи-объект будет репрезентирован СОМ-объектом с которыми Харбор-приложение и будет, собственно, работать?.... Если так, то выглядит, конечно, очень привлекательно, нет нужды пред-генерить что-то на Харбор стороне, работать можно типовыми средствами языка... Из скептических мыслей здесь пожалуй слудующее: - На вскидку, не уверен в развитости средств работы с COM в Харборе.. Здесь Харбор-специалисты должны подсказать нам. - Что-то есть какие смутные сомнения, что даже с RTTI 2010, "все завернется в COM" гладко и без дополнительной писанины... Как по вашему опыту? Относительно SB и скриптов. Мне, честно говоря, не очень понятна именно в нашей проблематике необходимость скриптового языка. SB "заточен" только на ActiveScript? А так, SB производит приятное впечатление, единственное, судя по версиям bpl, это пятый Дельфи? Интерфейс и "компонентная палитра" выглядят немного как "взгляд из 90-х". Относительно "кому это надо"... Сообщество здесь небольшое, много не заработать Хотя тот же Фаст здесь дает мне достаточно стабильный доход, хоть и не очень большой. Думаю, что занимаюсь этим в силу и некоторой инерции, когда-то я много работал над переводом Клиппер-приложений на Дельфи, и, хотя сегодняшняя работа ничего общего с этим не имеет, все равно интересуюсь Что-то мне подсказывает, что ваше пояление здесь обусловлено аналогичными причинами в "контексте SB"
Alexey Volkov: Давайте по-порядку. Sergey Spirin пишет: Правильно ли я понимаю, что речь о том, чтобы на лету генерить интерфейсы для Харбор приложения, который оно и будет использовать для создания и т.д. объектов, то есть, каждый Дельфи-объект будет репрезентирован СОМ-объектом с которыми Харбор-приложение и будет, собственно, работать? Скажем, не не лету, а на старте, в вашей библиотеке сопряжения создаётся некий объект, который "открывает" во внешний мир вашу наверняка не самую развесистую объектную модель. Аналогично тому, как Ворд и Екзел "подсовывают" в VBA каждый свой собственный объект "Application", со специфичными каждому приложению методами и свойствами. Вам, скорее всего, нужно будет реализовать только вызов нативных процедур по имени, и возвращение значений переменных по имени. Интерфейс очень простой, значения ходят туда-сюда в виде Variant. Это то, что касается части коммуникации в направлении Апплет => Харбор. Теперь в обратном направлении: Sergey Spirin пишет: каждый Дельфи-объект будет репрезентирован СОМ-объектом с которыми Харбор-приложение и будет, собственно, работать? Да, каждый Дельфи объект представлен COM объектом. Т.е. к каждому объекту Апплета можно обратиться, если есть указатель на корневой элемент (а он возвращается при загрузке Апплета) и известно полное имя дочернего объекта в точечной нотации. Нужно точно знать, к кому и к чему обращаешься. Указатель на корневой элемент можно присвоить переменной Variant, и далее делаем, что нам надо: var MainForm: Variant; text: string; begin MainForm := SBLoader.LoadLibrary("Test.sbl"); // тут я уже подзабыл, как оно работает, но принцип такой .... text := MainForm.TextEdit1.Text; end; Вот если бы нативный Харбор умел работать с вариантами (вернее, с IDispatch, завёрнутым в вариант) также, как это делает Дельфи, то на этом и дело в шляпе. Но боюсь, вам всё-таки придётся реализовать некую GetProp/SetProp/CallMethod на стыке с Харбором. Как показывает практика, задачу интеграции рантайма можно (и нужно!) формализовать, отделив мух от котлет (нативный код от рантайм-аплетов): ограничиться возможностью вызова аплетов лишь через некие "точки входа" с известной семантикой и известным типом результата. Тогда реализация CallMethod упрощается. Именно так сделано и VBA: из Ворда можно вызвать лишь "макрос" определённой семантики, "нырнуть" внутрь, сделать, всё что хочешь, и вынырнуть. Sergey Spirin пишет: - На вскидку, не уверен в развитости средств работы с COM в Харборе.. Здесь Харбор-специалисты должны подсказать нам. Вот хорошо бы, если бы нам прояснили ситуацию с Вариантами и IDispatch. Если этого нет - делаем сами в библиотеке сопряжения, и экспортируем как win32-обёртки. Благо, что их понадобится немного, если задачу формализовать. Sergey Spirin пишет: - Что-то есть какие смутные сомнения, что даже с RTTI 2010, "все завернется в COM" гладко и без дополнительной писанины... Как по вашему опыту? Если верить этому чуваку, то всё завернулось достаточно гладко: http://delphihaven.wordpress.com/generic-idispatch-proxies-for-active-scripting/ А это большоооой и глючный кусок текущей реализации ком-обёрток в SB, к тому же накладывающий ограничение на интеграцию сторонних компонентов. Поэтому SB выглядит приветом из 90х. Sergey Spirin пишет: Относительно SB и скриптов. Мне, честно говоря, не очень понятна именно в нашей проблематике необходимость скриптового языка. SB "заточен" только на ActiveScript? А каковы преимущества компилятора? Парадоксально, но интепретатор интегрировать проще, и дёргаться-то будут всё те же методы через RTTI. Преимущества ActiveScript - возможность настраивания бизнес-логики на ходу. Плюс такие вкусности, как о отладка. Производительность хуже? Не будем же мы сравнивать производительность пустого обработчика Button1Click в скрипте с пустым нативным обработчиком? Даже на Pentium1 разницы не будет заметно. Встраивать VCL через RTTI, но в компилированный код обвязки - всё равно что тратить на водку, но экономить на спичках )) Ну это ИМХО.
Alexey Volkov: Sergey Spirin пишет: Относительно "кому это надо"... Сообщество здесь небольшое, много не заработать Хотя тот же Фаст здесь дает мне достаточно стабильный доход, хоть и не очень большой. Думаю, что занимаюсь этим в силу и некоторой инерции, когда-то я много работал над переводом Клиппер-приложений на Дельфи, и, хотя сегодняшняя работа ничего общего с этим не имеет, все равно интересуюсь Что-то мне подсказывает, что ваше пояление здесь обусловлено аналогичными причинами в "контексте SB" И моя сегодняшняя работа никаким местом с Дельфи не связана. Просто неожиданно вдруг совершенно разные люди, с разными задачами проявили интерес к проекту. Вплоть до предложений выкупить права. Ну а в свете последних изменений в Дельфи, мне кажется, хоронить проект или отказываться от него пока рано. Если перевести на компонентную базу 10ки, то он ещё столько же проживёт, пусть в закрытом виде, но кому оно интересно, что там внутри, если оно не будет глючить и будет дружить со сторонними компонентами?
Наиль: Alexey Volkov пишет: Наиль, а попробуйте это дело инсталлировать, потом возьмите билдер, создайте новую аппликацию, в списке языков должно появиться "xbScript". Интересно пощупать. Пока сделал наоборот, при установленом SB установил XBScript. Увы, SB показывает прежний набор скриптов, а не тот который установлен в системе. Примеры идущие в комплекте XBScript демонстрируют возможности характерные для других скриптовых языков, вроде JavaScript, но не показывают как работать с базами данных . Есть довольно эффектный пример использования DOM. К сожалению, я не знаком с Клипером-Харбором и не могу оценить красоту примеров. Но вижу, что это эффективный способ получить решение не через годы, а в ближайшее время, правда это не совсем Харбор, но зато не придётся учить новый язык, вернее синтаксис нового языка. Я заинтересовался Delphi Run-Time для [x]Harbour (DRT4HB) потому, что из всего Харбора знаю лишь Delphi. Для Харбор сообщества это должно быть интересно потому, что более мощного для GUI под Windows пока ещё ни кто не предложил. Для Delphi сообщества это может быть интересно потому, что взамен смеси двух языков Pascal+SQL для проектирования баз данных можно получить один язык - Харбор, но с прежнеми визуальными элементами. Язык Клипер-Харбор имеет такое же значение для небольших баз данных, как PHP для HTML. Т.е. у языка есть большая перспектива. Но нужна определёная просветительская деятельность. А так же возможность создания современных интерфейсов с использование Харбор. Спасибо Вам, Алексей, за то, что вы откликнулись на мою просьбу и приняли участие в обсуждении.
Andrey: Sergey Spirin пишет: На вскидку, не уверен в развитости средств работы с COM в Харборе.. Здесь Харбор-специалисты должны подсказать нам. У меня есть пример работы с ключом HASP HL (фирмы Alladin) через COM xHarbour'a ! Т.е. xHarbour вызывает через COM-объект внешнюю hasp_com_windows.dll, а через нее осуществляется доступ к крипто-процессору на ключе HASP HL. Что бы зашифровать файл объемом 100Кб требуется 3.2сек, а 700Кб - 192сек. Те же функции обращающиеся напрямую дают результат: 100Кб требуется 0.14сек, а 700Кб - 0.17сек. Так что ну его нафиг - этот COM ...
Alexey Volkov: Наиль пишет: Пока сделал наоборот, при установленом SB установил XBScript. Увы, SB показывает прежний набор скриптов, а не тот который установлен в системе. Да, я тоже попробовал. С наскоку не получилось Дело в том, что дополнительный язык надо регистрировать ещё в самом Билдере. Там пишется специальный bpl с парой строк в инициализации - регистрация идентификатора скриптового движка, шаблон обработчика событий, опционально - шаблоны code-tamplate для редактора. Мелочь, но без Delphi 5 не обойтись Если есть желание / возможность, я дам всё необходимое для сборки, и даже код дам. Надо будет только скомпилировать.
Pasha: Alexey Volkov пишет: Вот если бы нативный Харбор умел работать с вариантами (вернее, с IDispatch, завёрнутым в вариант) также, как это делает Дельфи, то на этом и дело в шляпе. Умеет. Это еще клиппер 10 лет назад умел, правда для win16. Собственно харбор унаследовал этот класс (TOleAuto, Win_OleAuto) от соответствующего клипперовского класса. Для Variant выполняется соответствие (get/set) с харборовским item, вызываются методы (Invoke)
Alexey Volkov: Andrey пишет: У меня есть пример работы с ключом HASP HL (фирмы Alladin) через COM xHarbour'a ! Т.е. xHarbour вызывает через COM-объект внешнюю hasp_com_windows.dll Т.е. COM всё-таки есть непосредственно в языке? Это становится интересно. Что касается производительности, то пример с шифрованием не самый показательный. В нашем случае вряд ли было бы оптимальным и логически оправданным интенсивное обращение в цикле из нативного кода к элементам визуальной формы, чтобы заметить такой оверхед, а 0.1 секунда или 0.5 секунды задержки на одиночное действие открытия/закрытия формы имхо не принципиально. Вообще, дурной тон дважды лазить "через две точки". Один раз обратился - сохрани в локальную переменную и пользуйся, не мучай лошадку. Если что-то сильно тормозит, значит что-то сильно не логично.
Alexey Volkov: Pasha пишет: Умеет. Это еще клиппер 10 лет назад умел, правда для win16. Собственно харбор унаследовал этот класс (TOleAuto, Win_OleAuto) от соответствующего клипперовского класса. Для Variant выполняется соответствие (get/set) с харборовским item, вызываются методы (Invoke) Ну тогда интеграция дело техники. Я рекомендую скачать и поизучать вот этот пример, представив, что хост-приложение написано не на Дельфи7, а на Харборе. Если подобная модель взаимодействия устраивает, то готов помочь добровольцам, кто за это возмётся.
Pasha: Alexey Volkov пишет: Т.е. COM всё-таки есть непосредственно в языке? Это становится интересно. Да, это класс TOleAuto. В нем выполняется позднее связывание - в методе OnError как раз через IDispatch вызываются методы COM-сервера. В Delphi наверное делается то же самое. Что касается Variant - так клиппер/харбор - нетипизированный язык, и item харбора - это некий аналог Variant.
Alexey Volkov: Pasha пишет: ...позднее связывание... Вертелось на языке, думал не многие поймут
полная версия страницы