Форум » [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 явно не хватит. То есть, одному мне такой проект не поднять... Поэтому и пишу Паша, Григорий, Петр и другие уважаемые форумчане! Что вы думаете об этом? О возможном своем участии? Жду ваши комменты Спирин Сергей.
Ответов - 121, стр:
1 2 3 4 5 6 7 All
Петр: Мысли имеют право на жизнь В Harbour до сих пор не реализована поддержка Unicode, OOP тоже фактически можно считать не реализованным полностью. После выпуска версии 2.0 (надеюсь до конца этого года) в развитии продукта будет пауза, связанная с введением HB_<TYPE>. Т.е. Harbour, равно как и любой другой более менее большой мультиплатформенный С/С++ проект, будет переписан с использованием "своих" базовых типов (HB_BOOL, HB_BYTE, HB_CHAR и т.д. ), а не стандартных. Как предполагают разработчики при этом возникнут неизбежные ошибки, которые сделают невозможным использование кода с SVN на месяцы, а то и год (ы). В это время, возможно, и будет переписана VM для полноценной поддержки Unicode, изменено API (если кто-то заметил в API в последние месяцы внесено довольно много новых фукций, некоторые помечены как deprecate), изменена версия PCODE, потеряна совместимость с предидущими версиями как на бинарном, так и, частично, на уровне исходников (С code). О планах изменений в xHb не читал, но, думаю, там дела с реализацией изложенного обстоят немного хуже и некоторые вещи вообще не планируются (может и ошибаюсь ). Все это придется учитывать при организации Delphi Run-Time для [x]Harbour. Я думаю - эта работа посложнее FastReport for [x]Harbour и будет требовать не мало времени/сил, нестандартных решений. Если продукт на выходе будет иметь тоже качество, что и Xailer ( о Visual xHarbour помолчу) - лучше не начинать. И так многое не в его пользу - на слабых, старых машинах/ОС я так понял его использовать нельзя будет, dll/bpl куча будет не меньше чем в Alaska xBase++ (у многих клипперщиков какое-то необъяснимое предубеждение против dll), использовать можно будет только для написания новых проектов. Теперь о возможном участии. Почему бы и нет? P.S. Почитал о возможностях Delphi 2010 Enterprise - Подключение к серверам баз данных InterBase, Firebird, Blackfish SQL, MySQL, Microsoft SQL Server, Oracle, DB2, Informix и Sybase - на это у пользователей [x]harbour все чаще возникает спрос.
PSP: Петр пишет: при этом возникнут неизбежные ошибки, которые сделают невозможным использование кода с SVN на месяцы, а то и год (ы) Можно Вас попросить, Петр, сообщить нам об этом заранее? :)
Sergey Spirin: Петр пишет: Мысли имеют право на жизнь Петр пишет: Теперь о возможном участии. Почему бы и нет? Отлично Что ж, тогда можно начинать разговор более конкретный Наверное, самое первое - проект будет коммерческим? Делать здесь OpenSource думаю смысла нет. Дельфи то покупать придется Петр пишет: Если продукт на выходе будет иметь тоже качество, что и Xailer ( о Visual xHarbour помолчу) - лучше не начинать. И так многое не в его пользу - на слабых, старых машинах/ОС я так понял его использовать нельзя будет, dll/bpl куча будет не меньше чем в Alaska xBase++ (у многих клипперщиков какое-то необъяснимое предубеждение против dll), использовать можно будет только для написания новых проектов. Ну как он может иметь тоже качество, что и Xailer? Ведь основная цель проекта - портирование функционала Дельфи. А Дельфи и Xailer - даже и сравнить странно То есть, если в итоге получится Xailer, то дело явно будет в "кривых ручках" исполнителей Про старые машины. Быстродействие дельфийского кода намного выше того, что я когда-либо видел для Xbase. Поэтому, здесь, явно заблуждение. Если мы выберем Delphi2010 с полным Unicode, то мы просто отрежем Win95/98, но чисто технологически отрежем, быстродействие здесь не при чем. Код будет работать хоть на Pentium1. Размеры ран-тайма: В Аляске счас глянул - 20 dll общим размером ~8 mb. Что будет в Delphi run-time? Смотрю Delphi7, 2010 у меня еще нет: rtl70.bpl - 780 KB vcl70.bpl - 1.3 MB vcldb70.bpl - 270 KB Harbour70.bpl - 150 KB + какие-то библиотеки, используемые пользователем Этот набор уже больше чем тот же Xailer по функционалу... В 2010 размер будет побольше, но мне кажется вполне нормальным. Ничего страшного в этом нет, а возможности совсем иные. Петр пишет: Я думаю - эта работа посложнее FastReport for [x]Harbour и будет требовать не мало времени/сил, нестандартных решений. А по Delphi-части я, кстати, так не думаю. Самый сложный класс - THarbourDataSet, который делает Harbour-источники данных родными для Дельфи, написан именно в рамках FRH . Но по Harbour-части, думаю да. У вас, кстати, есть мысли по реализации Harbour-части? То есть, нам нужно реализовать некоторые "оболочки" над Дельфи-классами. Чтобы спокойно компилился типа такого код: Form1 := TForm.Create(nil) Grid1 := TDBGid.Create(Form1) Grid1:Parent := Form1 В результате выполнения такого кода должна "дергаться" моя dll-ка: CreateObject('TForm', nil) CreateObject('TDBGrid', pointer to Form1) SetProperty(pointer to Grid, 'Parent', pointer to Form1) Собственно, если даже только такое реализуем, то получим ... FiveWin, но только более высокого качества Жду комментов
Петр: Sergey Spirin пишет: Наверное, самое первое - проект будет коммерческим? Решать вам, но думаю, что да, а иначе какой смысл Delphi покупать Быстродействие дельфийского кода намного выше того, что я когда-либо видел для Xbase. Поэтому, здесь, явно заблуждение. Никакого заблуждения нет, никто не сравнивает скорость исполнения машинного и pcode. Я в том смысле, что у Delphi 2010 требования XP (или 2000?) , многие разработчики Harbour работают еще с 95/98/NT 4. То есть, нам нужно реализовать некоторые "оболочки" над Дельфи-классами. Естественно было бы написать Harbour-классы обертки. Что-то вроде [pre2] #include "hbclass.ch" PROCEDURE main LOCAL Form1, Grid1 Form1 := TForm():Create() IF hb_isObject( Form1 ) ? __objDerivedFrom( Form1, "TForm" ) ENDIF Grid1 := TDBGrid():Create( Form1 ) IF hb_isObject( Grid1 ) ? __objDerivedFrom( Grid1, "TDBGrid" ) ENDIF //Grid1:SetParent( Form1 ) ? hb_isObject( Grid1:GetParent()) /** */ CLASS TForm PROTECTED: VAR pRealObject INIT Nil EXPORTED: METHOD Create( oOwner ) CONSTRUCTOR DESTRUCTOR Destroy ENDCLASS METHOD Create( ... ) CLASS TForm ::pRealObject := CreateRealObject( "TForm", ... ) ? "TForm created" RETURN Self PROCEDURE Destroy() CLASS TFORM DestroyRealObject( ::pRealObject ) RETURN /** CLASS TDBGrid */ CLASS TDBGRID PROTECTED: VAR pRealObject INIT Nil VAR Parent INIT Nil EXPORTED: METHOD Create( oOwner ) CONSTRUCTOR METHOD SetParent( oOwner ) METHOD GetParent( oOwner ) DESTRUCTOR Destroy ENDCLASS // METHOD Create( oOwner ) CLASS TDBGRID IF hb_IsObject( oOwner ) .AND. __objDerivedFrom( oOwner, "TForm" ) ::pRealObject := CreateRealObject( "TDBGrid", oOwner ) ::Parent := oOwner ? "TDBGrid created" ELSE // ... ENDIF RETURN Self // METHOD SetParent( oOwner ) CLASS TDBGRID IF hb_IsObject( oOwner ) .AND. __objDerivedFrom( oOwner, "TForm" ) ::Parent := oOwner ELSE // ... ENDIF RETURN ::Parent // Self ? // METHOD GetParent( ) CLASS TDBGRID RETURN ::Parent PROCEDURE Destroy() CLASS TDBGRID DestroyRealObject( ::pRealObject ) RETURN /** stub */ FUNCTION CreateRealObject( ... ) RETURN // FUNCTION DestroyRealObject( ... ) RETURN /** typedef void* (__stdcall *CreateObject ) ( char*, void* ); static HMODULE hDll; HB_FUNC( CREATEREALOBJECT ) { // HMODULE hdll = LoadLibrary( "DelphiRT.dll" ); if( hdll ) { CreateObject f = (CreateObject) GetProcAddress( hDll, "CreateDelphiObject" ); if( !f ) { //.. } else { void* r = f( hb_parc(1), hb_parptr( 2 ) ); hb_retptr( r ); } // FreeLibrary( hdll ); } else { //.. } } */[/pre2]
Andrey: Петр пишет: Sergey Spirin пишет: цитата: Наверное, самое первое - проект будет коммерческим? Решать вам, но думаю, что да, а иначе какой смысл Delphi покупать Сделайте сначала НЕ коммерческий ! Для Turbo-Delphi ! Не у всех же есть возможность купить коммерческую лицензию Delphi .... А для желающих и с большими возможностями ВСЕ остальное....
Sergey Spirin: Andrey пишет: Сделайте сначала НЕ коммерческий ! Для Turbo-Delphi ! Не у всех же есть возможность купить коммерческую лицензию Delphi .... Андрей, Delphi покупать нужно будет нам, чтобы такую либу компилировать. А не конечным пользователям. Петр пишет: Я в том смысле, что у Delphi 2010 требования XP (или 2000?) , многие разработчики Harbour работают еще с 95/98/NT 4. Ну, пользователям Delphi то сам и не нужен. IDE Delphi действительно стало тяжеловатым после того как его сделали универсальным для всех языков - С++, C.Net, Delphi.Net (с 2005-го). То есть, часть этого IDE написана на .NET, требует NET Framework и т.д. Но сам производимый код компилятором Delphi так и остается - native Win32, поэтому будет работать на любой Win32 - машине. Петр пишет: Естественно было бы написать Harbour-классы обертки. Что-то вроде ...При таком подходе получается, что нам надо "задублировать" объявления всех (!) классов. Это.. долго будет Нельзя ли как-то поуниверсальней что-то придумать....?
Dima: Sergey Spirin пишет: Delphi покупать нужно будет нам Бери да пользуйся ;) http://torrents.ru/forum/viewtopic.php?t=2147307
Петр: Sergey Spirin пишет: При таком подходе получается, что нам надо "задублировать" объявления всех (!) классов. Это.. долго будет А их, что - много ? Можно написать на Delphi генератор шаблонов. Я в сети видел пример как с помощью RTTI перечисляются методы и свойства TButton. А CREATE CLASS в текстовый файл вывести не составит труда
Sergey Spirin: Dima пишет: Бери да пользуйся ;) http://torrents.ru/forum/viewtopic.php?t=2147307 Ох Круто было бы еще и умудриться продавать то, что компилируется на украденном Дим, я этого очень не люблю.. Конечно, посмотреть можно, но работать на краденном ???? Петр пишет: А их, что - много ? Да не мало будет Конечно, сотни, если не тысячи. Петр пишет: Можно написать на Delphi генератор шаблонов. Я в сети видел пример как с помощью RTTI перечисляются методы и свойства TButton. Это, конечно, можно.... Единственное, счас пока не соображу, как автоматом обойти все классы.... То есть не просто по вертикали, а захватывать все горизонтали Но "результирующая" текстовая портянка - это будет нечто Что-то мне хочется какого-то другого пути... ??? P.S. Пожалуй в ближайшие дни займусь установкой Delphi2010. Все, что я сейчас о ней читаю, убеждает в мысли, что если делать, то делать именно на ней... Будет намного проще.
Dima: Sergey Spirin пишет: Конечно, посмотреть можно Так для этого и дал ссылку , чисто для ознакомления
Sergey Spirin: Dima пишет: Что-то мне хочется какого-то другого пути.. Я как-то смутно припоминаю, что например в MiniGui объeкты/методы разделяются точкой, а не двоеточием. Более того, вроде этих самых объектов там нет вовсе... То есть, производится некоторое "перенапрвление" синтаксиса? Каким образом это достигается? Нельзя ли "зацепиться" каким-то подобным образом? Используя синтаксис... как текстовый параметр для dll?
Петр: Sergey Spirin пишет: Каким образом это достигается? Используя препроцессор. #translate System.Clipboard => RetriveTextFromClipboard() #translate System.Clipboard := <arg> => CopyToClipboard ( <arg> ) #translate System.DesktopWidth => GetDesktopWidth() #translate System.DesktopHeight => GetDesktopHeight() #translate System.DefaultPrinter => GetDefaultPrinter() Т.е. все эти псевдообьекты известны не то что-бы во время исполнения, а до того. Короче - раннее связывание Нельзя ли "зацепиться" каким-то подобным образом? Подобным нет, но вообще - можно. Есть такой трюк для "продвинутых" - Object over Hash и ON ERROR метод.
Sergey Spirin: Петр пишет: Object over Hash и ON ERROR метод. А это что такое? ON ERROR? Это все время падать в обработчик ошибки и такм "разруливать"?
Петр: Sergey Spirin пишет: Это все время падать в обработчик ошибки и такм "разруливать"? Именно так. Ладно, завтра постараюсь сделать несколько примеров - на выбор может что и понравится, с другой стороны хотелось бы знать конкретнее, что могут возвращать методы SetProperty, GetProperty
Петр: Sergey Spirin пишет: ON ERROR? Это все время падать в обработчик ошибки и такм "разруливать"? Этот код был впервые опубликован by Mindaugas Kavaliauskas. Хотя как говорится - идея витала в водухе И многие использовали ERROR HANDLER по своему усмотрению. Ясно, что здесь нет всех необходимых проверок и конечно это всего лишь пример, но в качестве "пищи для ума" - сойдет [pre2]#include "hbclass.ch" PROC MAIN() LOCAL hValue := HashObject() hValue:VAR1 := 123.45 hValue:VAR2 := DATE() ? hValue:VAR1, hValue:VAR2 // Let's create method for HashObject() hValue:PrintVar1 := @HO_PrintVar1() hValue:PrintVar1( 10000 ) RETURN STATIC PROC HO_PrintVar1( nOffset ) ? "I'm a function used as method" ? QSELF():VAR1 + nOffset RETURN CREATE CLASS HashObject VAR __hash INIT {=>} ERROR HANDLER OnError() ENDCLASS METHOD OnError( ... ) CLASS HashObject LOCAL cMessage := __GETMESSAGE(), xValue ? cMessage IF PCOUNT() == 1 .AND. LEFT( cMessage, 1 ) == "_" RETURN QSELF():__hash[ SUBSTR( cMessage, 2 ) ] := HB_PVALUE( 1 ) ENDIF xValue := QSELF():__hash[ cMessage ] IF HB_ISSYMBOL( xValue ) RETURN HB_EXECMSG( xValue, QSELF(), ... ) ENDIF RETURN xValue [/pre2] Осталось скрестить два мои примера и адаптировать к своим нуждам
Sergey Spirin: Петр пишет: Именно так. Ну это как-то уж чересчур, кажется... Петр пишет: хотелось бы знать конкретнее, что могут возвращать методы SetProperty, GetProperty Вообще, в RTTI для свойств определены следующие возможные варианты (не типы) : [pre]TTypeKind = (tkUnknown, tkInteger, tkChar, tkEnumeration, tkFloat, tkString, tkSet, tkClass, tkMethod, tkWChar, tkLString, tkWString, tkVariant, tkArray, tkRecord, tkInterface, tkInt64, tkDynArray); [/pre] В FRH я использую унифицированный тип доступа к свойствам через Variant. Variant - тип данный, который может быть чем угодно (почти): [pre]function GetPropValue(Instance: TObject; const PropName: string; PreferStrings: Boolean = True): Variant; procedure SetPropValue(Instance: TObject; const PropName: string; const Value: Variant); [/pre] В FRH я работаю через харборовские Item-ы. Думаю, что проще так и продолжать. То есть, GetProperty - будет возвращать указатель на Item, а SetProperty принимать его как параметр. В FRH я делаю преобразование ItemToVar и VarToItem, типа: [pre]function ItemToVar(PItem: Pointer): Variant; var ItemType, Len, x: ULong; AStr: string; tmpItem: Pointer; AYear, AMonth, ADay, AHour, AMinute, ASecond, AMilliSecond: Word; begin ItemType := hb_itemType(PItem); case ItemType of HB_IT_NIL : Result := Null; HB_IT_POINTER : Result := Integer(hb_itemGetPtr(PItem)); HB_IT_INTEGER : Result := hb_itemGetNI(PItem); HB_IT_LONG : Result := hb_itemGetNL(PItem); HB_IT_DOUBLE : Result := hb_itemGetND(PItem); HB_IT_DATE : begin AStr := StringOfChar(' ', 8); hb_itemGetDS(PItem, PChar(AStr)); if AStr = StringOfChar(' ', 8) then Result := Null else Result := EncodeDate(StrToInt(Copy (AStr, 1, 4)), StrToInt(Copy(AStr, 5, 2)), StrToInt(Copy(AStr, 7, 2))); end; HB_IT_TIMEFLAG, ........................................ function VarToItem(V: variant; PItem: Pointer = nil): Pointer; var AInt, Diff, x: LongInt; ADouble: Double; AStr: string; ABOOL: BOOL; TmpItem: Pointer; function GetXppDateStr(const ADate: TDateTime): String; var Y, M, D: Word; begin DecodeDate(ADate, Y, M, D); Result := Format('%4d%2d%2d', [Y,M,D]); Result := StringReplace(Result, ' ', '0', [rfReplaceAll]); end; begin case VarType(V) of varEmpty, varNull: begin if Assigned(PItem) then begin hb_itemClear(PItem); Result := PItem; end else Result := hb_itemNew(nil); end; varInteger: begin AInt := V; Result := hb_itemPutNL(PItem, AInt) end; varSingle, varDouble, varCurrency: begin ADouble := V; Result := hb_itemPutND(PItem, ADouble); end; varDate: begin if (StateOfDATETIME = 0) or (Frac(V) = 0) then begin AStr := GetXppDateStr(V); Result := hb_itemPutDS(PItem, PChar(AStr)); end else begin ...................... [/pre] Из этих фрагментов, я думаю, смысл манипулирования понятен. Дополнительного продумывания я думаю потребуют очень популярные для свойств перечислимые типы и множества, например в Delphi: type TBorderIcon = (biSystemMenu, biMinimize, biMaximize, biHelp); TBorderIcons = set of TBorderIcon; property BorderIcons: TBorderIcons read FBorderIcons write SetBorderIcons stored IsForm default [biSystemMenu, biMinimize, biMaximize]; Может быть, только работы через Variant и не хватит, придется дополнять. Но в целом, работа со свойствами это самый непроблемный кусок
Петр: Sergey Spirin пишет: Ну это как-то уж чересчур, кажется... Да нормально - это еще не извращения И по скорости исполнения - вполне сносно, если на OnError на С переписать В FRH я работаю через харборовские Item-ы. Ясно type TBorderIcon = (biSystemMenu, biMinimize, biMaximize, biHelp); TBorderIcons = set of TBorderIcon; property BorderIcons: TBorderIcons read FBorderIcons write SetBorderIcons stored IsForm default [biSystemMenu, biMinimize, biMaximize]; Здесь не совсем ясно - но предполагаю что это в С что-то вроде битовых операций?
Sergey Spirin: Петр пишет: Осталось скрестить два мои примера и адаптировать к своим нуждам Пока, что может получиться из такого скрещивания, для меня не очень понятно Вообще же, можно сформулировать что нам нужно так: - Переменная, которая использовалась для создания Delphi-объекта должна хранить указатель на него. - Этот указатель используется в дальнейшем при обращении к свойствам и методам, деструктору. - И !!! Обработчики событий! ... Похоже переменная просто обязана все-таки быть объектом, иначе, что такое будет Button1Click(Sender) ? Все-таки должно быть ведь что-то типа: CLASS TForm1 FROM TForm EXPORTED: METHOD Button1Click(oSender) ENDCLASS - Именно такое должен увидеть пользователь в будущем Дизайн-Тайме в файле при создании обработчика. - Ну и последующая задача Save/Load dfm(дельфи форм) в ресурсах exe. В ран-тайме при загрузке - восстановление всех обработчиков.
Sergey Spirin: Петр пишет: Здесь не совсем ясно - но предполагаю что это в С что-то вроде битовых операций? Да. Точно. Это просто удобная паскалевская обертка. Просто надо будет подумать как обернуть, но думаю это не сложно, в С++ Builder-е например это же сделано
Петр: Sergey Spirin пишет: Переменная, которая использовалась для создания Delphi-объекта должна хранить указатель на него. Пример №1 - VAR pRealObject Этот указатель используется в дальнейшем при обращении к свойствам и методам, деструктору. Естественно - пример №1 CLASS TForm1 FROM TForm EXPORTED: METHOD Button1Click(oSender) ENDCLASS Все таки - нужно писать классы обертки? Переопределять хотя бы основные методы. Остальное можно через OnError
Петр: Sergey Spirin пишет: Да. Точно. Это просто удобная паскалевская обертка. Просто надо будет подумать как обернуть [x]Harbour поддерживает битовые операции - hb_bit*(). Также нужны соответствующие include файлы #define что-то там
Sergey Spirin: Петр пишет: Все таки - нужно писать классы обертки? Переопределять хотя бы основные методы. Остальное можно через OnError Ну что-то, наверное, типа того. Дизайн-тайм просто этого требует. Обработчики событий не просто же процедурами делать, как-то это "не кудряво"...
Sergey Spirin: Петр пишет: [x]Harbour поддерживает битовые операции - hb_bit*(). Также нужны соответствующие include файлы #define что-то там Да, создание текстов #define-ов, похоже, еще одна работа для Delphi-создателя шаблонов А вообще над множествами (set) в Delphi возможны такие операции как: if biMinimize in BorderIcons then... BorderIcons := BorderIcons + [biMinimize] BorderIcons := BorderIcons- [biMinimize..biMaximize] То есть, проверка на вхождение, объединение, пересечение..
Vlad04: Например, инструмент, написанный Алексеем Волковым - Script Builder. Он и будет иллюстрацией того, что я имею в виду под Delphi Run-Time. Вообще, не разделяю Вашего восторга по поводу творения Волкова. Да он и сам считает проект не законченным. Я пробовал на Script Builder реальные программы писать. Глючный и не предсказуемый инструмент. Идентичные конструкции работают в Делфе - не работают в Script Builderе. И таких примеров было полно. Что получит от этого симбиоза Нарбоар и получит ли неизвестно ( точнее программисты). Но то, что скорость разработки упадёт в несколько раз - это факт.
Sergey Spirin: Vlad04 пишет: Вообще, не разделяю Вашего восторга по поводу творения Волкова. Похоже, Вы явно не уловили обсуждаемую здесь "идею". Уж, конечно, Script Builder тащить в Харбур никому и в голову не приходило. Script Builder использовался как иллюстрация принципиальной портируемости ран-тайма дельфи даже в сильно младших версиях. Vlad04 пишет: Идентичные конструкции работают в Делфе - не работают в Script Builderе. Конструкции языка? Тык Вы использовали в нем DelphiScript? Так это явно, какая-то реализация скрипта от самого Алексея, DelphiScript - какого-то стандарта или общепризнанной реализации в принципе не существует, думаю также как и С++ Script То есть, DelphiScript в SB ну никакого отношения к Delphi run-time не имеет. Да и как можно сравнивать творчество одного человека со всей Дельфи-историей. Думаю, если бы вы использовали бы например JavaScript в SB, то результаты были бы явно лучше, так как производством этого скриптового языка занимается солидная корпорация. Ну, а у нас эту нишу занимает сам [x]Harbour, нам никакие скрипты не нужны, у нас уже есть Тоже наверно небезглючный и с дельфи трудно сравнимый, но все-таки
Sergey Spirin: Sergey Spirin пишет: Что будет в Delphi run-time? Смотрю Delphi7, 2010 у меня еще нет: rtl70.bpl - 780 KB vcl70.bpl - 1.3 MB vcldb70.bpl - 270 KB Harbour70.bpl - 150 KB + какие-то библиотеки, используемые пользователем Смотрю Delphi2010 и, честно говоря, увиденное мне все больше и больше нравиться Размер ран-тайма действительно ожидаемо увеличился, но явно не катастрофически: rtl140 - 1,7 MB vcl140 - 2,4 MB dbrtl140 - 0,4 MB vclx140 - 0,25 MB vcldb140 - 0,3 MB Ну, возможно еще что-то потребуется, это надо смотреть. ---- Остальное по желанию, например ADO adortl140 - 176 KB и т.д. ---------- Теперь о нововведениях в RTTI. Действительно, терерь можно говорить о полном Reflection. Кстати, новый демо-пример с этими возможностями так и называется: "Reflection Browser". В нем как раз демонстрируется полная энумерация всего прямо от корня - TObject (вопрос про горизонтальный обход в потенциальном шаблонщике ). Пример бросил сюда, можно посмотреть: http://www.paritetsoft.ru/downloads/rtti_browser.rar Можно порассуждать абстрактно . А какие еще есть солидные системы с полным рефлекшн, которыми мы могли бы воспользоваться? В общем то, на ум приходит еще только 2 варианта - .NET и Java... Яву, как вариант, я думаю можно отмести сразу. Клипперисты "склонны" к созданию клиентских приложений, а в Яве это тупиковая ветка (свинги). Вся мощь и красота Явы в web-приложениях и web-технологиях, что все-таки далековато от классического клипперного представления о мире И как это "скрестить" не ясно. .NET... Не знаю, насколько возможно полноценное использование .NET из не-NET приложения.. Предположим, что возможно и не сложнее чем использовать дельфи ран-тайм... В этом случае .NET выглядит предпочтительней. .NET еще больше и солидней чем Дельфи. .NET развивается бешенными темпами (в жесткой схватке с Явой). .NET фактически уже часть Windows, поэтому не требует доп установок и т.д. На сегодняшних, а тем более завтрашних машинах разница в производительности с native-кодом уже не так важна, а безопасность кода на десять порядков выше, чем у native-кода... Но Есть один забавный нюанс Все языки под .NET - это всего лишь синтаксические оболочки над .NET-машиной Например, сейчас Delphi.Net (Prizm) просто устананавливается как плагин в Visual Studio и все, поехали! А идеологию подходов диктует именно .NET-машина, сводя разницу языков лишь к лексическим нюансам В контексте этого, Harbour(Clipper) со своим весьма специфичными взглядами на устройство БД и работы с БД, выглядит в связке с .NET даже как-то диковато Взгляды специфичны, конечно, в контексте сегодняшнего дня, а не 20-летней давности... Отсюда, думаю, что все-таки наболее органичное решение - это native Win32(64) ран-тайм Все я это к тому, что если втягиваться в такой проект, то хочется быть уверенным в правильности направления.. Поэтому, поправьте, если что-то в изложении не так. Ну и еще вопрос про жизнесобность Харбура. Не получится ли это все "мертвому припарка"? Ну или не мертвому.., а "припарка последним производителям софта для учета домофонов"? --------------- И последнее, в лоб либа для фаст под D2010 не работает, причина - Unicode. То есть, код весь придется проходить и адаптировать. Петр, в связи с этим вопрос, при обработке Harbour API уже как-то закладываться на возможный Unicode, либо пока бог с ним? Что посоветуете?
Andrey: Sergey Spirin пишет: "припарка последним производителям софта для учета домофонов"? Причем тут ЭТО ? Берите большие системы, типа БЭСТ 4+ или 5... Да и другие есть наверно... Сюда ведь не я один заглядываю ?
Sergey Spirin: Andrey пишет: Причем тут ЭТО ? Андрей, ну это же шуточная аллегория-обобщение Кстати, гляньте в GUI тему "Глюки при прорисовке формы...", там тоже что-то про домофоны. Поэтому аллегория родилась сама собой Andrey пишет: Берите большие системы, типа БЭСТ 4+ или 5... Да и другие есть наверно... Ох , Андрей, не напоминайте мне про мучения и конвульсии старых производителей бухсофта. Я сам из "отмучившихся" и эту проблематику хорошо знаю. Это тоже домофонщики
Петр: Sergey Spirin пишет: Пример бросил сюда, можно посмотреть Не посмотрел - у меня почему-то выскакивает "Поврежден заголовок", но это не так важно. какие еще есть солидные системы с полным рефлекшн В том или ином виде reflection поддерживает куча языков, в т.ч. [x]Harbour. Не всем нужен полный reflection, да и предназначен он пока для задач специфических. А потом, что считать "солидной системой" в 2010 году? ИМХО эта система должна быть ориентирована на разные платформы (архитектура процессора + ОС) в т.ч. и 64bit, Unicode (и не только в варианте от MS), обязательно иметь встроенный garbage collector, поддерживать тот же reflection, иметь удобную RAD среду (Visual Studio ) и т.д. и т.п. (позвольте не оглашать весь список ). Но у каждого свое ИМХО и каждый найдет в этом перечне те вещи, которые нужны в первую очередь, и те вещи на которые даже не обратит внимание. Так что оставим эти разговоры для специализированных форумов - там всегда найдется желающий начать "священную войну", типа я vs all world. Sergey Spirin пишет: Не знаю, насколько возможно полноценное использование .NET из не-NET приложения.. Предположим, что возможно и не сложнее чем использовать дельфи ран-тайм... Можно, вовсе не сложно. На сколько полноценно - не знаю. Примеры были где-то на codeproject. NET развивается бешенными темпами Да и бог с ним, C# на компе установлен , но вообще то MS обещала не интеграцию Net в ОС, а ОС на базе Net, но пока что ни Win 7, ни следующая обьявленная ОС таковыми не будут. А то что каждая последующая версия Net частично несовместима с предидущей - это факт. Так что поддерживаю вашу мысль, что пока таки да - наболее органичное решение native Win32(64) ран-тайм. Тем более что проект Clipper over .Net уже вроде существует - Vulcan.Net. Sergey Spirin пишет: Ну и еще вопрос про жизнесобность Харбура. Вы знаете в котором году умер Clipper? Многие скажут, что он не умирал вообще. Спорить не буду, но последние обновления были выпущены где-то в 1996 году (не ошибся?). Даже если бы сейчас разработка Harbour прекратилась (чего не наблюдается) пользоваться ним будут еще не меньше времени. при обработке Harbour API уже как-то закладываться на возможный Unicode, либо пока бог с ним? Ну знаете, Delphi вон тоже совсем недавно разжился на Unicode Ну это шутка. Реально тут вопрос больше в совместимости Harbour и xHarbour, и насколько быстро будут расходиться их API, внутреннее обустройство, пути развития. Сделайте среди своих пользователей маркетинговое исследование и тогда принимайте решение на какой сегмент ориентироваться (хотя понятно, что желательно не потерять ни одного, но и поддерживать 3 продукта вместо 2 тоже, наверное, не хочется.). Думаю время у вас пока есть.
Sergey Spirin: Петр пишет: у меня почему-то выскакивает "Поврежден заголовок", Да, у меня из дома тоже. Что-то ftp-доступ к хостингу стал подглючивать в последнее время, завтра (с работы) перезалью заново. Петр пишет: В том или ином виде reflection поддерживает куча языков, в т.ч. [x]Harbour. Ну это то свойство архитектуры, что называется "по-задумке" Для Дельфи же это необычно, так как это native код. Петр пишет: А потом, что считать "солидной системой" в 2010 году?..... Так что поддерживаю вашу мысль, что пока таки да - наболее органичное решение native Win32(64) ран-тайм. Ok. Петр пишет: Ну знаете, Delphi вон тоже совсем недавно разжился на Unicode.... Хорошо. О Харбор-unicode пока не думаю. Будет это существенно, к этому вернемся. На следующей неделе постараюсь сделать некий рабочий прототип. Тогда можно будет "пощупать" и обсудить конкретику архитектуру Harbour-части. P.S. Паша, а что-то Вы не подключаетесь к обсуждению? Насколько я помню, у Вас же был какой-то Дельфи-опыт?
Pasha: Sergey Spirin пишет: P.S. Паша, а что-то Вы не подключаетесь к обсуждению? Насколько я помню, у Вас же был какой-то Дельфи-опыт? Это было очень уж давно. Последний раз я программировал на Дельфи году в 2001-м, а запускал - году в 2003-м. Уже и подзабыл его. На чем работаешь - то и знаешь. Когда писал на паскале - подзабыл клиппер, а теперь наоборот.
Sergey Spirin: Sergey Spirin пишет: Пример бросил сюда, можно посмотреть: http://www.paritetsoft.ru/downloads/rtti_browser.rar Перевыложил и проверил, можно смотреть.
Sergey Spirin: Хочу сказать, что не забыл о данной теме. К сожалению, все сложилось так, что я физически не мог заниматься DRT for [x]Harbour. Но планирую, что к апрелю время у меня должно появиться и я обязательно к этому вернусь.
Sergey Spirin: Вот все-таки думаю, что очень плохо, что у меня нет напарника-дельфиста. При его наличии, дело бы могло двигаться и быстрее, а главное стабильней. Я, конечно, понимаю, что в среде клипперистов-харбуристов "приличного" дельфиста мне найти почти невозможно.... Но вот я думаю - я ведь могу и научить (!). Я - опытный дельфист, к тому же у меня есть опыт преподавания программирования в университете. Я ведь такого потенциального партнера могу и в OOП ввести, и с указателями работать научить, помочь всю мощь VCL понять и т.п., то есть, прояснить все то, с чем обычно у клипперистов проблемы... Никто не хочет освоить еще один язык и поучаствовать в приличном проекте? Проект то гибридный, отрыва от Харбура не будет. Жду отклика
Andrey: Sergey Spirin пишет: Никто не хочет освоить еще один язык и поучаствовать в приличном проекте? Можно было бы поучаствовать... Только я Дельфи могу только устанавливать.... И все....
Dima: Andrey пишет: Только я Дельфи могу только устанавливать.... И все.... Тогда будешь таджиком - дворником
Andrey: Dima пишет: таджиком - дворником Ну если не устраивает... То сам включайся в работу... Будешь китайцем-подмастерьем ....
Sergey Spirin: Andrey пишет: Можно было бы поучаствовать... Только я Дельфи могу только устанавливать.... И все.... Ну, совсем с нуля, это, конечно, чересчур для серьезного проекта... Увы, к сожалению..
krutoff: Может поляки смогли бы в этом помочь? http: //www. otc.pl/
Наиль: Идею можно реализовать. Как это делается, можно подсмотреть у самого делфи. При добавлении ActiveX в проекты делфи конвертирует информацию об объектах из dll и ocx в pas, на основе аналога RTTI. По аналогии можно сделать конвертирование RTTI в PRG. Причем делать это нужно на основе конвертирования VCL в ActiveX, при котором производятся практически все необходимые преобразования, останется только доработать напильником. Delphi знаю хорошо, но вот с клипером-харбором (с кораблем и гаванью) только начинаю знакомиться. К сожалению, использую TurboDelphi в котором поддержка ActiveX отсутствует. К следующему воскресению тоже постараюсь состряпать прототип.
Sergey Spirin: Наиль пишет: Delphi знаю хорошо, но вот с клипером-харбором (с кораблем и гаванью) только начинаю знакомиться. Привет! Вот здорово! Наконец-то я дождался дельфиста в этом "сумрачном" мире. То, что клиппер-харбор еще не знаете, это не страшно, тут ничего особо сложного нет, овладеете по ходу. Кстати, а какими судьбами в клиппер-харбор заносит? Обычно, здесь люди находятся по чисто историческим причинам только. По версии дельфей. "Перегнать" декларации классов по RTTI в харбор декларации в общем-то можно в любой версии дельфей. Но в любой версии, кроме 2010, все ограничится только секцией piblished. Нам же, для полноценной работы, нужно вытаскивать и полноценно управлять еще хотя бы всем из public. То есть, пришлось бы что-то додумывать, варианты конечно есть, но в 2010 это уже дают "на блюдечке"... Отсюда и мой интерес именно к 2010. Использовать Турбо в виду бесплатности заманчиво, но доп. писанины будет много, как бы не оказалось это "бесплатным сыром" Поэтому, если делать будем, то надо все-таки сразу определиться с версией дельфей, ну и подумать о переспективе покупки (у меня лицензионные только тройка и семерка). Ну а дальше можно будет распределить направления. Очень надеюсь, что совсем скоро у меня появится достаточно времени для этого проекта. Думаю, что моя первая задача - это адаптация и расширение, написанного для фаста движка на 2010. Вы, действительно, могли бы заняться "перегонкой классов", ну а по харбор конкретике, то есть, во что перегонять, как движок "цеплять" и т.д. заведовал бы Петр. Вроде все "логично" получается Основная проблема в таких проектах, конечно, время. Жду обсуждения
Наиль: Существует два (пока два) варианта решения задачи: сильнодинамический и слабодинамический. Предложенный выше вариант сильнодинамический. Суть решения в том, что нужно создать библиотеку-обёртку вокруг компонентов Delphi. Это позволит динамически создавать из харбора окна-формы любой сложности. Учитывая размер конфетки под обёрткой процесс может оказаться бесконечным и с неясной перспективой. Поэтому я пошел по второму пути. Попробую создать некий конструктор, который позволит создавать форму и генерировать соответствующий ей объектный код на Харборе. Задача сгенерированного кода обеспечить интерфейс для событий клавиатуры и мыши (в начальном варианте) и изменения свойств объектов-компонентов. Конструктор будет работать в отсутствии Delphi используя лишь bpl-файлы. При слабодинамическом решении компоненты нельзя не удалить, не добавить, можно лишь изменить свойства, например скрыть.
Andrey: Наиль пишет: будет работать в отсутствии Delphi используя лишь bpl-файлы. Позвольте вопрос ? А готовое приложение с чем будет ? В смысле: со своим EXE-ником и DLL-ки Delphi будут еще какие-то файлы ? Это не есть хорошо.... Мне нравится Harbour за его компактность !!!
Sergey Spirin: Наиль пишет: Существует два (пока два) варианта решения задачи: сильнодинамический и слабодинамический. Предложенный выше вариант сильнодинамический....... Привет, Наиль. Вообще говоря, понять однозначно то, что вы сказали (или хотели сказать), трудновато Думаю, что нужно определиться с терминологией, конечными целями и вытекающими из них задачами более конкретно. Итак, конечной целью проекта является полное портирование VCL в Харбор приложение. Под этим под этим подразумевается полностью прозрачный доступ "в обе стороны". Как первый шаг, реализация без IDE (наподобие FiveWin), как идеал создание или портирование IDE. Реализация в Delphi. В сторону Харбор->VCL, все на чистом RTTI от Delphi2010. "Размер конфетки" "никакой рояли не играет", так как доступ полностью унифицирован. То есть, это десяток-полтора функций типа Get/SetProperty, CallMethod, Get/SetField и т.д. В сторону VCL->Харбор, использование отработанной на Фасте технологии использования HB API. HarbourDataSet для прямого доступа к нативным Харбор-источникам данных, и т.д.. По модулям. Это одна dll, содержащая вышеописанное взаимодействие в обе стороны, компилируется с пакетами, откуда, собственно, и будет брать VCL-функционал. Думаю, что где-то три пакета можно грузить сразу статично (rtl, vcl, vcldb), остальные динамически по вызову из Харбор-приложения. Харбор-сторона. Вот здесь как раз варианты есть. Можно в конце концов ограничится только импортом функций из dll и писать что-то типа: SomeVar := CallConstructor("TForm", "Create") SetProperty(SomeVar, "Width", 800) CallMethod(SomeVar, "ShowModal") ...... Но это уж больно "как-то не то" . К тому же, исходя из переспективы IDE и дизайн-тайма такой "процедурный подход не катит". Отсюда идея сделать автоматическую декларацию классов, сделать точную копию дерева наследования и т.д. Это и есть "перегонка", при которой каждый метод "знает", что ему вызывать и т.д.. Тогда код на Харборе примет более нормальный вид: MyForm := TForm:Create(nil) MyForm:Width := 80 MyForm:ShowModal Так как классов у нас очень немало, то такая перегонка должна быть полностью автоматизирована и продумана по объему. Ну вот, собственно, пока все мысли по этому поводу
Vlad04: Еще раз о целях. 1) Вряд ли Делфи нуждается в Нарборе. Там уже столько наворочено 2) У Нарбора ( как программист, занимающий прикладным программированием ) вижу ВСЕГО два недостатка: - отсутствие удобной отлаженной IDE для работы в графическом режиме . Но просто повторение Делфи - это, вообщем, шаг назад. Использование DataSEt совсем не производительный метод. По различным оценкам, если сравнивать Делфи, VBasic, Access ( это все системы быстрой разработки приложений) скорость разработки на Access раз в 5 выше, чем у первых двух.Здесь речь идет о принципах. - проддержка работы с SQL серверами , ставшими стандартом де-факто.
Sergey Spirin: Vlad04 пишет: Еще раз о целях. Влад, я очень ценю ваше желание пообщаться Но читать ваши суждения, честно говоря труд нелегкий Может, вам лучше не утверждать что-то, а просто спрашивать, если что-то непонятно? Vlad04 пишет: 1) Вряд ли Делфи нуждается в Нарборе Гм..х....г... А кто-то говорил, что нуждается? Кто? Влад, речь об использовании Delphi-функционала в Харбор приложении. Vlad04 пишет: Но просто повторение Делфи - это, вообщем, шаг назад. Чего-чего? От чего это шаг назад? От MiniGUI? (Григорий извините..) Vlad04 пишет: Использование DataSEt совсем не производительный метод. Это вообще читается примерно как: "Фармацевтический смысл туманности Андромеды" Что называется, хоть стой, хоть падай. Vlad04 пишет: скорость разработки на Access раз в 5 выше От такого сравнения, у меня уже просто "мозг клинит" Даже, что сказать, непонятно... Немая сцена с открытым ртом Влад! Пишите, повеселите еще!
Vlad04: Чего-чего? От чего это шаг назад? От MiniGUI? Нет , конечно. Я и пишу об одном из недостатков Харбор - отсутствие удобной отлаженной IDE для работы в графическом режиме. Использование DataSEt совсем не производительный метод Это вообще читается примерно как: "Фармацевтический смысл туманности Андромеды" Да, при разработке метод Select, используемый в Харбор, намного производительней DAtaset. Вы попробуйте создать вычисляемое поле или подставляемое поле в Делфи и Харборе и сравните потраченное время. скорость разработки на Access раз в 5 выше Увы, так оно и есть. Некоторые фирмы в Access проверяют методологию и подход при решении задачи. А потом уже переписывают программу на другой платформе. Вообщем, чего чего, а сарказма у Вас на всех хватит.
Sergey Spirin: Привет, Влад! Vlad04 пишет: Чего-чего? От чего это шаг назад? От MiniGUI? Нет , конечно. Я и пишу об одном из..... Ну так, от чего это шаг назад то? Vlad04 пишет: Да, при разработке метод Select, используемый в Харбор, намного производительней DAtaset. Я уж было напрягся даже Потом вспомнил, что в HarbourDataSet, вызов "метода Select, используемого в Харбор" по коду встречается десятки раз, и успокоился, значит у меня производительный DataSet Влад, что такое для вас DataSet? Vlad04 пишет: Увы, так оно и есть. Некоторые фирмы в Access проверяют методологию и подход при решении задачи. А потом уже переписывают программу на другой платформе. Влад, как бы вам объяснить, что вы сравниваете несравнимое - узкоспециализированное средство, включенное в MSOffice и универсальный, достаточно низкоуровневый язык программирования .... Вы случайно почту не "The Bat"-ом читаете? А в аське не "QIP"-ом сидите? Или может файлы копируете "Windows Commander"-ом? А может с разными базами работали когда-нибудь через IBExpert, PL/SQL-Developer, SQL-Navigator....? Это все программы, написанные на Delphi... Есть у меня какое-то смутное впечатление, что на Accsess QIP или PL/SQL-Developer быстро не напишешь Vlad04 пишет: Вообщем, чего чего, а сарказма у Вас на всех хватит. Надеюсь, сарказма здорового и необидного
Andrey: Vlad04 пишет: Некоторые фирмы в Access проверяют методологию и подход при решении задачи. А потом уже переписывают программу на другой платформе. Подробней пожалуйста ! С фактами ! Мне тоже интересно узнать, кто так делает ! 2 раза писать систему ? Круто деньгами сорят ...
Vlad04: Не в обиду пишется. Я в своем опусе хотел выделить ЛУЧШИЕ стороны, имеющиеся в некоторых системах , а не системы в целом. Вы невнимательны. И про Select написано - при разработке. Т.е программист в Харбор оперируя RDD и Select пишет и вносит в программы изменения быстрее , чем это делается с DAtaSourse и DataSet в Делфи. Да и удобнее так (мне точно). Речь не идет о производительности готовых систем. Впрочем я тестировал Харбор , клиппер и Делфи на примерно одинаковых задачах. Делфи на Apollo приближается к Харбор и клипперу , но отстает все равно. И хотя Access в целом мне не нравится, но там есть очень удобные моменты. Возможно что-то подобное есть в Делфи2010, я пока использую Делфи 7.
Andrey: Vlad04 пишет: Впрочем я тестировал Харбор , клиппер и Делфи на примерно одинаковых задачах. Давай пример одинаковый сделаем ! Очень хочется сравнить скорости !!!
Dima: Andrey пишет: Очень хочется сравнить скорости !!! Еще бы хотелось сравнить 1с
Vlad04: Что мы отвлекаемся. Главное, сформулировать задачу для Сергея. А сила 1с в другом - в организации данных. В простом пересчете она , конечно, проиграет.
Sergey Spirin: Привет. Vlad04 пишет: Я в своем опусе хотел выделить ЛУЧШИЕ стороны, имеющиеся в некоторых системах , а не системы в целом. Вы невнимательны. Как невнимателен? Да я до сих пор жду ответа про "шагом назад от чего?" было бы повторение Дельфи для Харбура. Ну и про ЛУЧШИЕ стороны тоже кое что теперь знаю, а именно: - В Accsess есть тоже что-то хорошее. - Писать вот так: SELECT MYTABLE GoTop() Это намного удобнее, чем писать вот так: MyTable.First; Понял. Принял к сведению. Vlad04 пишет: И про Select написано - при разработке. Т.е программист в Харбор оперируя RDD и Select пишет и вносит в программы изменения быстрее , чем это делается с DAtaSourse и DataSet в Делфи. Да и удобнее так (мне точно). Последняя ремарка, я думаю, наиболее точно отражает положение вещей У меня коллега-клипперист, что называется "стоявший у истоков", до последнего "упирался", лишь бы кодировать в своем любимом Лексиконе. Сейчас правда перешел на.... редактор Far-а Vlad04 пишет: прочем я тестировал Харбор , клиппер и Делфи на примерно одинаковых задачах. Делфи на Apollo приближается к Харбор и клипперу , но отстает все равно. Слово Apollo я "слышал", но никогда не видел. Но, просто формализуем положение вещей объективной реальности: - Native-код всегда будет работать быстрее, чем P-код. - Нет ничего такого в реализации Клиппер-Харбура, чего нельзя было бы сделать на Дельфи. Исходя из этих аксиом, и если Apollo действительно работает медленнее, нужно просто посмотреть в глаза разработчикам этого Apollo и спросить: "Что ж вы голубы делаете? Из какого места у вас руки растут"? Кстати, вас наверное интересует работа только с dbf-файлами? В дельфи я с dbf уже и не помню, когда последний раз работал... давно. Но когда еще работал, то использовал Halcyon. Симпатичная такая библиотечка, за 100 баксов шла с полными исходниками. И с производительностью, насколько я помню, у нее проблем не было, то есть она была явно выше, чем у Клиппер-Харбура. P.S. C dbf я, действительно, уже "100 лет" не работаю. Но тут мне Oracle не так давно, выдал такую ошибку: ORA-XXX Не могу открыть dbf-файл. У меня чуть челюсть об стол не стукнула
Vlad04: Не будем препираться, кто что сказал. Вперед, Сергей, твори. Будем смотреть , критиковать.
Sergey Spirin: Vlad04 пишет: Не будем препираться, кто что сказал. Сильно не люблю людей, не отвечающих за свои слова... Поэтому, просьба вам, не "проявляться" в моих темах. Vlad04 пишет: Вперед, Сергей, твори. Будем смотреть , критиковать. В дилетанских "речах" я не нуждаюсь, к тому же, если продукт состоится, то он будет явно не дешев, явно не для вас...
Proxy: Наиль пишет (11.04.10 23:52.): К следующему воскресению тоже постараюсь состряпать прототип. Воскресенье заканчивается, а мы всё ждём! И ... ?
Наиль: Proxy пишет: Воскресенье заканчивается, а мы всё ждём! И ... ? Извините, что не оправдал ваших ожиданий. Авральная неделя, пришлось работать без выходных. На прототип времени не осталось. Следующая неделя обещает быть такой же, так что даже не знаю, когда смогу что-то показать.
Proxy: Наиль пишет: Извините, что не оправдал ваших ожиданий. Авральная неделя, пришлось работать без выходных. На прототип времени не осталось. Следующая неделя обещает быть такой же, так что даже не знаю, когда смогу что-то показать. Наверное после "Курса молодого бойца" Но, как бы то ни было, всё равно ждём
Наиль: Proxy пишет: Наверное после "Курса молодого бойца" Но, как бы то ни было, всё равно ждём Так как времени писать программу нет, то я пишу письма. Одно из них я направил Алексею Волкову с предложением открыть исходные коды программы Script Builder, которую он забросил много лет назад. Вот что он пишет в ответ: Здравствуйте, Наиль. Извиняюсь за задержку с ответом, я тут застрял в аэропорту, в интернете появляюсь не регулярно. Странное что-то происходит, вы уже третий человек, кто интересуется Билдером за последний месяц, и это после нескольких лет затишья. Интересы у всех интересующихся диаметрально разные - один предлагает сделать "облачную" версию на дотнете, второй предлагает допиливать паскаль скрипт как есть, вы как я понял, просто хотите прикрутить клиппер. Открыть исходники или передать разработку был бы выход, но от этого шага меня удерживает одна "небольшая" проблема - движок-то проприетарный, и исключительные права на него принадлежат некой австралийской фирме Dream Company (они ещё живы?). И даже автор движка не думаю что в силах что-то изменить. Я как основной разработчик среды и контрибьютор движка имею исходники (свой форк) и лицензию на исходники, но я не правообладатель. Я не имею право раскрывать исходники движка. А это главный тормоз. Попробуйте поговорить с Сергеем Костинским, может он лучше знает, кому сейчас принадлежат права на движок. Если они согласны раскрыть свои исходники под GPL или LGPL, то и я не буду возражать против раскрытия своих. Насколько я понял по сайту http://www.dreamcompany.com/ фирма Dream Company стала частью фирмы Altium. Т.е. продолжает использовать и продавать тот код, как часть других продуктов. Так что здесь облом.
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 пишет: ...позднее связывание... Вертелось на языке, думал не многие поймут
Andrey: Alexey Volkov пишет: Я рекомендую скачать и поизучать вот этот пример, Выдает ошибку: "Script Builder not installer" !
Петр: К сожалению, я не знаком с Клипером-Харбором и не могу оценить красоту Я заинтересовался Delphi Run-Time для [x]Harbour (DRT4HB) потому, что из всего Харбора знаю лишь Delphi. Очень точно характеризует обсуждение темы в последние дни
Alexey Volkov: Andrey пишет: "Script Builder not installer" Надо установить движок или полную среду, из первого поста. Ваш К.О.
Sergey Spirin: Alexey Volkov пишет: А каковы преимущества компилятора? Парадоксально, но интепретатор интегрировать проще, и дёргаться-то будут всё те же методы через RTTI. Преимущества ActiveScript - возможность настраивания бизнес-логики на ходу. Плюс такие вкусности, как о отладка. Производительность хуже? Не будем же мы сравнивать производительность пустого обработчика Button1Click в скрипте с пустым нативным обработчиком? Даже на Pentium1 разницы не будет заметно. Встраивать VCL через RTTI, но в компилированный код обвязки - всё равно что тратить на водку, но экономить на спичках )) Ну это ИМХО. Здесь, боюсь, Алексей, Вы "со своим уставом в чужой монастырь" Кроме того, что подобное явно противоречит представлениям сообщества, но это еще и вряд ли возможно технически. Похоже Вы не знаете, например, какой компилятор использует Харбор для получения исполняемого модуля, это Borland C, Pellle С, C от Microsoft и т.д. Компилятор Харбор называется таковым скорее по привычке, это "лексический анализатор" переводящий Клиппер синтаксис в PCode-"болванку" для С компилятора. Просто по коду можно использовать С, что часто и делается.. и.т.д. Вы думаете, все это можно повторить скриптом? Alexey Volkov пишет: И моя сегодняшняя работа никаким местом с Дельфи не связана. Просто неожиданно вдруг совершенно разные люди, с разными задачами проявили интерес к проекту. Вплоть до предложений выкупить права. Ну а в свете последних изменений в Дельфи, мне кажется, хоронить проект или отказываться от него пока рано. Если перевести на компонентную базу 10ки, то он ещё столько же проживёт, пусть в закрытом виде, но кому оно интересно, что там внутри, если оно не будет глючить и будет дружить со сторонними компонентами? Хоронить, конечно, не надо. Скриптинг вещь востребованная. Если переведете на 2010, будет очень солидно. Но нельзя ли сделать ветку и не для скриптовых языков тогда? В принципе, это даже несколько проще должно быть? Нужно же только IDE, "дизайнер форм", и поддержка отладчика... Никакого ран-тайм в "скриптовом смысле". Вот это бы было бы очень взаимно интересно..
Sergey Spirin: Петр пишет: цитата: К сожалению, я не знаком с Клипером-Харбором и не могу оценить красоту цитата: Я заинтересовался Delphi Run-Time для [x]Harbour (DRT4HB) потому, что из всего Харбора знаю лишь Delphi. Очень точно характеризует обсуждение темы в последние дни Да и еще перл: Наиль пишет: Для Delphi сообщества это может быть интересно потому, что взамен смеси двух языков Pascal+SQL для проектирования баз данных можно получить один язык - Харбор Но, Алексея, давайте "простим" (пока ) за нежелание хоть что-то узнать о предметной области
Sergey Spirin: Pasha пишет: в методе OnError как раз через IDispatch вызываются методы COM-сервера. Ага!!! Петр был не оригинален! P.S. Сегодня под вечер - хорошее настроение
Alexey Volkov: Sergey Spirin пишет: Здесь, боюсь, Алексей, Вы "со своим уставом в чужой монастырь" Кроме того, что подобное явно противоречит представлениям сообщества, но это еще и вряд ли возможно технически. Похоже Вы не знаете, например, какой компилятор использует Харбор для получения исполняемого модуля, это Borland C, Pellle С, C от Microsoft и т.д. Компилятор Харбор называется таковым скорее по привычке, это "лексический анализатор" переводящий Клиппер синтаксис в PCode-"болванку" для С компилятора. Просто по коду можно использовать С, что часто и делается.. и.т.д. Вы думаете, все это можно повторить скриптом? С подобным "компилятором" я в данный момент работаю, только на PowerPC. точно так же трансляция в си, возможность правки болванки, компиляция в нативный код. Но там ресурсы сильно ограничены. Не думал, что на PC тоже актуальна борьба за такты. Представлениям противоречит, но технически возможно, если IDispatch поддерживается. Повторить в скрипте можно всё, вопрос в задержках. Имхо, требования к задержкам на десктопе вообще и в ГУИ в частности несколько мягче, чем в системах реального времени. Впрочем, вам виднее. К тому же я вовсе не говорю о полной замене нативного кода скриптом, а лишь об обвязке (обработка событий, настраиваемая бизнес-логика), некритичной к задержкам. Sergey Spirin пишет: Хоронить, конечно, не надо. Скриптинг вещь востребованная. Если переведете на 2010, будет очень солидно. Но нельзя ли сделать ветку и не для скриптовых языков тогда? В принципе, это даже несколько проще должно быть? Нужно же только IDE, "дизайнер форм", и поддержка отладчика... Никакого ран-тайм в "скриптовом смысле". Вот это бы было бы очень взаимно интересно.. Не сказал бы что проще. скорее сложнее. Ведь на выходе дизайнера вам нужно будет сгенерить не dfm, а что-то своё? в синтаксисе клиппера, конструирующее форму, с возможностью выборочной ручной правки, по типу SWING в JAVA, транслирующееся далее в pcode, потом в си, и тут мы теряем все преимущества разделения мух и котлет, ибо всё равно "позднее связывание". Я готов поспорить, что скорость создания формы из dfm всяко больше, чем создание её динамически из транслированного кода. Преимущества такого рантайма не очевидны, кроме возможности править исходник по F4, и собирать один екзешник. Возьмите для начала Generic IDispatch Proxy Classes, поиграйтесь с VCL объектами вручную Харборовском коде. Я очень сомневаюсь, что работать они будут быстрее, чем в скриптовом приложении. Альтернативы конечно есть, но вы же не будете всерьёз рассматривать "раннее связывание"?
Sergey Spirin: Alexey Volkov пишет: Представлениям противоречит, но технически возможно, если IDispatch поддерживается. Повторить в скрипте можно всё Повторить... Теоретически, наверно, только Тут, фактически сразу 2 языка, один из которых С. То есть, указатели, структуры, препроцессор, ассемблерные и машинокодные вставки наконец Да и Клиппер-Харбор язык немолодой и накопил оччень значительное количество своих нетривиальных синтаксических конструкций Alexey Volkov пишет: Имхо, требования к задержкам на десктопе вообще и ГУИ в частности несколько мягче, чем в системах реального времени. Гм... Грид с юзерской отрисовкой в событии OnPaint? Скриптом... Alexey Volkov пишет: а лишь об обвязке (обработка событий, настраиваемая бизнес-логика), Насчет обработки событий не очень понимаю, что вы имеете в виду. А вот "настраиваемая бизнес-логика" - это безусловно востребованная скриптовая ниша. Кстати говоря, у вас SB сделан так, что генерит целиком скриптовое приложение. У меня какое-то ощущение, что более востребован скрипт как встраиваемае подсистема, а не "целиковое решение". Alexey Volkov пишет: Не сказал бы что проще. скорее сложнее. Ведь на выходе дизайнера вам нужно будет сгенерить не dfm, а что-то своё? Зачем? dfm конечно будет, зачем здесь что-то придумывать? "в синтаксисе клиппера" будет клипперный класс с конструктором в 2 строки вызова "дельфийской стороны". Первая создаст объект формы и загрузит dfm, вторая расставит обработчики событий. В чем проблема?
Alexey Volkov: Sergey Spirin пишет: Повторить... Теоретически, наверно, только Тут, фактически сразу 2 языка, один из которых С. То есть, указатели, структуры, препроцессор, ассемблерные и машинокодные вставки наконец Добавится третий, "managed", или "код обвязки", как мост между визуальной частью и первыми двумя. Sergey Spirin пишет: Гм... Грид с юзерской отрисовкой в событии OnPaint? Скриптом... Но Грид-то и вся иерархия под ним от этого не перестанет быть нативным win32 кодом на Паскале? Скриптовый только обработчик, который сегодня может вызывать одну нативную процедуру, а завтра другую, а послезавтра обе, и ещё "немножечко шить", и это без необходимости перекомпиляции и наличия полновесного средства разработки на объекте. В этом смысл managed-кода. Конкретно по OnPaint в чистом скрипте - даже интересно попробовать. Вопрос, как будем замерять разницу? На глаз? Sergey Spirin пишет: Насчет обработки событий не очень понимаю, что вы имеете в виду. А вот "настраиваемая бизнес-логика" - это безусловно востребованная скриптовая ниша. Кстати говоря, у вас SB сделан так, что генерит целиком скриптовое приложение. У меня какое-то ощущение, что более востребован скрипт как встраиваемае подсистема, а не "целиковое решение". Я видимо непонятно объясняю. Надеюсь, сейчас насчёт событий объяснил понятно? Насчёт встраиваемой подсистемы я уже по второму кругу захожу - да, именно это уже реализовано, и уже успешно внедрялось годы назад. Вы, видимо, невнимательно продукт изучили, есть там Script Builder for Applications, и я не вижу технических причин, почему нельзя его использовать в любом компилируемом приложении, умеющем работать с OleVariant. Естественно, с пониманием того, что делаешь, с пониманием разделения кода на native (time-critical) и managed. Ещё раз вам советую скачать пример, посмотреть, как оно работает, и представить, что екзешник у вас написан на Харборе, а скрипт - на чём угодно, возможно для вашего удобства - на XBScript. Если такая модель взаимодействия вас идеологически устраивает, то дальнейший разговор имеет смысл. Sergey Spirin пишет: Зачем? dfm конечно будет, зачем здесь что-то придумывать? "в синтаксисе клиппера" будет клипперный класс с конструктором в 2 строки вызова "дельфийской стороны". Первая создаст объект формы и загрузит dfm, вторая расставит обработчики событий. В чем проблема? Если предложенная модель вас устраивает, то именно так и будет.
Sergey Spirin: Alexey Volkov пишет: Если предложенная модель вас устраивает, то именно так и будет. Так Вы готовы в этом участвовать? Супер! Тогда "пасьянс" складывается полностью. Если так, то я готов перейти от "размышлений" к делу. Фронт работы выглядит тогда очень гармонично: Петр и, возможно Паша (Паш, вы как?) - это Харбор сторона. Я - DelphiEngine, сопряжение с одной стороны с Харбор API, с другой с дезайн-тайм ("обвяжем" конечно ) Алексей - IDE, дезайн-тайм. По Delphi2010 решим "как всегда"? То есть, работаем на хакнутом, платим, если продукт состоится? Что скажете?
Alexey Volkov: Моё участвие в общем-то сведётся к апгрейду моего же продукта. Интерфейсы "наружу" революционным образом не поменяются. Конкретные шаги - портирование на 10ку, встраивание THarbourDataSet в палитру, регистрация XBScript. Консультирование, дебагирование. Но есть определённые риски. Я не знаю, насколько гладко портируется старый инструментарий на новую компонентную базу, сколько времени это займёт и какой будет результат. Поэтому да, подход "как всегда" разумен, а финальную версию можно будет собрать на арендованном "облаке". Надо выяснить, сколько это стоит.
Perec: Не смог, извините, смолчать. Так все время гостем заходил. Sergey Spirin пишет: То есть, работаем на хакнутом, платим, если продукт состоится? Ну вот и Spirin без глянца. А то "не люблю я этого". Работать, голубчик, тоже надо на легальном раз уж декларации такие. Это во-первых. Во-вторых, пасьянс был бы полон, если бы ИМХО для русскоязычного сообщества, на котором по мнению того же Spirin много не заработаешь, Run-time был бы бесплатен. А то как с FR, перефразируя известную песню "Горькую ягоду ели вместе, а сладкую ты одна!" Но это, наверное, решать нашим гуру, Кресину, "апостолам-хранителям" Петру и Павлу, Филатову и др. Или я не прав, мужики?
PSP: Perec, имхо, не стоит заострять на легальности. "Пусть первым кинет камень тот, кто сам безгрешен" Мало кто из нас использует все легальное (бесплатное). Пусть делают, на чем хотят. И вопрос платности (цены) - это вопрос авторов. Их дело - предложить, наше - ... ну а дальше каждый сам решит. Это мое мнение.
Perec: Уважаемый, PSP. Вопрос мой был только относительно "во-вторых". Причем я высказал пожелание, исходя из того, что участники форума могли бы, да и будут участвовать в тестировании и т.д. И еще. Без "наших гуру" никакой Run-Time не состоится. Если предположить, что продукт получится, (а я уверен, что при благоприятных условиях получится) то со временем он может стать (особенно, если еще и с отладчиком) конкурентом для Хaler, FiveWin и т.д. И поэтому спецам стоит задуматься о финансовых условиях участия в разработке. И не в последнюю, а в первую. А в остальном вы безусловно правы.
Andrey: PSP пишет: Perec, имхо, не стоит заострять на легальности. "Пусть первым кинет камень тот, кто сам безгрешен" Мало кто из нас использует все легальное (бесплатное). Пусть делают, на чем хотят. И вопрос платности (цены) - это вопрос авторов. Их дело - предложить, наше - ... ну а дальше каждый сам решит. Это мое мнение. Полностью согласен с PSP !!! Если цена не будет выше чем у всяких Visual Harbour'ов и Xaler'ов, тогда нормально все ! Еще бы совместимость с Lunix обеспечить - было бы классно ! А в качестве тестера тоже согласен быть. Надоело писать программы без IDE... И гибриды надоели.....
santy: Andrey пишет: Еще бы совместимость с Lunix обеспечить - было бы классно ! Ну с Линукс думаю будет тяжеловато, Делфи пока работает только под винду. А относительно оплаты - нужно думать.
Sergey Spirin: Alexey Volkov пишет: Моё участвие в общем-то сведётся к апгрейду моего же продукта. Интерфейсы "наружу" революционным образом не поменяются. Конкретные шаги - портирование на 10ку, встраивание THarbourDataSet в палитру, регистрация XBScript. Консультирование, дебагирование. Но есть определённые риски. Я не знаю, насколько гладко портируется старый инструментарий на новую компонентную базу, сколько времени это займёт и какой будет результат. Поэтому да, подход "как всегда" разумен, а финальную версию можно будет собрать на арендованном "облаке". Надо выяснить, сколько это стоит. Возможно не все "гладко" переведется, в основном из-за Unicod-а. Если использовали много стороннего, нужны будут Уникодные версии и т.п. >> регистрация XBScript. Вот этот пункт мне все-таки не ясен, зачем нужен XBScript? Можно ли без него?
Sergey Spirin: Perec пишет: Ну вот и Spirin без глянца. А то "не люблю я этого". Работать, голубчик, тоже надо на легальном раз уж декларации такие. Застыдил Ладно, я действительно "этого не люблю" и уже задумался о покупке Delphi2010 без привязки к этому проекту. Perec пишет: Во-вторых, пасьянс был бы полон, если бы ИМХО для русскоязычного сообщества, на котором по мнению того же Spirin много не заработаешь, Run-time был бы бесплатен. Гм... А что по этому поводу думают "мои коллеги"? Perec пишет: А то как с FR, перефразируя известную песню "Горькую ягоду ели вместе, а сладкую ты одна!" Чего-чего? Не понял. Все кто мне помогал лицензию получили бесплатно. Или о чем речь?
Наиль: Sergey Spirin пишет: Чего-чего? Не понял. Все кто мне помогал лицензию получили бесплатно. Или о чем речь? Исходя из Perec пишет: Во-вторых, пасьянс был бы полон, если бы ИМХО для русскоязычного сообщества, на котором по мнению того же Spirin много не заработаешь, Run-time был бы бесплатен. я понял так, что Perec хотел бы поиметь ФастРепорт для Харбор бесплатно. Но нехороший Spirin не даёт, хотя сам пользуется халявной средой разработки . Perec А если серьёзно, то я не могу купить Delphi 2010, т.к. программирование для меня всего лишь хобби и дохода не приносит. Мои потребности полностью закрываются TurboDelphi (я тоже не люблю пиратов). Даже те у кого Delphi куплен, как правило НЕ нуждаются в ещё одной (учитывая цену каждой версии). А на данный момент важно привлечь как можно больше соУчастников проекта. Поэтому и говорится о возможности участниками использовать такую Delphi2010, какую смогут себе позволить. santy пишет: Ну с Линукс думаю будет тяжеловато, Делфи пока работает только под винду. В конце октября должен выйти Delphi 2011 c поддержкой Linux, но это не поможет, т.к. SB под Windows. Sergey Spirin пишет: Вот этот пункт мне все-таки не ясен, зачем нужен XBScript? Можно ли без него? Хотя на этот вопрос отвечать Алексею, но мне кажется, что если начать с XBScript, то уже в этом году мы увидим полноценно работающий вариант, хотя и интерпетируемый, а не компилируемый. Без него конечно можно обойтись, но учитывая специфику SB, создание связки SB-Harbor равносильно приделыванию паровозу крыльев. Может и полетит, а может и нет.
Andrey: Sergey Spirin пишет: Чего-чего? Не понял. Все кто мне помогал лицензию получили бесплатно. Или о чем речь? Подтверждаю, я получил лицензию бесплатно ! Правда времени убил своего, но было интересно поучаствовать...
Alexey Volkov: Наиль пишет: Хотя на этот вопрос отвечать Алексею, но мне кажется, что если начать с XBScript, то уже в этом году мы увидим полноценно работающий вариант, хотя и интерпетируемый, а не компилируемый. Без него конечно можно обойтись, но учитывая специфику SB, создание связки SB-Harbor равносильно приделыванию паровозу крыльев. Может и полетит, а может и нет. Ну, вы не далеки от истины. Да, интерпретируемый можно получить очень быстро. Встроенную user-form инфраструктуру в готовое приложение - тоже. Но народ хочет получить средство разработки, в котором и нативный код, и визуальные объекты взаимно интегрированы. Тут надо понять, что полностью компилируемое приложение получить не получится. Для этого нужно создать аналог C++ builder. А вот "гибридное" решение с возможностью работы в одном IDE - нативные модули + визуальные модули со скриптом под ними - не сразу, но решаемо, в рамках имеющейся функциональности и заложенной возможности расширения. Из серьёзных проблем вижу только отладку нативного кода.
Петр: Наиль пишет: Хотя на этот вопрос отвечать Алексею, но мне кажется, что если начать с XBScript Поскольку Алексей уже вроде ответил, позволю и себе высказаться. Прежде всего Наиль определитесь - какую вы сторону представляете Harbour или Delphi и, как уже вам сказали, изучайте предметную область. Если вы начнете с XBScript, то им можете и закончить. Q. What is the cost of XBScript? A. XBScript is free of cost, anyone can download it free of cost from: http://www.xHarbour.com. Commercial versions (Professional and Enterprise are also -- Q. Can I distribute it freely? A. No, you are not allowed to distribute xbScript itself it in any form. You may freely distribute scripts of of any form, including html and asp pages. Во вторых XBScript есть чисто xHarbour -ский прибамбас. А кто-то писал, что на данный момент важно привлечь как можно больше соУчастников проекта.
Sergey Spirin: Alexey Volkov пишет: Тут надо понять, что полностью компилируемое приложение получить не получится Алексей, а расскажите чуть подробнее, почему ваш дизайнер форм и редактор кода так жестко "приколочены" к ActiveScript? Почему нет возможности просто генерить dfm-ки и сохранять их в файлы? В принципе же, это все, что нужно, далее, просто последовательно запускаются Харбор и С компиляторы, dfm-ки зашиваем в ресурсы полученного exe-шника, и просто его запускаем. А наш run-time с этими dfm-ками уже разбирается... Петр пишет: Если вы начнете с XBScript, то им можете и закончить. Добавлю еще, что производитель XBScript тот же, что и xHarbour Builder. Это такое IDE для xHarbour, но качество которого не выдерживает ну никакой критики. Почему проблема IDE столь и актуальна. Alexey Volkov пишет: Из серьёзных проблем вижу только отладку нативного кода. Ну, здесь надо смотреть, какие средства отладки есть в Харборе и писать взаимодействие с ними.
Alexey Volkov: Sergey Spirin пишет: Алексей, а расскажите чуть подробнее, почему ваш дизайнер форм и редактор кода так жестко "приколочены" к ActiveScript? Почему нет возможности просто генерить dfm-ки и сохранять их в файлы? Потому что решалась именно эта задача. Вынос настраиваемой логики (dfm+скрипт) из екзешника в структурированное хранилище рядом с ним. Хранилище определяет иерархическую объектную модель апплета, контроль времени жизни, области видимости элементов, каждый элемент по сути и класс и экземпляр, агрегирующий в себе свойства VCL-формы, методы скрипта и мета-свойства самого элемента (которые можно расширять). Есть возможность сохранять текущее ран-тайм состояние и восстанавливать в новом сеансе. Этого нет в Дельфи, простым "прошиванием" в ресурс это не решить, и мне кажется было бы неразумно от этого отказываться. Но если вам именно цельный екзешник нужен, то SB тут не помошник. надо искать простой дизайнер форм и писать своё решение.
Andrey: Alexey Volkov пишет: Но если вам именно цельный екзешник нужен, то SB тут не помошник. надо искать простой дизайнер форм и писать своё решение. Как разработчик, я настаиваю на цельном EXE-нике ! Ну пару-тройку DLL можно в придачу. Но больше ни-ни. И так замучился высылать обновления своей программы...
Alexey Volkov: Тогда вот дизайнер: http://www.econtrol.ru/formdsn_r.html 350 баксов. Думаю, склепать IDE из этого не составит труда. Формы линковать в ресурс, тогда штатные конструкторы работать будут. На автоматические прокси-классы я ссылки давал. Через OleVariant работать будет. Насчёт обработки событий - надо у автора узнавать, он вроде собирался какой-то универсальный прокси для событий написать, если новый RTTI это позволит. Andrey пишет: И так замучился высылать обновления своей программы... Прелесть SB в том, что единожды установив движок (набор бинарников отдельной универсальной инсталляшкой), далее обновляешь только приложение, цельное, которому ничего больше не нужно и которое весит копейки. Но монастырь у вас тут совсем другой
Sergey Spirin: Alexey Volkov пишет: Тогда вот дизайнер: http://www.econtrol.ru/formdsn_r.html 350 баксов. Думаю, склепать IDE из этого не составит труда. Ух ты, спасибо, похоже, то что нужно. Я когда гуглил, как-то мимо прошел. "Захаров М.Ю.", а не знаете как зовут? Он один этим занимается? Alexey Volkov пишет: Насчёт обработки событий - надо у автора узнавать Да я вроде продумал уже все на чистом Win32. Нужным обработчикам будет присваиваться одна универсальная процедура, Внутри процедуры идентифицироваться обработчик будует через трюк с подменой Sender-а. И уже даже договорился с коллегой (профи по asm-у) на бутылку коньяка Он напишет процедуру снятия параметров с регистров и стэка. Ну а дальше по Харбор API дергаем соответствующий метод. Alexey Volkov пишет: Но монастырь у вас тут совсем другой
Alexey Volkov: Sergey Spirin пишет: Ух ты, спасибо, похоже, то что нужно. Я когда гуглил, как-то мимо прошел. "Захаров М.Ю.", а не знаете как зовут? Он один этим занимается? Не знаю. узнавайте. Sergey Spirin пишет: Нужным обработчикам будет присваиваться одна универсальная процедура, Внутри процедуры идентифицироваться обработчик будует через трюк с подменой Sender-а. И уже даже договорился с коллегой (профи по asm-у) на бутылку коньяка Он напишет процедуру снятия параметров с регистров и стэка. Ну а дальше по Харбор API дергаем соответствующий метод. Да, подход правильный. У меня примерно так же, только дёргается IDispatch скрипта.
Наиль: Sergey Spirin пишет: "Захаров М.Ю.", а не знаете как зовут? МаилАгент докладывает: Захаров Михаил рождёный 8 апреля 1977 года. Sergey Spirin пишет: Он один этим занимается? http://www.ittlab.uniyar.ac.ru/contacts.html Sergey Spirin пишет: Да я вроде продумал уже все на чистом Win32. Нужным обработчикам будет присваиваться одна универсальная процедура, Внутри процедуры идентифицироваться обработчик будует через трюк с подменой Sender-а. И уже даже договорился с коллегой (профи по asm-у) на бутылку коньяка Он напишет процедуру снятия параметров с регистров и стэка. Ну а дальше по Харбор API дергаем соответствующий метод. Дальше обсуждать даже не стоит, нужно переходить к реализации. Я пока поучу матчасть и присоеденюсь со стороны Delphi. Хотя тут работа в основном на стороне Харбора. Sergey Spirin пишет: Alexey Volkov пишет: цитата: >Тогда вот дизайнер: >http://www.econtrol.ru/formdsn_r.html >350 баксов. >Думаю, склепать IDE из этого не составит труда. Ух ты, спасибо, похоже, то что нужно. Я когда гуглил, как-то мимо прошел. А я найдя решил, что это платный аналог SB и тоже прошёл мимо.
TakOj: Разрешите высказаться заинтересованной (в «супер» GUI) стороне! ИМХО!!! Я думаю «супер» GUI для [x]Harbour можно разработать (в свете данного топика) только при: -- обязательном условии; 1- Alexey Volkov и Sergey Spirin имеют серьёзные намерения. 2- Alexey Volkov и Sergey Spirin объединяют свои усилия. -- достаточном условии: 3 - (при выполнении 1) Alexey Volkov возвращается к своему заброшенному проекту и интегрирует [x]Harbour. 4 - (при выполнении 1) Sergey Spirin ведёт свою линию. 3 и 4 (при выполнении 1) предпочтительнее т.к. будет иметь место конкурирующие продукты, где будет возможность выбора. Гуру [x]Harbour будут иметь двойное преимущество при участии в 3 и 4.
TakOj: Alexey Volkov пишет: Но монастырь у вас тут совсем другой Мне кажется тут нарушается ( и уже нарушен "FRH") основной пункт устава монастыря - OpenSource!!! Т.ч. вы даже очень к стати !!!
Alexey Volkov: TakOj, давайте будем реалистами. Я не готов на 50% переписывать свой продукт, чтобы сделать его из универсального нишевым. дешевле и правильнее будет решить задачу на новой компонентной базе, с новым инструментарием. TakOj пишет: Мне кажется тут нарушается ( и уже нарушен "FRH") основной пункт устава монастыря - OpenSource!!! Смешно говорить об опенсурсе, когда компоненты и инструменты сплошь проприетарные. Конечному пользователю исходники не нужны, а нужен работающий инструмент. Хорошо, если бесплатный. Бесплатность не тождественна открытости, и наоборот. Поверьте линуксоиду со стажем.
Andrey: Alexey Volkov пишет: Конечному пользователю исходники не нужны, а нужен работающий инструмент. Полностью согласен ! Давайте от писанины переходить к делу !!! Чем быстрей, тем лучше....
Sergey Spirin: Привет, всем, и прошу прощения за то, что опять "пропал". К сожалению, со свободным временем у меня напряги продолжаются.... Наиль пишет: Дальше обсуждать даже не стоит, нужно переходить к реализации. Andrey пишет: Давайте от писанины переходить к делу !!! Чем быстрей, тем лучше.... Конечно, согласен, что если не к реализации, так к "глубокому прощупыванию" переходить давно надо. Очень надеюсь, что в ближайшее время свою часть начну. Могу даже уточнить, начну с 18-го июня (возвращаюсь из отпуска). Относительно финансовой стороны, предлагаю обсудить это приватно с реальными и потенциальными участниками по результатам первых "прощупываний".
Наиль: Sergey Spirin пишет: Относительно финансовой стороны, предлагаю обсудить это приватно с реальными и потенциальными участниками по результатам первых "прощупываний". Мне достаточно права участвовать в развитии проекта и использовать результат работы в собственных программках.
Andrey: Sergey Spirin пишет: Могу даже уточнить, начну с 18-го июня (возвращаюсь из отпуска). Как результаты ?
Sergey Spirin: Andrey пишет: Как результаты ? Пока никак. Увы руки не доходят....
Sergey Spirin: Привет! Нашел коллегу-дельфиста, которого заинтересовал проектом. К сожалению, в силу возраста, что такое Dbase он понимает очень смутно Поэтому ему потребуется некоторое время, чтобы войти в проблематику. Планирую, что в течении осени он сможет втянуться. Если втянется, то появляется надежда на осуществление этого проекта. Я же осенью вернусь пока к любимому Фасту Намечается проект - "FastReport for FoxPro"
Наиль: Петр пишет: Если вы начнете с XBScript, то им можете и закончить. цитата: Q. What is the cost of XBScript? A. XBScript is free of cost, anyone can download it free of cost from: http://www.xHarbour.com. Commercial versions (Professional and Enterprise are also -- Q. Can I distribute it freely? A. No, you are not allowed to distribute xbScript itself it in any form. You may freely distribute scripts of of any form, including html and asp pages. Не пойму почему это XBScript нельзя использовать в любой форме? Вот я скачал исходники с SVN. Можете скачать их одним архиве http://files.mail.ru/ZZX6BO и убедиться, что проект создаётся под лицензией GPL А значит я могу использовать его в пределах этой лицензии.
Alexey Volkov: Смотрю, обсуждение затихло? А тем временем внезапно появились новости. Мне удалось выйти на нынешних правообладателей библиотеки Dream Controls, которые благополучно забили на этот продукт. Пытался склонить их к открытию исходников, чтоб аналогичным образом и я смог поступить со своим Билдером. Но увы, они заняли предсказуемую позицию - ни себе, ни людям. Но по крайней мере удалось договориться о возможности передачи моей разработки (включая мою ветку их библиотеки) третьим лицам на условиях NDA. Т.е. в закрытом виде. Так что если есть серьёзные намерения - обращайтесь, передам в хорошие руки. Сам я уже развивать проект вряд ли буду. Условия передачи обсуждаются лично. Поскольку распространение под открытой лицензией невозможно, кандидат должен понимать ответственность, которую на себя берёт. Соответственно, исключительные права на передаются не безвозмездно. Надеюсь на понимание!
Наиль: Alexey Volkov пишет: Так что если есть серьёзные намерения - обращайтесь, передам в хорошие руки. С моей точки зрения, только Сергей Спирин в состоянии поднять этот проект. Но исходя из Sergey Spirin пишет: Реализация. Ясно, что начинать надо с 2-x сторон. 1) Delphi-часть, сначала собственно ран-тайм, здесь в общем-то все понятно и я могу это реализовать. 2) [x]Harbour-часть, здесь необходима некоторая библиотека, которая бы обеспечивала прозрачный доступ к классам, объектам Дельфи и делала бы их частью своего языка. Здесь моих знаний [x]Harbour явно не хватит. То есть, одному мне такой проект не поднять... Поэтому и пишу Паша, Григорий, Петр и другие уважаемые форумчане! Что вы думаете об этом? О возможном своем участии? ... без помощи сообщества здесь не обойтись. Лично я остановился на следующем варианте. Веб-сервер берёт данные из базы с использование XBScript и передаёт их клиентской стороне. На данный момент, клиент = веб-морда (веб-интерфейс). Но может быть и полноценным GUI-приложением. При этом данные будут браться с веб-сервера с использованием AJAX. В любом случае, я с удовольствием поучаствую, если кто-нибудь возьмётся за эту задачу. И ещё, при решении данной задачи не будут лишними исходники XBScript: http://tepuysoft.googlecode.com/svn/trunk
полная версия страницы