Форум » GUI » HMG OOP?... WHY NOT?... ;) » Ответить
HMG OOP?... WHY NOT?... ;)
Петр: Новый поворот в судьбе HMG. В начале мая Roberto Lopez обнаружил для себя ООП в Harbour. Последует ли примеру Роберто Григорий Филатов? Ведь до сих пор MiniGUI Ex. всегда следовал (и продолжает) в фарватере HMG. Воспримут ли такие изменения пользователи обеих библиотек? На что больше будет походить MiniGUI - на OOHG или на HWGUI? Очень интересно. И чем это все закончится?
Ответов - 28, стр:
1 2 All
Петр: Пока, что пользователи HMG очень лестно оценивают поделки Маэстро. Типа: "Your OOP code is very elegant and very simple and yet very powerful." Не удержался и скачал исходники. Вещь называется HMG OBJECTS 2010.05.15
Петр: Да, не зря Лопез написал: "I'm a 'procedural guy'. I'm just learning about OOP.." С другой стороны, от человека с хорошим опытом работы с VB, VFP and RapidQ можно было ожидать большего.
Петр: У меня нет никакого желания критиковать чью-то работу, тем более если я не собираюсь использовать ее результаты. Но поскольку, как я знаю, Григорий Филатов и Алексей Густов иногда пишут на форуме HMG, если они проявят заинтересованность, то могут подсказать Роберто, что так писать нельзя и, перефразируя классика, такой код нам не нужен. Я не буду обращать внимание на объектную модель предложенную Лопезом. Просто открою один из файлов - windows.prg И так CLASS WINDOW FROM APPLICATION дальше идет комментарий * Internal Data DATA aControls INIT {} .. DATA nRow INIT 0 DATA nCol INIT 0 .. еще дальше определения методов * Properties METHOD Row SETGET METHOD Col SETGET Первое, что бросается в глаза, это стиль описания класа - смесь FW и Classy. Вряд ли такую смесь можно назвать словом elegant. Но это дело вкуса. А вот дальше - уже серьезнее, методы объявлены без параметров и компиляция с ключами -w3 -es2 будет завершаться неудачей. Никого не должны сбивать столку комментарии. Никакие nRow и nCol не Internal Data. Это общедоступные данные, ведь по умолчанию SCOPE VISIBILITY в Harbour - EXPORTED. И зачем тогда реализация методов SETGET, ведь можно обращаться напрямую win1:nRow?
Петр: Идем дальше, сама реализация методов (properties) показывает, что и с процедурным программированием не все в порядке. К примеру [pre2]METHOD Title ( cValue ) CLASS WINDOW * Pre-Creation : Read / Write * Post Creation: Read / Write If ::lCreated If Pcount() == 0 RETURN GetProperty ( ::cName , 'Title' ) ElseIf Pcount() == 1 SetProperty ( ::cName , 'Title' , cValue ) EndIf Else If Pcount() == 0 RETURN ::cTitle ElseIf Pcount() == 1 ::cTitle := cValue EndIf EndIf RETURN Nil[/pre2] следовало бы переписать как [pre2]METHOD Title( cValue ) CLASS WINDOW * Pre-Creation : Read / Write * Post Creation: Read / Write If PCount() > 0 .and. ISSTRING( cValue ) If ::lCreated SetProperty ( ::cName , 'Title' , cValue ) Else ::cTitle := cValue EndIf EndIf RETURN iif( ::lCreated, GetProperty(::cName, 'Title'), ::cTitle )[/pre2] и код компактнее, и проверка параметра производится, и поведение (возвращаемый результат) классическое для Clipper/Harbour.
Петр: Группа методов Events тоже реализована как то не понятно. Вообще то эти методы должны быть виртуальными. Да, забыл добавить - никаких конструкторов, деструкторов, очевидно нам это пока не известно.
Петр: Прямо умиляет реализация метода [pre2]METHOD Create CLASS Window Local lMain Local lChild Local lPanel ::lCreated := .T. If ::nType == 0 // Standard lMain := .F. lChild := .F. lPanel := .F. ElseIf ::nType == 1 // Main lMain := .T. lChild := .F. lPanel := .F. ElseIf ::nType == 2 // Child lMain := .F. lChild := .T. lPanel := .F. ElseIf ::nType == 3 // Panel lMain := .F. lChild := .F. lPanel := .T. EndIf ..[/pre2] Помните, что этот детский код не оптимизируется сам по себе. [pre2]METHOD Create CLASS Window Local lMain := .F. Local lChild := .F. Local lPanel := .F. ::lCreated := .T. If ::nType == 1 // Main lMain := .T. ElseIf ::nType == 2 // Child lChild := .T. ElseIf ::nType == 3 // Panel lPanel := .T. EndIf ..[/pre2]
Петр: Следующая группа методов [pre2]METHOD Center CLASS Window If !::lCreated Return Nil EndIf DoMethod ( ::cName , 'Center' ) RETURN Nil[/pre2] должна быть переписана как [pre2]METHOD PROCEDURE Center CLASS Window If ::lCreated DoMethod ( ::cName , 'Center' ) EndIf RETURN[/pre2]
Петр: Ну и конечно, замена FOR i := 1 TO Len( ::aControls ) на FOR EACH и ValType ( ::aControls:oTabObject ) == 'O' на hb_isObject( ::aControls:oTabObject ) повсеместно
gustow: Петр, спасибо большое за комментарии. Приятно послушать умного человека (действительно - приятно :) )! Петр пишет: У меня нет никакого желания критиковать чью-то работу, тем более если я не собираюсь использовать ее результаты. Но поскольку, как я знаю, Григорий Филатов и Алексей Густов иногда пишут на форуме HMG, если они проявят заинтересованность, то могут подсказать Роберто, что так писать нельзя и, перефразируя классика, такой код нам не нужен. В том-то и дело, что я (я вам не скажу за всю Одессу... т.е. за Григория :) ) не смогу подсказать Роберте, "льзя" так писать или "нельзя": к стыду своему, я тоже - надеюсь, пока - "процедурный пацан" :) ну как-то не было необходимости до сих пор начинать мыслить исключительно по-ООПшному... знаю, что быть таким - это "каменный век"... но и ООП-стилю, насколько знаю, уже лет 20, если не 25, и после него напридумано немало чего еще более "продвинутого" [не спрашивайте меня о деталях - RTFM+Google]. М.б. вы, Петр, и другие ребята, достаточно хорошо "ООП-подкованные", как раз и подскажете Роберте что-нибудь полезное по этому поводу? А то проект у него этот в самом зародыше - и не поздно еще "основы" переписать без "большой крови". (если не хотите сами писать в HMGforum, то, думаю, Григорий или я без проблем процитируем там - от вашего имени - ваши мнения [только на английский переводите сами! :)]) И, кстати (как я понял), HMG OBJECTS не будет являться "основой" для "нового облика" HMG - Лопез вроде и пишет, что это будет отдельная штуковина (ну, или прибамбасина внутри HMG: хочешь - пиши "традиционно", хочешь - "ООПшно", а результат будет один... что, в общем-то, думаю, тоже было бы неплохо для возможности "плавной" миграции).
gfilatov2002: Петр пишет: Новый поворот в судьбе HMG. В начале мая Roberto Lopez обнаружил для себя ООП в Harbour. Последует ли примеру Роберто Григорий Филатов? Петр Большое спасибо за содержательные комментарии! Действительно, существует масса проблем в предложенном коде, поскольку Роберто сосредоточен на самой идее использования объектов в HMG, а тонкости реализации его не занимают. Ведь все равно этот код не будет работать без основной библиотеки. Это просто ООП-обертка для HMG, можно сказать, уступка для программистов, предпочитающих работать в стиле ООП. Роберто так и пишет в своем readme: OOP programmers... Welcome to HMG too :) Поэтому квалифицированные советы знатоков ООП совсем не повредят, особенно на начальном этапе проекта
Pasha: Петр пишет: METHOD Create CLASS Window Local lMain := .F. Local lChild := .F. Local lPanel := .F. ::lCreated := .T. If ::nType == 1 // Main lMain := .T. ElseIf ::nType == 2 // Child lChild := .T. ElseIf ::nType == 3 // Panel lPanel := .T. EndIf .. Нет предела совершенствованию Этот метод можно оформить и так: METHOD Create CLASS Window Local lMain := (::nType == 1) Local lChild := (::nType == 2) Local lPanel := (::nType == 3) ::lCreated := .T. ..
gustow: gfilatov2002 пишет: Это просто ООП-обертка для HMG, можно сказать, уступка для программистов, предпочитающих работать в стиле ООП. Что я и предполагал, но не был уверен, что понял смысл у Лопеза правильно... Спасибо за разъяснение, Григорий.
Петр: Pasha пишет: Нет предела совершенствованию
Петр: gfilatov2002 пишет: Роберто сосредоточен на самой идее использования объектов в HMG, а тонкости реализации его не занимают. Ведь все равно этот код не будет работать без основной библиотеки. Это просто ООП-обертка для HMG, можно сказать, уступка для программистов, предпочитающих работать в стиле ООП. Это не аргумент. Вспомните, как Лопез квалифицировал MiniGUI Ext как пример некачественного кода (местами, что есть то есть). Но к самому творению Лопеза - это можна отнести сполна. Большинство кода не приспособлено к реалиям Harbour 2.0. И даже не планируется. При этом перед Роберто не стоит проблемма совместимости с xHb. И никакая это не уступка - это дополнительный слой над самой библиотекой, призванный скрыть реализацию. И реализация этого слоя не должна существенно влиять на производительность библиотеки. К тому же можно поспорить об истинных причинах появления HMG OBJECTS, в т.ч. и с цитированием самого Лопеза.
Петр: gustow пишет: М.б. вы..как раз и подскажете Роберте что-нибудь полезное по этому поводу? А то проект у него этот в самом зародыше - и не поздно еще "основы" переписать без "большой крови". Судя по количеству написанных классов, зародышем это уже назвать сложно. А по поводу подсказок.. У меня сложилось мнениё о том, что пользователи HMG - это маленькая, дружная "секта", вместе с своим вожаком категорически не приемлющая критику и даже просто подсказки из вне Может я ошибаюсь, но уменя нет желания что-нибудь подсказывать. Мне просто не хотелось бы, что бы все это перекочевало в MiniGUI Ext.это будет отдельная штуковина (ну, или прибамбасина внутри HMG: хочешь - пиши "традиционно", хочешь - "ООПшно", а результат будет один... Эта прибамбасина снаружи. И по задумке Лопеза, внутри может быть не только HMG for Windows/
gustow: Петр пишет: пользователи HMG - это маленькая, дружная "секта", вместе с своим вожаком категорически не приемлющая критику и даже просто подсказки Петр, я уважаю вашу неоднократно доказанную квалификацию и ваше право иметь ваше мнение (и для многих, думаю, оно будет правильным) - но рискну высказать свои (м.б. смешные или примитивные для кого-то) соображения и резоны... Прошу немного потерпеть бурчание "неуча" :) ... Странно - не замечал уж особой нетерпимости в "маленькой дружной секте" к "пришлым" и мнениям, достаточно отличающимся от мнения "святейшего патриарха". :) Даже от меня (при моем-то "ученическом" уровне) Лопез неоднократно терпел и подсказки, и критику. Конечно, я не наезжал (мол, что ж ты такое неграмотное лепишь... ээх... учись, пока я жив! :) ) - но кое с чем бывал не согласен (и подобных "несогласностей" у других "сектантов" тоже бывало, и бывает, и, уверен, будет бывать)... и ничего, жив пока. :) (во всяком случае, во многих других программерских сообществах хамства и презрительного отношения к "нубам" бывает куууда как больше... а уж попробуй что-то вякнуть по поводу - как тебе кажется - неверных высказываний или решений какого-нибудь местного "гуру"... уууух как далеко послан будешь! :) ) Но если уменя нет желания что-нибудь подсказывать что ж, придется обходиться силами "сектантов" и тех "сторонних", у кого возникнет желание подсказать не "через губу". Относительно же, так сказать, "целевой функции" использования HMG... Меня, к примеру, пока вполне устраивает, что я могу, не особо заморачиваясь, стряпать простенькие приложения (и консоли, и ГУИ), использующие DBFки, наполняемые инфой во все еще ("тому уж скоро 30 лет..." :) ) используемых в больничках всей нашей области клипперовских программках (ну нету ресурсов у конторы "с нуля" все дела переписывать на чем-то "приличном"!)... И для этого мне вовсе не обязательно учить некий другой язык (даже из Xbase-семейства, но достаточно отличающийся от "цлиппера") ("другой" - я имею в виду C, Delphi-йский Паскаль, еще что-то), осваивать некий IDE (и при этом - поскольку практически все это добро небесплатно - либо рисковать напороться на "маски-шоу" при использовании "пиратки", либо колоть начальство на бабки - а колется оно без крайней необходимости... ну сами знаете как) и др. и пр... Т.ч. для моих (подчеркиваю - моих) "граничных условий" решение в виде "пакета программ для программирования HMG Ext." :) со следующими свойствами: бесплатного; с открытыми исходниками; (во всяком случае - очень большой процент исходников легко доступен или локально или в Интернете); наследующего конструкции, команды и функции языка (как и задумывалось Линаресом); "драматически" :) расширяющего возможности старого кода консольных приложений при относительно "малокровной" переделке; позволяющего (взяв "математику и логику" от старого кода - или хотя бы алгоритмы расчетов) и создав GUI-интерфейс (хоть через IDE, хоть "руками"), получить вполне "современного" вида приложение, которое "не стыдно людям показать"; достаточно хорошо документированного; (к примеру, недостаток этого в HWGUI отвратил меня от него в начале, когда я только осматривался и примеривался); с достаточно большим набором примеров (от простейших до готовых приложений); (опять же - ау, как с этим в HWGUI?.. что-то я там не приметил...) с оперативным реагированием разработчиков на баг-репорты и предложения; с частым выпуском новых билдов, версий и релизов; (Григорий, пользуясь поводом - спасибо еще и еще раз!) с небольшим (у MiniGUI - у (x)Harbour заметно больше), но имеющимся коммьюнити (в т.ч. русскоязычным) (причем рекламы-то практически никакой нет: все в основном приходят способом "друган мне пальцем на это место показал - я глянул... ни фига себе! интересная штуковина!" :) ); и наконец - как это имеет место с HMG (orig.) и HMG Ext., но не имеет места с тем же HWGUI (или я плохо смотрел? и не посылайте меня на CVS! пошлите меня просто и тупо скачать откуда-то EXE, ZIP или RAR...) - распространяемого в виде одного инсталляционного EXE-файла, где есть всё что нужно для начала работы (для HMG Ext еще надо установить халявный BCC, а в HMG orig. и так уже есть C-компилятор - MingW, кажется); добавьте что-то от себя по вкусу... :) является (опять же подчеркиваю - для моих "граничных условий") весьма даже приемлемым решением, снимающим кучу головных болей (которые, конечно же, компенсируются - время от времени - недостатками в документации, глюками и багами и пр. "родимыми пятнами опен-сорса" :) но насчет глюков и багов... а зачем тогда нам антивирусы? не было бы дыр в Винде - и Касперский не нужен!.. а ведь Винда у меня в офисе за деньги куплена - и однако же нервы значительно треплет значительно чаще и злее, чем бесплатный Харбор+МиниГУИ :( ). Извините за (возможно для кого-то) "примитив" и "непродвинутость"... :)
ММК: gustow пишет: что ж, придется обходиться силами "сектантов" и тех "сторонних", у кого возникнет желание подсказать не "через губу". Вот уж действительно - сколько людей столько и мнений :) А у меня от письма Петра возникло совсем другое впечатление. По поводу "подсказак" , не очень их любят там. Ну , а когда тебя просто терпят ... Мне кажется человек нормально поделился своим мнением так сказать в семейном кругу поэтому не очень понимаю такую реакцию . Петр пишет: Очень интересно. И чем это все закончится? А не может ли это быть признаком скорого перехода в "проффи"? :) Другими словами не хотят ли они сделать свой продукт платным. Типа новай подход ( ООП ) , как повод подходит .
Петр: gustow пишет: придется обходиться силами "сектантов" и тех "сторонних", у кого возникнет желание подсказать не "через губу". Мне жаль, что у вас сложилось такое мнение. Тем не менее, желаю вам удачи!
Петр: ММК пишет: Другими словами не хотят ли они сделать свой продукт платным. Типа новай подход ( ООП ) , как повод подходит . Ну нет, не думаю. Лучше всего появление HMG OBJECTS объясняет сам Лопез «HMG OBJECTS OOP layer has only four points of contact with HMG core library: - SetProperty() function. - GetProperty() function. - Domethod() function. - _Define* Control definition functions. The good side of this, is that you could easily replace the HMG core back-end with any other that you want for different platforms (ie: GTK on Linux and MacOSX). Since the perfect isolation of OOP layer from low level code, the basics of such implementation could be running after only some hours of work. In such context current HMG core code could became only one of many back-ends that you could plug in HMG OBJECTS according your needs (In fact, that is my secret plan )»
ММК: Петр пишет: Ну нет, не думаю. Лучше всего появление HMG OBJECTS объясняет сам Лопез Ну меня он не очень убедил :) Жизнь покажет. Кстати вот очередной IDE Highlights: Open Source! GPLv3, no hidden costs. Cross-platform. Runs on Linux, Mac, Windows (uses wxWidgets). Written in C++. No interpreted languages or proprietary libs needed. Extensible through plugins Compiler: Multiple compiler support: GCC (MingW / GNU GCC) MSVC++ Digital Mars Borland C++ 5.5 Open Watcom ...and more Very fast custom build system (no makefiles needed) Support for parallel builds (utilizing your CPU's extra cores) Multi-target projects Workspaces to combine multiple projects Inter-project dependencies inside workspace Imports MSVC projects and workspaces (NOTE: assembly code not supported yet) Imports Dev-C++ projects Debugger: Interfaces GNU GDB Also supports MS CDB (not fully featured) Full breakpoints support: Code breakpoints Data breakpoints (read, write and read/write) Breakpoint conditions (break only when an expression is true) Breakpoint ignore counts (break only after certain number of hits) Display local function symbols and arguments User-defined watches (support for watching user-defined types through scripting) Call stack Disassembly Custom memory dump Switch between threads View CPU registers Interface: Syntax highlighting, customizable and extensible Code folding for C++ and XML files. Tabbed interface Code completion Class Browser Smart indent One-key swap between .h and .c/.cpp files Open files list for quick switching between files (optional) External customizable "Tools" To-do list management with different users And many more features provided through plugins!
Петр: Кстати вот очередной IDE Угу, Code::Blocks, поддерживает подсветку синтаксиса Clipper. Как альтернативу для любителей wxWidgets могу предложить посмотреть CodeLite.
Петр: gustow пишет: Относительно же, так сказать, "целевой функции" использования HMG Относительно целевой функции HMG и MiniGUI Ex я не писал ничего. Но поскольку вы, как я понимаю, восприняли мои сообщения как "наезд" на MiniGUI, давайте доиграем эту игру до конца Все, что я напишу ниже, прошу рассматривать с точки зрения возможных улучшений MiniGUI и только. "Все события и персонажи вымышленные, а любые совпадения случайны".
Петр: gustow пишет: Меня, к примеру, пока вполне устраивает, что я могу, не особо заморачиваясь, стряпать простенькие приложения (и консоли, и ГУИ) А как же быть со "сложными" приложениями? Кто их писать будет? Кто из "сектантов" или "сторонних", подсказывающих не "через губу" наконец напишет нормальное IDE? Или это неподъемная задача для коммьюнити? Стряпать консольные приложения с помощью можно, но.. Вот, что пишет некий Аdam Harbour included into MiniGUI (1.8.81 and new) for regular expressin not use functions from own hbpcre.lib but from standard BCC lib, so functions hb_regex*() not work correct. Error is in hbrtl.lib. To use in hbrtl.lib hbpcre.lib must be set HB_HAS_PCRE variable when compile Harbour binaries. (This variable is set auto by *make.exe when detect file %HBROOTDIR%\external\pcre\pcre.h) Т.е. другими словами сборка Harbour для MiniGUI не только нестандартная, но и дефективная. Контрибуторам MiniGUI надо искать пути для использования с библиотекой стандартной сборки Harbour. Некий Кеvin пишет «My console program needed MiniGui.ch because it was using GetStartUpFolder(), a pseudofunction defined in Include\i_pseudofunc.ch. I used the translated version instead and found I could do without MiniGui.ch. This had an unexpected side benefit: the .exe size reduced from 1.6M to 900K. I believe ..» В чем здесь проблема или ее нет. Здесь есть несколько проблем. Первая - это то, что некоторые позователи HMG догадываются о существовании некого HMG language и не догадываются о существовании Harbour, они продолжают программировать на Clipper for Windows и не хотят изучать Harbour/xHarbour. Даже Алексей говорит о каком-то "пакете программ для программирования HMG Ext.". Даже Лопез (!) в рассылке для разработчиков Harbour (!) уверял, что его HMG может использоваться в контексте отличном от Harbour/xHarbour. При этом не смог ответь на прямой вопрос с каким языком может использоваться HMG, если две базовые основы его WinAPI и Harbour API? Если бы Kevin интересовался Harbour/xHb, ему бы в голову не пришло использовать MiniGUI ради одной единственной функции: [pre2] local cPath #ifndef __XHARBOUR__ cPath := hb_dirBase() #else hb_FNameSplit( hb_CmdArgArgV(), @cPath ) #endif ? cPath[/pre2] Ну и проблемы, ведь работает все и так. Да работает. Только нативные функции кросплатформенны, а функции в составе HMG Win ориентированные (и примеры такие же). Т.е. если наступит светлое завтра и вы плавно уедете на HMG OBJECT over HMG for Linux вам придется перелопачивать кучу кода. Контрибуторам MiniGUI надо потихоньку переписывать часть кода библиотеки, менять макросы с целью использования нативных функций языка.
Петр: gustow пишет: бесплатного; с открытыми исходниками; (во всяком случае - очень большой процент исходников легко доступен или локально или в Интернете); ok, трудно не согласиться наследующего конструкции, команды и функции языка (как и задумывалось Линаресом); "драматически" :) расширяющего возможности старого кода консольных приложений при относительно "малокровной" переделке; относится в большей мере к Harbour/xHarbour позволяющего (взяв "математику и логику" от старого кода - или хотя бы алгоритмы расчетов) и создав GUI-интерфейс (хоть через IDE, хоть "руками"), получить вполне "современного" вида приложение, которое "не стыдно людям показать"; в принципе - да, но уже не редкость Win 7, к которой HMG не готов, в смысле не использует API семерки.
Петр: достаточно хорошо документированного; (к примеру, недостаток этого в HWGUI отвратил меня от него в начале, когда я только осматривался и примеривался); с достаточно большим набором примеров (от простейших до готовых приложений); (опять же - ау, как с этим в HWGUI?.. что-то я там не приметил...) Базовые примеры у HWGUI есть. Базовая документация тоже. Описано как компилировать библиотеку, примеры. В документации даже есть раздел "Inside HwGUI". Что внутри MiniGUI и как оно работает вы знаете? Еще по поводу примеров - а примеры писать тоже уметь надо и не такая это простая штука. Проблема примеров МiniGUI Ext, с моей точки зрения, как раз их количество - в папке samples более трех тысяч файлов! Не удивительно, что многие вместо разглядывания этих примеров пытаются найти ответ на форуме. И не находят - правильно, сто раз отвечать на один и тот же вопрос Григорий уже "задолбался", а остальное комьюнити не очень спешит с подсказками. Дублирование, низкое качество отдельных примеров, примеры на общую технику, никак не связанные с MiniGUI, перенасыщенность отдельных примеров вставками С кода. Часть кода из примеров вообще должна быть включена в состав самой библиотеки, а не дублироваться из примера в пример. Самое главное на мой взгляд, что есть сейчас в HWGUI и нет в MiniGUI, - адаптация к Harbour API 2.0 и UNICODE, сделанная Przemyslaw Czerpak -ом со знанием дела. Я думаю, что найдутся пользователи MiniGUI и уже пользуясь готовыми решениями смогут адаптировать HMG к современным реалиям. с оперативным реагированием разработчиков на баг-репорты и предложения; с частым выпуском новых билдов, версий и релизов; (Григорий, пользуясь поводом - спасибо еще и еще раз!) Что тут скажешь - MiniGUI Ex повезло с Григорием! Единственное, что меня смущает отсутствие института патчей, как такового. Выпустили версию 1.х, обнаружили ошибку выпускаем 1.х.а. Опять все по новой скачивать. Скачали, а тут новый баг вылез. Ну ладно, его в 1.x+1 исправим. Решается правильным подбором инсталятора. с небольшим (у MiniGUI - у (x)Harbour заметно больше), но имеющимся коммьюнити (в т.ч. русскоязычным) (причем рекламы-то практически никакой нет: все в основном приходят способом "друган мне пальцем на это место показал - я глянул... ни фига себе! интересная штуковина!" :) ); Не забывайте, пользователи MiniGUI являются в первую очередь пользователями (x)Harbour. и наконец - как это имеет место с HMG (orig.) и HMG Ext., но не имеет места с тем же HWGUI (или я плохо смотрел? и не посылайте меня на CVS! пошлите меня просто и тупо скачать откуда-то EXE, ZIP или RAR...) - распространяемого в виде одного инсталляционного EXE-файла, где есть всё что нужно для начала работы (для HMG Ext еще надо установить халявный BCC, а в HMG orig. и так уже есть C-компилятор - MingW, кажется); Что вы меня все время к HWGUI отсылаете, я им не пользуюсь . В свое время мне не удалось зарегистрироваться на hwgui.borda.ru Скачайте HBIUP и выскажите свое мнение о процессе инсталяции, повторной инсталяции Мне будет интересно, а для вас, если понравится конечно, могу поделиться инсталяционным скриптом для InnoSetup с MiniGUI Time.
Andrey: Петр пишет: могу поделиться инсталяционным скриптом для InnoSetup с MiniGUI Time. Очень хочется...
Петр: Andrey пишет: Очень хочется... Чего хочется? Чтобы я поделился скриптом с MiniGUI Time или с вами? Обыкновенный скрипт, если хотите давайте адрес эл.почты
Andrey: Петр пишет: Обыкновенный скрипт, если хотите давайте адрес эл.почты 30195 @ mail.ru - Спасибо большое !
полная версия страницы