Форум » GUI » Новая версия Расширенного релиза библиотеки MiniGUI (часть VI ) (продолжение) » Ответить
Новая версия Расширенного релиза библиотеки MiniGUI (часть VI ) (продолжение)
gfilatov: Начало темы находится здесь, а теперь АНОНС * АНОНС * АНОНС * АНОНС * АНОНС Готовится к опубликованию новая сборка №48, которая выйдет в конце недели. Если у Вас есть интересные наработки для включения в новый релиз, то сейчас самое удобное время для их отправки мне Кратко, что нового: - исправление обнаруженных ошибок и неточностей кода; - новый класс HEADERIMAGE для Grid и Browse; - свойство Address в Hyperlink может теперь открывать папку или файл на диске; - добавлен NOTABSTOP класс для Browse; - поддержка пользовательских компонентов (заимствована из оффициального релиза); - расширения и исправления в библиотеках TsBrowse и PropGrid; - обновлены сборки Харбор и HMGS-IDE; - новые и обновленные старые примеры (как обычно ).
SergKis: Петр пишет Присмотритесь к TTaskDialog ... Поэтому изучив xhb-diff, напичкав свой код #ifdef ваяете что-то не слишком замысловатое (оно же еще в multithread работать должно, а там опять грабли при переносе с одной системы на другую) или забиваете на классы и с помощью WinAPI/C API/PRG кода в старом добром процедурном стиле решаете нужную вам проблему и предлагаете ее Григорию для включения в MiniGUI Присмотрелся, думаю в xhb, наверно, не включен h_taskdialog.prg, т.к. "забили на классы". Скачал, смотрю есть такой файл. Надо поучиться на xhb h_taskdialog.prg, как "в старом добром процедурном стиле" написать свой класс. Открываю , а там, решение "в старом добром процедурном стиле" CREATE CLASS TSimpleTaskDialog FUNCTION SimpleTaskDialog а дальше, больше, есть METHOD OnDestroyed( hWnd, nNotify, nWParam, nLParam ) CLASS TTaskDialog а в нем ужасное ::HWND := Nil От души отлегло, гора с плеч упала, в xhb (за деньги) все в порядке с классами. А то в clipper с классами работали ... а тут "с помощью WinAPI/C API/PRG кода в старом добром процедурном стиле решаете нужную вам проблему" К чему это я и о чем ? Снова о "религии", понимал, что "лезу в чужой монастырь со своим уставом" предложением ... Видно мы по разному крестимся. У себя, я получил, того чего не хватало мне в МиниГуи, для других ...
gfilatov2002: SergKis пишет: От души отлегло, гора с плеч упала Прошу без обид... SergKis пишет: заложить в hmg следующее: Сделал таким образом: 1. Оставил введенные переменные _HMG_aFormMisсData1, _HMG_aFormMisсData2, а вместо _HMG_aControlMiskData0 предлагаю использовать уже существующий _HMG_aControlMisсData2 для хранения массива. 2. В процедурах _DoWindowControlEventProcedure, _DoWindowEventProcedure добавил параметры в вызов и Eval и проверку i > 0 3. Добавил в _EraseControl() обработку 2-го элемента массива Cargo [pre2] IF ISARRAY ( _HMG_aControlMiscData2 [ i ] ) .AND. Len( _HMG_aControlMiscData2 [ i ] ) > 1 IF ISBLOCK ( _HMG_aControlMiscData2 [ i ][2] ) Eval ( _HMG_aControlMiscData2 [ i ][2], i, p ) ENDIF ENDIF [/pre2] Вместо Eval(_HMG_bFormRelease, k) предлагаю использовать событие ON RELEASE (или ON INTERACTIVECLOSE) формы. Вместо блоков кода Eval(_HMG_bFormInit, k) использовать событие ON INIT формы, а вместо блока Eval(_HMG_bControlInit, k) делать добавление объекта в 1-й элемент массива _HMG_aControlMiscData2 после определения каждого контрола (где index регистрации элемента есть GetControlIndex(c,f)). Обработку событий WM_USER+... делать в своем MyEvents с использованием команды Set Events Function To MyEvents. P.S. Мне симпатичен Ваш подход, но совместное использование псевдо-ООП и настоящих классов порождает ненужное дублирование в ядре библиотеки...
SergKis: gfilatov2002 пишет использование псевдо-ООП и настоящих классов порождает ненужное дублирование в ядре библиотеки... Лучше иметь дублирование, чем не иметь ничего, речь идет о разрезах контролов по окнам, то что в МиниГуи кроме ascan ничего нет (доступ к контролам), вызывает удивление, база есть а разрезов, по окнам нет. Это как DBFCDX только с Locate, без индексов и тегов, scope. Если нужен индекс\тег, то стройте его (клиенты) сами, там С структуры, там учебник по С и вперед. Т.е. что бы получить что то с МиниГуи пользователь должен досконально знать организацию и цепочки (itemoв), а если с версией это меняется. Словом недоработка, по моему мнению, длящаяся годами. Прошу без обид... Обиды нет, есть непонимание, почему просто не сказать, систему сообщений берем от Петра. Будет ли она лучше, посмотрим. Что предложено сечас, полная изолированность конрола, т.е. он о себе знает все, где что брать, как отображать и ничего не знает о др. конролах окна. И так каждый контрол, т.е. создана база контролов, в которых можно события пронумеровать с 1 и далее (на каждый контрол), наложив на них одинаковое действие, как в примере. В программе нет ни одного места использования контрола напрямую, только через сообщения. Окно так же ничего не знает о поведении контролов (списки-разрезы знает). На окно мы ставим с 1 и далее события, которые в основном раздают сообщения. Т.е. с контролами общаемся только через события окна, никаких прямых сообщений из разных мест прогр. нет, только через окно, так же поступаем и с др. окном, надо сделать refresh, посылаем сообщение окну, а оно контролам групповые сообщения. Сделал таким образом: Думаю это все не очень нужно (мне точно), так сказал, наверно сгоряча. Зачем это, если можно исходники подправить, не сложно. Думается и другим корячится вряд ли захочется, тем более, что исп. OnInit и OnRelease можно, но это большая морока делать в КАЖДОМ окне, а до OnInit от _DefineWindow... как до луны.
SergKis: PS совместное использование псевдо-ООП и настоящих классов порождает По мне, так положительные эмоции, можно написать с псевдо ООП, будет крутиь макро (чуть медленнее), но сделает. Можно исп. объект, будет ТОЖЕ работать, возможно, чуть быстрее, а при передаче его (объкта) в блок кода, так и писать удобнее, а с блоками сообщений (моя версия) именно так и происходит. У пользователя МиниГуи есть выбор, как писать, а сейчас его нет. Пишем только псевдо ООП, а если дурит препроцессор, в небольшом примере идет, в родной проге приходится уходить с псевдо на функции. Или сразу писать функциями. Тут тоже вопрос, а что лучше тогда ?
Петр: SergKis пишет: Присмотрелся Знаете, я ровным счетом ничего не понял, что вы хотите сказать. Прямо какой-то поток сознания. Вы случайно во второй цитате или не видели? И кто вам посоветовал "как "в старом добром процедурном стиле" писать свои классы"? Вы можете вызвать TaskDialog из xhb? Рад за вас И что у вас вызвало столько эмоций в методе OnDestroyed?
SergKis: Петр пишет Знаете, я ровным счетом ничего не понял, что вы хотите сказать. Боюсь не поймете, но попробую объяснить. На мое "с xhb дел не имел (кроме сборки letodb) никаких" и sourcе кодером становиться 'совершенно не стремлюсь" (xhb не нужен мне), вы, явно ерничая, даете советы (см. выше), особенно порадовало именно после или. Ваше "Вот, к примеру, в xhb реализация деструктора обьекта приводит к повреждению HVM памяти." навело на мысль, что просто свойство\переменную в Nil, недостаточно (со времен clipper хватало) и это вызвало эмоции, как же я работал до этого. И я, явно ерничая, побежал смотреть, как вы, применяете на практике, то что советуете ... Ваше "читать xhb-diff ... нужно знать их отличия (xhb-diff)", вызывает желание посоветовать почитать инструкцию по эксплуатации автомашины ГАЗ-51, там тоже есть отличия, при переключении передач от автомобиля ВАЗ. Вы можете вызвать TaskDialog из xhb? Рад за вас Опять фантазируете, ерничаете, я только сказал, что в xhb есть H_TaskDialog.prg, .т.е. включен в проект, работает он или нет, это др. вопрос. Прямо какой-то поток сознания. Надеюсь, я его расшифровал
Петр: SergKis пишет: Ваше "Вот, к примеру, в xhb реализация деструктора обьекта приводит к повреждению HVM памяти." навело на мысль Вы не правильно интерпретировали мою подсказку. Опять фантазируете, ерничаете, я только сказал, что в xhb есть H_TaskDialog.prg, .т.е. включен в проект Нет, но могу вам напомнить, что я не мантайнер MiniGUI. К тому же "включен в проект" можно понимать по разному, то ли это значит, что файлы включены в поставку (архив/инсталятор), то ли используется файлом сборки (make файл/bat). В поставе "xhb (за деньги)" используется 2 вариант (с классами там действительно все в порядке )
gfilatov2002: Петр пишет: могу вам напомнить, что я не мантайнер MiniGUI Ребята, давайте жить дружно Подготовил очередную бетку для новой сборки 17.06 со следующим списком изменений [pre2] * New: Added the read/write user-defined property 'Cargo' for the Forms. You can set/get this property at runtime: - function syntax: SetProperty ( Form, 'Cargo', xUserData ) GetProperty ( Form, 'Cargo' ) --> xUserData - pseudo-OOP syntax: Form.Cargo := xUserData Form.Cargo --> xUserData Sample code: ThisWindow.Cargo := InputBox( 'Enter a form's title', 'New Title' ) ThisWindow.Title := ( ThisWindow.Cargo ) It was a postponed user's request. Suggested and contributed by SergKis. * New: Added a possibility to load a menu from an application resource with the accelerators: - added a new function hMenu := LoadMenu( [<hInstance>], cMenuName ); - added the new functions hAccel := LoadAccelerators( [<hInstance>], cTableName ) and SetAcceleratorTable( hWnd, hAccel ). It was a postponed user's request. Note that hMenu handle should be destroyed ON RELEASE of a form via calling of the function DestroyMenu( hMenu ). Contributed by Petr Chornyj <myorg63@mail.ru> (see demo in folder \samples\Basic\MenuRES) * New: Added the following new commands for managing of the application events: - ON APPEVENT [ID] <nId> ACTION <bAction> OF <window> ; [NOACTIVE>] [ONCE>] [RESULT] TO <lResult>. - EMIT [EVENT] [ID] <nId> OF <window>. - REMOVE APPEVENT [[ID] [<nId>] | ALL] OF <window> ; [ONCE>] [RESULT] TO <lResult>. - UPDATE APPEVENT [ID] <nId> [ACTION <bAction>] OF <window> ; [NOACTIVE>] [ONCE>] [RESULT] TO <lResult>. Contributed by Petr Chornyj <myorg63@mail.ru> (see demo in folder \samples\Advanced\AppEvents) * Modified: GetBox control - improved caret shape in the insert/overwrite modes. A readonly GetBox will not show a caret now. Based upon a contribution of SergKis (see demo in folder \samples\Basic\GetBox) * Modified: The following obsolete C-functions were guarded with HMG_LEGACY_ON constant in the Minigui core: - BitmapSize(); - C_DrawFocusRect(); - GetWindowFromDC(). The actual function's names are GetBitmapSize(), DrawFocusRect() and WindowFromDC(). Contributed by Grigory Filatov <gfilatov@inbox.ru> (see demo in folder \samples\Advanced\SetThemes) * Updated: PropSheet library source code (see in folder \Source\PropSheet): - updated for compatibility with the last Minigui changes. Suggested and contributed by SergKis. * Updated: Adaptation FiveWin Class TSBrowse 9.0 in HMG: - added a new method UserKeys( nKey, bKey, lCtrl, lShift ). Sample code: :UserKeys(VK_F2, {|oBr,nKy,cKy| Add_Rec(oBr, nKy, cKy) }) :UserKeys(VK_F3, {|oBr,nKy,cKy| Del_Rec(oBr, nKy, cKy) }) :UserKeys(VK_F3, {|oBr,nKy,cKy| MsgBox(cKy, 'Ctrl + F3') }, .T.) :UserKeys(VK_F3, {|oBr,nKy,cKy| MsgBox(cKy, 'Shift + F3') }, , .T.) :UserKeys(VK_F3, {|oBr,nKy,cKy| MsgBox(cKy, 'C + S + F3') }, .T., .T.) :UserKeys(NIL , {|oBr,nKy,cKy| _LogFile(.T.,cKy, 'other', nKy ) }) If an above codeblock returns Nil or .F., then method KeyDown will be finished, else if return is .T. then method KeyDown will work further. Contributed by SergKis (see demo in folder \samples\Advanced\Tsb_addrecord_3) * Updated: HbSQLite3 library: - update for using SQLITE3 version 3.19.3 (from 3.19.0). Contributed by Grigory Filatov <gfilatov@inbox.ru> * Updated: Harbour Compiler 3.2.0dev (SVN 2017-05-20 02:25). Contributed by Grigory Filatov <gfilatov@inbox.ru> (look at ReadMe.txt in folder \harbour) * Updated: 'Sumatra PDF Viewer' utility: - added ability to translate the interface, - added ability to open url links from pdf documents, - added view documents in tabs, - added saving of last session and recent files in PdfView.recent, - added processing of command line with pdf files as parameters, - added auto refresh the file list when main window got focus, - minor bugs fixed. Based upon a contribution of HMG user KDJ. Adapted for Minigui Extended by Grigory Filatov <gfilatov@inbox.ru> (see in folder \samples\Advanced\PdfView) * Updated: 'TsBrowse Add New Record with Index Order' sample: - fixed the warnings in a C-code; - modified for using of a method UserKeys. Contributed by Grigory Filatov <gfilatov@inbox.ru> (see in folder \samples\Advanced\Tsb_addrecord_3) * Updated: 'DOS-like menu with using of TsBrowse' sample. Based upon a contribution of Krzysztof Stankiewicz <ks@nsm.pl> (see in folder \samples\Advanced\Tsb_menu) [/pre2] Благодарю за оперативную помощь в подготовке этой сборки SergKis и Петра Без Вашей поддержки ничего бы не вышло... Кстати, команды ON APPEVENT/EMIT были вдохновлены SergKis Петр пишет: SergKis подбросил интересную идею, попробую реализовать что-то подобное ON APPEVENT [NAME] <evName> [ID <id>] | [AUTO] EVAL <{block}> [ONCE] EMIT <evName>
SergKis: Петр xhb, меня не интересует в любом виде. Я, не распаковывая, глянул архив xhmg1705... и увидел, что увидел. Глянул команды из hbclass.ch и сделал вывод, что класс TWndData полностью отвечает требованиям xhb, т.е. не требует дополнительных #ifdef XHARBOUR для работы в xhb. Посмотрел и TsBrowse на предмет #ifdef их всего несколько строк, причем только 1 реальная, связанная с функ. CToT. Говорю, просто для информации, что и как посмотрел. Действительно, давайте закончим эту не интересную дискуссию.
SergKis: gfilatov2002 пишет Прошу без обид... Мне симпатичен Ваш подход, но совместное использование псевдо-ООП и настоящих классов порождает ненужное дублирование в ядре библиотеки.. Я, скорее, рассердился на себя. Мой товарищ по работе, сразу сказал, не трать время, ни один класс окна и контрола не будет принят добровольно в МиниГуи, т.к. он практически хоронит псевдо ООП (Andrey пишет Удобней кстати для использования.). Я, наивный, не поверил, т.е. "хотел как лучше ...". Так что я сильно рассердился на себя.
gfilatov2002: SergKis пишет: я сильно рассердился И зря... Ваше предложение не отвергнуто, но отложено по причинам, которые уже озвучил Петр: - отсутствие внятной модели классов; - смешивание визуальных и невизуальных методов в классах; - наличие в предлагаемом коде избыточных пользовательских методов, которые должны добавляться наследованием от базового класса. SergKis пишет: ни один класс окна и контрола не будет принят добровольно в МиниГуи Тка сложилось исторически, что библиотекой пользуются в основном старые "зубры" программирования, которые привыкли использовать процедурный стиль. Кстати, это одна из причин популярности Минигуи в отличие от того же грамотно спланированного HwGui. ИМХО Признаюсь, что я тоже овладел классами только на пользовательском уровне, что потребовало минимум 3 года работы. Поэтому я всецело доверяю в этом вопросе мнению Петра, который разработал для минигуи класс TTaskDialog и, поэтому имеет право предлагать его в качесте примера Кстати, предложенные Вами кодовые блоки для подключения классов окон и контролов могут быть легко добавлены в переменную _HMG_MainCargo как #xtranslate _HMG_bFormInit => _HMG_MainCargo \[1] #xtranslate _HMG_bControlInit => _HMG_MainCargo \[2] #xtranslate _HMG_bControlErase => _HMG_MainCargo \[3] #xtranslate _HMG_bFormRelease => _HMG_MainCargo \[4] и затем вызываться в соответствубщих функциях ядра при необходимости. Также есть замечание по поводу имени класса TCntData. Cnt - это сокращение для Count, а для контрола д.б. CTRL или CTL (это так, к слову). В заключение обратите внимание, что предложенные Вами довольно давно изменения для GetBox (форма курсора) включены в следующую сборку На все требуется время для осмысления...
SergKis: gfilatov2002 пишет отсутствие внятной модели классов... наличие в предлагаемом коде избыточных пользовательских методов, которые должны добавляться наследованием от базового класса. Я считал, что работаем в процедурной среде МиниГуи, а не среде грамотно спланированной цепочки классов. Т.к. практически исключил наследование. Как это делать в _HMG_aControlMiskData0[ i ][1] := <объект контрола> ? По этой причине сделал избыточные (немного) классы. Т.е. я отверг изначально oApp->oWindow->oWindowDialog ... Представленные классы - это скорей сложные процедуры\функции. Расширение свойств, методов - через функции объектов и примерно так, добавляем переменную в объект и присваиваем значение := oKeyData() получая сразу контейнер данных и исп. блоки с возможностью проводить групповые операции Eval() или Sum(). Т.е. с моделью я определился, она процедурная, как и МиниГуи. смешивание визуальных и невизуальных методов в классах хотелось бы конкретики По названиям, абсолютно, без разницы как будут называться, были бы в наличии.
SergKis: PS Потом, я не знаю, будем делать и повторять в классе TAppData свойства\методы из App. ... псевдо ООП команд ? Если будем, сделать не сложно, тогда там будет регистрация окон (как контролов в окне), т.е. свои :oName, :oHand с доступом. Вопрос надо ли это сейчас ?
SergKis: PS Если вопрос наследования на первом месте (или замена класса полностью в переменной _HMG_aControlMiskData0[ i ][1])?, делаем это (к примеру) в функции oWndData(...). Если к примеру _HMG_bWndObject := bBlock выполняем и возвращаем что она дает из ф-ии oWndData, если не задан - как сейчас. Все по МиниГуи-шному
SergKis: gfilatov2002 пишет в отличие от того же грамотно спланированного HwGui. Основная причина - она брошена. В 2009 году она была 2004\5 года сборки. Сейчас ее состояние (внутреннее) практически не изменилось, только перевелась на hb3.2 с небольшими улучшениями и сменой названий функции. Потом, многие вещи оставлены на очень низком уровне - что надо собирайте сами, а инстукции\примеров нет, "догадайся мол сама". Мое мнение
gfilatov2002: SergKis пишет: Все по МиниГуи-шному Замечательно, тогда присылайте мне по почте предлагаемые изменения, будем рассмативать их для будущих сборок SergKis пишет: Основная причина - она брошена. Согласен. Но чтобы этого не случилось с Минигуи, необходимы стимулы, в т.ч. Ваша поддержка и предложения по улучшению кода. Я не устаю повторять, что всегда открыт для новых улучшений, но только после их критического пересмотра
SergKis: gfilatov2002 пишет но только после их критического пересмотра Кто б возражал, я не буду. После выхода new версии, надо присмотреться (я пляшу от своей) к коду, пришлю.
SergKis: gfilatov2002 пишет переменную _HMG_MainCargo как #xtranslate _HMG_bFormInit => _HMG_MainCargo \[1] #xtranslate _HMG_bControlInit => _HMG_MainCargo \[2] #xtranslate _HMG_bControlErase => _HMG_MainCargo \[3] #xtranslate _HMG_bFormRelease => _HMG_MainCargo \[4] и затем вызываться в соответствующих функциях ядра при необходимости. Если _HMG_MainCargo новая переменная и не занята пользователями hmg, в проектах, я предложу в дальнейшем _HMG_MainCargo := oKeyData() _HMG_MainCargo:Set('bFormInit', Nil) _HMG_MainCargo:Set('bFormDestroy', Nil) _HMG_MainCargo:Set('bControlInit', Nil) _HMG_MainCargo:Set('bControlDestroy', Nil) и использовать _HMG_MainCargo:Do('bFormInit', p1, p2, p3) если много параметров, то IF _HMG_MainCargo:IsBLock('bFormInit') EVal(_HMG_MainCargo:Get('bFormInit', p1, p2, p3, p4, p5, ...) ENDIF или p1 := { x1, x2, ... } _HMG_MainCargo:Do('bFormInit', p1, p2, p3) _HMG_MainCargo:Do('bFormDestroy') _HMG_MainCargo:Do('bControlInit', p1, p2, p3) если много параметров, то IF _HMG_MainCargo:IsBLock('bControlInit') EVal(_HMG_MainCargo:Get('bControlInit', p1, p2, p3, p4, p5, ...) ENDIF или p1 := { x1, x2, ... } _HMG_MainCargo:Do('bControlInit', p1, p2, p3) _HMG_MainCargo:Do('bControlDestroy') и т.д. нет ограничений в будущих переменных #xtranslate _HMG_bFormInit => _HMG_MainCargo:Get('bFormInit') #xtranslate _HMG_bControlInit => _HMG_MainCargo:Get('bControlInit') #xtranslate _HMG_bControlDestroy => _HMG_MainCargo:Get('bControlDestroy') #xtranslate _HMG_bFormDestroy => _HMG_MainCargo:Get('bFormlDestroy') если _HMG_MainCargo уже в проектах занята, то надо ввести новую, типа _HMG_AppCargo
Vlad04: ООП , пусть да же псевдо, нельзя хоронить ни в коем случае. Наоборот - надо развивать. Это же удобно.
SergKis: Vlad04 пишет ООП , пусть да же псевдо, нельзя хоронить ни в коем случае. Наоборот - надо развивать. Это же удобно. Даже в мыслях нет. Объекты расширят возможности (могут добавиться команды псевдо ООП), сразу получите: - списки типов контролов на окно - списки контролов на окно - сможете получить массив объектов запрошенных типов\имен контролов по равно или вхождению и в цикле запустить этот список, к примеру для refresh гляньте пример, выкладывал выше, Toolbar в середине
полная версия страницы