Отправлено: 30.05.17 18:02. Заголовок: Кто-нибудь пользуется HwGUI под Windows?

Попробовал. Все вроде здорово -- грамотно написана, ООП с внятной иерархией классов, куча приятных возможностей, хоть какое-то описание (правда, очень лаконичное).
Но столкнулся в процессе освоения с проблемой, которую не смог сам разрулить (любой наследник HDialog при попытке изменить его размер на экране сразу вырубает программу) -- и кирдык.
Ветка на этом форуме умерла год назад, Александр Кресин на письма не отвечает, в SourceForge ничего давно не происходит.
Может, ищу не там, и где-то есть место, где тусуются счастливые пользователи HwGUI?

 Отправлено: 30.05.17 21:00. Заголовок: George Вы уверены, ..

George
Вы уверены, что можно наследовать, при наличии таких переменных ?

 
 STATIC aSheet := Nil 
 STATIC aMessModalDlg := { ; 
       { WM_COMMAND,    { |o,w,l|onDlgCommand( o,w,l )    } }, ; 
       { WM_SYSCOMMAND, { |o,w,l| onSysCommand( o, w, l ) } }, ; 
       { WM_SIZE,       { |o,w,l|hwg_onWndSize( o,w,l )   } }, ; 
       { WM_ERASEBKGND, { |o,w|onEraseBk( o,w )           } }, ; 
       { WM_PSPNOTIFY,  { |o,w,l|onPspNotify( o,w,l )     } }, ; 
       { WM_HELP,       { |o,w,l|onHelp( o,w,l )          } }, ; 
       { WM_ACTIVATE,   { |o,w,l|onActivate( o,w,l )      } }, ; 
       { WM_INITDIALOG, { |o,w,l|InitModalDlg( o,w,l )    } }, ; 
       { WM_DESTROY,    { |o|hwg_onDestroy( o )           } }  ; 
       } 
  
    // Class HDialog 
  
 CLASS HDialog                                                  INHERIT HWindow 
 

 Отправлено: 31.05.17 04:07. Заголовок: SergKis Спасибо за о..

SergKis Спасибо за ответ.
Моя уверенность в связке Harbour + ООП + HwGUI пока близка к нулю из-за отсутствия опыта работы с ней.
Приведенные Вами конструкции показались мне вполне невинными с точки зрения наследования, хотя, по-моему, смотрелись бы лучше как CLASS VAR. Вероятно, я чего-то не понимаю. А что в них не так?
Кстати, нечто подобное есть в hcwindow.prg, при том, что от HCustomWindow наследуется половина классов HwGUI.
А если от классов типа HDialog нельзя наследоваться, то вообще непонятно, зачем нужен HwGUI. Вряд ли автор ставил перед собой такую цель. Мне кажется, что поддержка "честного" ООП (по крайней мере, декларируемая) остается главным преимуществом HwGUI перед множеством альтернативных систем Harbour + GUI + Windows (у HbQt нет 100% совместимости с Harbour по управлению памятью).

 Отправлено: 31.05.17 09:33. Заголовок: George http://www.k..

George
http://www.kresin.ru/hrbfaq_3.html#Doc3 :

цитата:

Класс может быть объявлен как наследник от одного или нескольких родителей (особенности multiinheritance - множественного наследования мы рассмотрим позже) при помощи служебного слова FROM или INHERIT. Это значит, что он получает от родительского класса весь его набор переменных и методов (кроме помеченных как HIDDEN). Любой из унаследованных методов может быть переопределен. При этом родительский метод может быть вызван как Super:<methodName>() или ::<cSuperClass>:<methodName>() (если он не HIDDEN). Отмечу еще одну интересную особенность, связанную с наследованием. Если в порожденном классе есть переменная с тем же именем, что и в родительском, то каждый объект содержит две переменных с этим именем. К одной из них следует обращаться obj:<varName>, к другой - obj:<cSuperClass>:<varName>. Класс может быть объявлен как STATIC - т.е. он не может использоваться вне текущего модуля.

т.е. наследование в др. prg, делает невидимыми STATIC переменные (как с Клиппера еще повелось) ...
Можно попробовать в родном prg это сделать.
Наши 2-а подхода к hwg (2009, 2016) выявили хорошую работу Main (SDI) и HDialog окон, MDI никак, а нам он нужен был основным и слабоватые browse: многострочность шапки есть (но задается очень специфички) с многострочностью строк (уже подзабыл), а с footerom тоже беда. Словом надо было вкладываться в код (начиная с "родного") не по детски и сразу попадаешь в ситуацию разбалансировки версии, т.е. с выпуском новой надо .... (где то тут на сайте я писал Кресину о бяках и даже примеры выкладывал, но по реакции понял что win версия не самое главное, так показалось)
Возможно hwg linuks работает лучше и где то, раньше, видел на бразильских сайтах что то.
Это мое мнение.

 Отправлено: 31.05.17 10:00. Заголовок: George А.Кресин пиш..

George
А.Кресин пишет

цитата:

Первоначально, до релиза 1.3, HwGUI не использовал классы, больше того, я даже декларировал это, как одну из особенностей библиотеки - все хранилось в массивах. Главным причиной было стремление к лучшей производительности и к стабильности. Реализация классов в Harbour тогда еще хромала, оставались каки-то ошибки и я не хотел лишней головной боли. Ну и, конечно, доступ к элементам массива осуществляется быстрее, чем к данным объекта... Но позже я пришел к решению переписать HwGUI под использование ООП - чтобы сделать конечный код, код приложения более понятным и структуированным. К тому времени и c реализацией классов в Harbour дела поправились. Поэтому, начиная с релиза 2.0 HwGUI основан на ООП. ...

Думаю исторические закавыки остались.

 Отправлено: 31.05.17 10:09. Заголовок: PS не смотря на "..

PS
не смотря на "ООП с внятной иерархией классов, куча приятных возможностей" основной реализацией языка являются DEFINE ... команды, что изначально отвергает наследование, т.е. если наследуете расходитесь с DEFINE или пишете новые или ...

 Отправлено: 31.05.17 10:39. Заголовок: SerkKis пишет многос..

SerkKis пишет

цитата:

многострочность шапки есть (но задается очень специфички)

Уже подзабыл, с многострочностью шапки все в порядке,
Специфичность в организации Super header над шапкой.

 Отправлено: 31.05.17 11:10. Заголовок: PS Думаю, в основе h..

PS
Думаю, в основе hwg "наследования" лежит принцип модификации существующего объекта, исхожу из наличия
/* *$Id: miscfunc.prg 2331 2014-12-24 08:22:58Z alkresin $ */ функций:
FUNCTION ADDMETHOD( oObjectName, cMethodName, pFunction )
FUNCTION ADDPROPERTY( oObjectName, cPropertyName, eNewValue )
FUNCTION REMOVEPROPERTY( oObjectName, cPropertyName )
Рад был бы ошибиться.

 Отправлено: 31.05.17 17:46. Заголовок: SergKis Спасибо за п..

SergKis Спасибо за подробный ответ.
По моему мнению,
1. STATIC в модуле HDialog не напрягают, поскольку с ними работает только HDialog (а не его наследники). Инкапсуляция, однако. В методах наследника я к ним не обращаюсь. Конечно, второй из них можно было бы "высунуть" для наследников, но это дело Автора. Кстати, я попробовал перенести второй из них в INIT класса HDialog -- ровно ничего не изменилось, как и следовало ожидать.
2. Под всеми #DEFINE в HwGUI лежат обращения к соответствующим классам, т.е. это не "основная реализация", а просто красивая оболочка. Я ими вообще не пользовался. Было бы неплохо затолкать туда что-то вроде clause CLASSNAME, но можно и без этого.
3. Судя по исходникам, в основе наследования HwGUI лежит все-таки стандартная система классов Harbour. Упомянутые Вами функции ADDMETHOD, ADDPROPERTY и REMOVEPROPERTY, к счастью, в самом HwGUI нигде не испоьзуются (только в contrib от бразильцев), и сам Автор высказывался на эту тему в ChangeLoge.
4. Большое спасибо за упомянутые Вами "бяки". До большинства из них я еще не добрался, но они, несомненно, существуют. Некоторые видны при беглом просмотре исходников (конструкции типа IF oParent:Classname() == "HDIALOG" в HEdit). По-моему, для этого и придумано наследование в ООП -- изменять кривое поведение классов в их наследниках, не дергая Автора.

 Отправлено: 31.05.17 18:13. Заголовок: George пишет В метод..

George пишет

цитата:

В методах наследника я к ним не обращаюсь

Напрямую, возможно, не обращаетесь, но по внешнему виду STATIC aMessModalDlg это обработчик событий, т.е. ваше Resize должна пробегать через него.
Первым делом мы избавились от STATIC в VAR, пришлось еще что то править в родных исходниках (немного).
В тестах, приближенных, к задачам с HDialog проблем не было (modal\child работали).
Но, к сожалению, результат - с компа удалил из головы выбросил (и так уже места мало ). Для себя тему закрыл.

 Отправлено: 02.06.17 06:17. Заголовок: Глянул в код поглубж..

Глянул в код поглубже. По-моему, большая проблема HwGUI -- наличие "винегрета" из нормальных методов классов и из функций, которые пытаются делать то же самое, принимая объект как параметр. При этом обращаются эти функции с объектами иногда весьма вольно, вызывая их суперклассы и т.д. Вероятно, это наследие "до-ООПшного" периода, о котором писал Автор.
Проделал небольшой рефакторинг, чисто формальный: преобразовал все функции, работающие с "оконными" объектами, в методы соответствующих классов. Никакую логику не менял, все переменные STATIC оставил как есть -- они вполне на своем месте.
После этого наследование "оконных" классов, в том числе HDialog, заработало как-то само собой без каких-либо проблем.

 Отправлено: 02.06.17 07:59. Заголовок: George пишет После э..

George пишет

цитата:

После этого наследование "оконных" классов, в том числе HDialog, заработало как-то само собой без каких-либо проблем.

SergKis пишет

цитата:

Первым делом мы избавились от STATIC в VAR, пришлось еще что то править в родных исходниках (немного).

Об одном и том же.
Но сразу разошлись с "родной" версией, не говоря уже о линуксовой.
Если хватит возможностей browseров, то удачи.

 Отправлено: 02.06.17 15:25. Заголовок: SergKis пишет: Об од..

SergKis пишет:

цитата:

Об одном и том же

Не об одном и том же. STATIC модулей и STATIC классов не правил нигде, поскольку они нужны именно в таком виде. Некоторые нужны для сохранения данных вне объектов, чтоб защитить от GC (а где еще их сохранять?), другие -- чтоб не таскать их за каждым объектом. Они безопасны по наследованию, поскольку инкапсулированы в модули или классы.

SergKis пишет:

цитата:

Но сразу разошлись с "родной" версией

Расхождение с "родной" версией меня нисколько не беспокоит. Мне просто нужна удобная, понятная и работающая система Harbour+ООП+GUI здесь и сейчас. При всем уважении к Александру Кресину, проделавшему такую огромную работу, он все-таки оставил ее без всякой поддержки. При этом весь ее код открыт, прекрасно написан и кажется достаточно понятным всем, кто имел дело с ООП и WinAPI. Если Автор когда-нибудь решит вернуться к проекту, буду рад потратить пару часов на поиск нововведений и перенос их к себе, или убедить его принять мои изменения.

SergKis пишет:

цитата:

не говоря уже о линуксовой

А вот с этим я и правда поостерегусь пока. Реализована на GTK, соответственно, несовместимость по управлению памятью, приводящая к неконтролируемым утечкам.

SergKis пишет:

цитата:

Если хватит возможностей browseров, то удачи

Спасибо за пожелание. Изначально исходил из того, что в HwGUI мне не хватит нигде ничего. Надеюсь решить эту проблемы посредством рук, головы, ООП с работающим наследованием и примеров из других подобных систем.

Удачи и Вам.