On-line: гостей 1. Всего: 1 [подробнее..]
АвторСообщение
gfilatov
модератор




Пост N: 699
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 29.01.08 13:59. Заголовок: Новая версия Расширенного релиза библиотеки MiniGUI (часть VI ) (продолжение)


Начало темы находится здесь, а теперь

АНОНС * АНОНС * АНОНС * АНОНС * АНОНС

Готовится к опубликованию новая сборка №48, которая выйдет в конце недели.
Если у Вас есть интересные наработки для включения в новый релиз, то сейчас самое удобное время для их отправки мне

Кратко, что нового:

- исправление обнаруженных ошибок и неточностей кода;
- новый класс HEADERIMAGE для Grid и Browse;
- свойство Address в Hyperlink может теперь открывать папку или файл на диске;
- добавлен NOTABSTOP класс для Browse;
- поддержка пользовательских компонентов (заимствована из оффициального релиза);
- расширения и исправления в библиотеках TsBrowse и PropGrid;
- обновлены сборки Харбор и HMGS-IDE;
- новые и обновленные старые примеры (как обычно ).




Спасибо: 5 
Профиль
Ответов - 300 , стр: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 All [только новые]


SergKis
постоянный участник




Пост N: 1529
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 13.06.17 11:36. Заголовок: Петр пишет Присмотр..


Петр пишет
 цитата:
Присмотритесь к 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 кода в старом добром процедурном стиле решаете нужную вам проблему"
К чему это я и о чем ? Снова о "религии", понимал, что "лезу в чужой монастырь со своим уставом" предложением ... Видно мы по разному крестимся.
У себя, я получил, того чего не хватало мне в МиниГуи, для других ...




Спасибо: 0 
Профиль
gfilatov2002
moderator




Пост N: 1115
Зарегистрирован: 11.02.10
ссылка на сообщение  Отправлено: 13.06.17 13:51. Заголовок: SergKis пишет: От д..


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
   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

Вместо 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. Мне симпатичен Ваш подход, но совместное использование псевдо-ООП и настоящих классов порождает ненужное дублирование в ядре библиотеки...

Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1530
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 13.06.17 19:12. Заголовок: gfilatov2002 пишет и..


gfilatov2002 пишет
 цитата:
использование псевдо-ООП и настоящих классов порождает ненужное дублирование в ядре библиотеки...


Лучше иметь дублирование, чем не иметь ничего, речь идет о разрезах контролов по окнам, то что в МиниГуи кроме ascan ничего нет (доступ к контролам), вызывает удивление, база есть а разрезов, по окнам нет. Это как DBFCDX только с Locate, без индексов и тегов, scope. Если нужен индекс\тег, то стройте его (клиенты) сами, там С структуры, там учебник по С и вперед. Т.е. что бы получить что то с МиниГуи пользователь должен досконально знать организацию и цепочки (itemoв), а если с версией это меняется. Словом недоработка, по моему мнению, длящаяся годами.

 цитата:
Прошу без обид...


Обиды нет, есть непонимание, почему просто не сказать, систему сообщений берем от Петра. Будет ли она лучше, посмотрим.

Что предложено сечас, полная изолированность конрола, т.е. он о себе знает все, где что брать, как отображать и ничего не знает о др. конролах окна. И так каждый контрол, т.е. создана база контролов, в которых можно события пронумеровать с 1 и далее (на каждый контрол), наложив на них одинаковое действие, как в примере. В программе нет ни одного места использования контрола напрямую, только через сообщения. Окно так же ничего не знает о поведении контролов (списки-разрезы знает). На окно мы ставим с 1 и далее события, которые в основном раздают сообщения. Т.е. с контролами общаемся только через события окна, никаких прямых сообщений из разных мест прогр. нет, только через окно, так же поступаем и с др. окном, надо сделать refresh, посылаем сообщение окну, а оно контролам групповые сообщения.

 цитата:
Сделал таким образом:


Думаю это все не очень нужно (мне точно), так сказал, наверно сгоряча. Зачем это, если можно исходники подправить, не сложно. Думается и другим корячится вряд ли захочется, тем более, что исп. OnInit и OnRelease можно, но это большая морока делать в КАЖДОМ окне, а до OnInit от _DefineWindow... как до луны.




Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1531
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 13.06.17 19:38. Заголовок: PS совместное исполь..


PS

 цитата:
совместное использование псевдо-ООП и настоящих классов порождает


По мне, так положительные эмоции, можно написать с псевдо ООП, будет крутиь макро (чуть медленнее), но сделает.
Можно исп. объект, будет ТОЖЕ работать, возможно, чуть быстрее, а при передаче его (объкта) в блок кода, так и писать удобнее, а с блоками сообщений (моя версия) именно так и происходит. У пользователя МиниГуи есть выбор, как писать, а сейчас его нет. Пишем только псевдо ООП, а если дурит препроцессор, в небольшом примере идет, в родной проге приходится уходить с псевдо на функции. Или сразу писать функциями. Тут тоже вопрос, а что лучше тогда ?

Спасибо: 0 
Профиль
Петр
постоянный участник


Пост N: 1521
Зарегистрирован: 09.10.06
ссылка на сообщение  Отправлено: 13.06.17 21:56. Заголовок: SergKis пишет: Прис..


SergKis пишет:

 цитата:
Присмотрелся


Знаете, я ровным счетом ничего не понял, что вы хотите сказать. Прямо какой-то поток сознания.
Вы случайно во второй цитате или не видели?
И кто вам посоветовал "как "в старом добром процедурном стиле" писать свои классы"?
Вы можете вызвать TaskDialog из xhb? Рад за вас
И что у вас вызвало столько эмоций в методе OnDestroyed?


Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1532
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 14.06.17 10:05. Заголовок: Петр пишет Знаете, я..


Петр пишет
 цитата:
Знаете, я ровным счетом ничего не понял, что вы хотите сказать.


Боюсь не поймете, но попробую объяснить.
На мое "с xhb дел не имел (кроме сборки letodb) никаких" и sourcе кодером становиться 'совершенно не стремлюсь" (xhb не нужен мне), вы, явно ерничая, даете советы (см. выше), особенно порадовало именно после или.
Ваше "Вот, к примеру, в xhb реализация деструктора обьекта приводит к повреждению HVM памяти." навело на мысль, что просто свойство\переменную в Nil, недостаточно (со времен clipper хватало) и это вызвало эмоции, как же я работал до этого.
И я, явно ерничая, побежал смотреть, как вы, применяете на практике, то что советуете ...
Ваше "читать xhb-diff ... нужно знать их отличия (xhb-diff)", вызывает желание посоветовать почитать инструкцию по эксплуатации автомашины ГАЗ-51, там тоже есть отличия, при переключении передач от автомобиля ВАЗ.

 цитата:
Вы можете вызвать TaskDialog из xhb? Рад за вас


Опять фантазируете, ерничаете, я только сказал, что в xhb есть H_TaskDialog.prg, .т.е. включен в проект, работает он или нет, это др. вопрос.

 цитата:
Прямо какой-то поток сознания.


Надеюсь, я его расшифровал


Спасибо: 0 
Профиль
Петр
постоянный участник


Пост N: 1522
Зарегистрирован: 09.10.06
ссылка на сообщение  Отправлено: 14.06.17 13:43. Заголовок: SergKis пишет: Ваше..


SergKis пишет:

 цитата:
Ваше "Вот, к примеру, в xhb реализация деструктора обьекта приводит к повреждению HVM памяти." навело на мысль


Вы не правильно интерпретировали мою подсказку.

 цитата:
Опять фантазируете, ерничаете, я только сказал, что в xhb есть H_TaskDialog.prg, .т.е. включен в проект


Нет, но могу вам напомнить, что я не мантайнер MiniGUI.
К тому же "включен в проект" можно понимать по разному, то ли это значит, что файлы включены в поставку (архив/инсталятор), то ли используется файлом сборки (make файл/bat).
В поставе "xhb (за деньги)" используется 2 вариант (с классами там действительно все в порядке )


Спасибо: 0 
Профиль
gfilatov2002
moderator




Пост N: 1116
Зарегистрирован: 11.02.10
ссылка на сообщение  Отправлено: 14.06.17 17:22. Заголовок: Петр пишет: могу ва..


Петр пишет:

 цитата:
могу вам напомнить, что я не мантайнер MiniGUI


Ребята, давайте жить дружно

Подготовил очередную бетку для новой сборки 17.06 со следующим списком изменений
Скрытый текст

Благодарю за оперативную помощь в подготовке этой сборки SergKis и Петра
Без Вашей поддержки ничего бы не вышло...

Кстати, команды ON APPEVENT/EMIT были вдохновлены SergKis
Петр пишет:

 цитата:
SergKis подбросил интересную идею, попробую реализовать что-то подобное

ON APPEVENT [NAME] <evName> [ID <id>] | [AUTO] EVAL <{block}> [ONCE]
EMIT <evName>



Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1533
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 14.06.17 19:27. Заголовок: Петр xhb, меня не и..


Петр
xhb, меня не интересует в любом виде. Я, не распаковывая, глянул архив xhmg1705... и увидел, что увидел.
Глянул команды из hbclass.ch и сделал вывод, что класс TWndData полностью отвечает требованиям xhb,
т.е. не требует дополнительных #ifdef XHARBOUR для работы в xhb.
Посмотрел и TsBrowse на предмет #ifdef их всего несколько строк, причем только 1 реальная, связанная с функ. CToT.
Говорю, просто для информации, что и как посмотрел.

Действительно, давайте закончим эту не интересную дискуссию.

Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1534
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 14.06.17 22:49. Заголовок: gfilatov2002 пишет П..


gfilatov2002 пишет
 цитата:
Прошу без обид...



 цитата:
Мне симпатичен Ваш подход, но совместное использование псевдо-ООП и настоящих классов порождает ненужное дублирование в ядре библиотеки..


Я, скорее, рассердился на себя. Мой товарищ по работе, сразу сказал, не трать время, ни один класс окна и контрола не будет принят добровольно в МиниГуи, т.к. он практически хоронит псевдо ООП (Andrey пишет
 цитата:
Удобней кстати для использования.

). Я, наивный, не поверил, т.е. "хотел как лучше ...". Так что я сильно рассердился на себя.

Спасибо: 0 
Профиль
gfilatov2002
moderator




Пост N: 1117
Зарегистрирован: 11.02.10
ссылка на сообщение  Отправлено: 15.06.17 11:51. Заголовок: SergKis пишет: я си..


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 (форма курсора) включены в следующую сборку
На все требуется время для осмысления...

Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1535
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 15.06.17 15:09. Заголовок: gfilatov2002 пишет о..


gfilatov2002 пишет
 цитата:
отсутствие внятной модели классов...
наличие в предлагаемом коде избыточных пользовательских методов, которые должны добавляться наследованием от базового класса.


Я считал, что работаем в процедурной среде МиниГуи, а не среде грамотно спланированной цепочки классов.
Т.к. практически исключил наследование. Как это делать в _HMG_aControlMiskData0[ i ][1] := <объект контрола> ?
По этой причине сделал избыточные (немного) классы. Т.е. я отверг изначально oApp->oWindow->oWindowDialog ...
Представленные классы - это скорей сложные процедуры\функции. Расширение свойств, методов - через функции объектов и
примерно так, добавляем переменную в объект и присваиваем значение := oKeyData() получая сразу контейнер данных и исп. блоки с возможностью проводить групповые операции Eval() или Sum().
Т.е. с моделью я определился, она процедурная, как и МиниГуи.

 цитата:
смешивание визуальных и невизуальных методов в классах


хотелось бы конкретики

По названиям, абсолютно, без разницы как будут называться, были бы в наличии.


Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1536
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 15.06.17 15:17. Заголовок: PS Потом, я не знаю,..


PS
Потом, я не знаю, будем делать и повторять в классе TAppData свойства\методы из App. ... псевдо ООП команд ?
Если будем, сделать не сложно, тогда там будет регистрация окон (как контролов в окне), т.е. свои
:oName, :oHand с доступом. Вопрос надо ли это сейчас ?

Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1537
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 15.06.17 15:26. Заголовок: PS Если вопрос насле..


PS
Если вопрос наследования на первом месте (или замена класса полностью в переменной _HMG_aControlMiskData0[ i ][1])?,
делаем это (к примеру) в функции oWndData(...). Если к примеру _HMG_bWndObject := bBlock выполняем и возвращаем
что она дает из ф-ии oWndData, если не задан - как сейчас. Все по МиниГуи-шному


Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1538
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 15.06.17 15:51. Заголовок: gfilatov2002 пишет ..


gfilatov2002 пишет
 цитата:
в отличие от того же грамотно спланированного HwGui.


Основная причина - она брошена. В 2009 году она была 2004\5 года сборки.
Сейчас ее состояние (внутреннее) практически не изменилось, только перевелась на hb3.2 с небольшими улучшениями и сменой названий функции. Потом, многие вещи оставлены на очень низком уровне - что надо собирайте сами, а инстукции\примеров нет, "догадайся мол сама". Мое мнение


Спасибо: 0 
Профиль
gfilatov2002
moderator




Пост N: 1118
Зарегистрирован: 11.02.10
ссылка на сообщение  Отправлено: 15.06.17 16:16. Заголовок: SergKis пишет: Все ..


SergKis пишет:

 цитата:
Все по МиниГуи-шному


Замечательно, тогда присылайте мне по почте предлагаемые изменения, будем рассмативать их для будущих сборок

SergKis пишет:

 цитата:
Основная причина - она брошена.


Согласен. Но чтобы этого не случилось с Минигуи, необходимы стимулы, в т.ч. Ваша поддержка и предложения по улучшению кода.
Я не устаю повторять, что всегда открыт для новых улучшений, но только после их критического пересмотра

Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1539
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 15.06.17 17:17. Заголовок: gfilatov2002 пишет н..


gfilatov2002 пишет
 цитата:
но только после их критического пересмотра


Кто б возражал, я не буду.
После выхода new версии, надо присмотреться (я пляшу от своей) к коду, пришлю.

Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1540
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 16.06.17 07:05. Заголовок: gfilatov2002 пишет п..


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




Спасибо: 0 
Профиль
Vlad04
постоянный участник


Пост N: 715
Зарегистрирован: 13.10.05
ссылка на сообщение  Отправлено: 16.06.17 08:20. Заголовок: ООП , пусть да же п..


ООП , пусть да же псевдо, нельзя хоронить ни в коем случае. Наоборот - надо развивать. Это же удобно.


Спасибо: 0 
Профиль
SergKis
постоянный участник




Пост N: 1541
Зарегистрирован: 17.02.12
ссылка на сообщение  Отправлено: 16.06.17 09:11. Заголовок: Vlad04 пишет ООП , п..


Vlad04 пишет
 цитата:
ООП , пусть да же псевдо, нельзя хоронить ни в коем случае. Наоборот - надо развивать. Это же удобно.


Даже в мыслях нет.
Объекты расширят возможности (могут добавиться команды псевдо ООП), сразу получите:
- списки типов контролов на окно
- списки контролов на окно
- сможете получить массив объектов запрошенных типов\имен контролов по равно или вхождению и
в цикле запустить этот список, к примеру для refresh
гляньте пример, выкладывал выше, Toolbar в середине

Спасибо: 0 
Профиль
Ответов - 300 , стр: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 All [только новые]
Тему читают:
- участник сейчас на форуме
- участник вне форума
Все даты в формате GMT  3 час. Хитов сегодня: 16
Права: смайлы да, картинки да, шрифты да, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет