Fw: Re: wfl grid
|
|
Привет
Обсуждение wfl. Begin forwarded message: Date: Sat, 9 Jun 2007 21:26:05 +0400 From: Dmitry Yakimov <[hidden email]> To: ygrek <[hidden email]> Subject: Re: wfl grid Привет, On Thu, 7 Jun 2007 13:27:10 +0300 ygrek <[hidden email]> wrote: > > > > 1. Мы в диалоге родителе вынуждены обрабатывать WM_SIZE и > > > отправлять его grid, можно сделать автоматически как в контроле > > > splitter. Суть приема в том что grid делает сабклассинг (attach > > > метод) к родителю, и фильтрует его сообщения в поисках WM_SIZE! > > > ПОсле обработки сообщение отправляем родителю. (ну и необходимо > > > смотреть чтобы сообщение которое получаем по сабклассингу точно > > > принадлежало перехваченному родителю). По WM_NCDESTROY wfl сделает > > > автоматический detach. > > > > Буду смотреть. Очень интересно. > > Посмотрел :) > Что-то мне не нравится делать grid отдельным контролом. инкапсулировать сущности друг от друга. > Сразу > вылезли какие-то глюки в GL-контроле, перестал отрисовываться. Хотя > может я что-то неправильно сделал.. Если бы можно было вклиниться в > обработку сообщений не создавай для этого отдельное окно... > Вообще >> пока спрятывание внутренностей вполне решается наследованием от > стандартных контролов - FrameWindow, Dialog, Panel с перегрузкой > соответствующих сообщений. Но конечно дублирование кода :( В WTL (есть такая gui либа для с++) сделано интересно - 1. Можно унаследоваться от родителя и перегрузить некоторые его методы так, что родитель будет вызывать методы потомка. Там сделано через шаблоны. Хорошо, в wfl это сделано через полиморфизм. 2. Самое важное - там каждый класс это фильтр сообщений. То есть например у нас есть библиотечный класс CWindow, мы делаем библиотечный класс CWindowWithHeader и наследуем CMyWindow : CWindowWithHeader : CWindow. и в CMyWindow мы сообщения которые не отбрабатываем отправляем родителю - CWindowWithHeader чтобы тот отрисовал header. Таким образом мы этот CWindowWithHeader можем использовать много раз и в том числе и для контролов. В wfl это делается через перегрузку метода message: : message ( lpar wpar msg hwnd -- result ) DEPTH >R OVER [CHAR] W SWAP sendWinMessage 0= IF inheritWinMessage THEN DEPTH R> SWAP - 3 = INVERT S" Wrong data stack size" SUPER abort ; здесь мы пытаемся послать себе сообщение. и если мы его не обработали (или сделали вид) то отправляем дальше, но отправляем не по цепочке классов, а сразу колбеку. то есть в wfl пока этот функционал по умолчанию отсутствует. А думаю его надо ввести, тогда создание компонент будет облегчено. Можно конечно сейчас делать это руками: : message ( lpar wpar msg hwnd -- n ) || CWinMessage msg || msg copy INHERIT 0= IF послать message базовому классу THEN ; Но и здесь неудобно! У нас нет множественного наследования как в c++. Например у нас есть grid. Допустим для того чтобы контрол сел в нее надо его унаследовать от объекта класса CGridCell. Но мы не можем вклинить CGridCell в уже написанную иерархию. Думаю надо ввести 1. В CWinBaseClass список объектов перехватчиков сообщений, модифицирующих поведение объекта 2. В message автоматически проходить сначала по ним, потом по списку родителя. Это заменит текущий хак с врезкой окна ребенка в очередь сообщений окна родителя. В случае с CSplitterController этот класс тогда будет таким контроллером и будет перехватывать WM_SIZE уже на законных основаниях. grid тоже будет таким контроллером. И будет перехватывать сообщения окна родителя контролов. И сам grid будет windowless, будет содержать только логику. И управлять CGridCell (это уже может быть окном) и окном внутри CGridCell. Буду копать в этом направлении. > > Предложение - унифицировать поведение create по всему коду, > сейчас в разных классах у него разная стековая нотация. Сложно > отслеживать. Например в activex в качестве параметра передаётся > дополнительная строка. Лучше сделать так - переименовать в > другое слово и вдобавок определить стандартный create с abort'ом > внутри. Мне думается сделать в grid-е отложенное создание контролов, > чтобы grid можно было определять вне класса. Т.е. во время задания > сетки запоминаются только классы контролов, а потом по сигналу create > к каждому из них полиморфно делается create. Тут и пригодится > одинаковый create, а доп. параметры передавать внутри классов-обёрток > над более общими контролами (например mediaplayer наследовать от > activex, всё равно к нему надо дополнительные методы делать). Вопрос - если запоминать только классы - как проще всего инициализировать контролы после создания? Например заполнить список или дерево значениями, задача встречающаяся в каждой программе. grid штука важная. поверху wtl и grid легко сделать скриптовый gui язык a la winlib но более продвинутый. > > В CWindow#getStrText течёт память - ALLOCATE без FREE Ага, fixed. > > Предлагаю для <= => использовать ~profit/lib/logic.f - уже выделено в > отдельный файл. Просто лишние isnt unique мельтешат согласен. > > ЗЫ Насчёт ~day/lib/clipboard.f письмо получал? Из-за более строгого > синтаксиса локалсов не компилится сейчас. Спасибо, исправил. > > -- > ygrek > Собственно todo list сейчас такой в wfl: * модульный перехват сообщений (?) * унифицировать create * получение нотификаций от active x компонент (важно, тогда можно делать интерфейс к программам на html) * проверить в Win98/95/Wine * отловить утечки * resizing framework * класс тулбара, UI update framework, связать меню и тулбар! * docking windows/toolbars * URLLabel проверить где отпустили * RAD gui (например просто визуальное редактирование диалогов с генерацией соотв. wfl кода) p.s. если не против - отправь это в spfdev, пусть народ почитает. Дмитрий. -- ygrek |
||||||||
attachment0 (187 bytes)
|
|
||||||||
|
|
|
||||||||
|
|
In reply to this post
by Andrey Cherezov
> А сейчас ведь уже и не пишет никто такие интерфейсы - не только > потому, что "не модно", столько потому, что кроме игр скоро вообще > ничего на локальный компьютер ставить не будут, всё из Сети работает > лучше. Для меня - нет. Не желаю доверять свои данные Сети... Ещё локальный веб-интерфейс - возможно. Но до сих пор пробовал несколько раз и ни разу субьективно не понравилось - нативные приложения-аналоги гораздо удобнее. -- ygrek |
||||||||
|
In reply to this post
by Andrey Cherezov
|
||||||||
|
|
Some javascript/style in this post has been disabled (why?)
Добрый день!Илья Абдрахимов: Остались "сферы" применения, где просто необходимо иметь автономную софтину (пример: сервисные программы для "всяческих" железяк). Сервисные программы для всяческих железок тоже уже чаще работают через веб. Вот уже не найдешь роутера (ADSL,WiFi,NAT,VoIP,какого угодно) без веб-интерфеса, например. В Технофортовых железках тоже Ethernet,IP и веб-серверы работают. ygrek: Ещё локальный веб-интерфейс - возможно. Но до сих пор пробовалТы можешь не замечать, что работаешь с HTML-интерфейсом. Уже много раз приводил пример: MSN Messenger и Windows Messenger - это на самом деле веб-интерфейсы (я это давно случайно заметил, когда из-за какой-то проблемы html-файл интерфейса побился и в окне вылезли html-тэги). Или вот (стилизация под инсталятор NSIS, но это HTA+acWEB):  Пример складской программы (её спользуют как через веб, так и локально в hta):  Или вот eChat:  (заказчик просил клонировать iChat, но с XMPP). Чем не обычные GUI? Но это все HTML. |
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
In reply to this post
by ygrek-3
> > Что-то мне не нравится делать grid отдельным контролом. > > В том то и дело что хочется сделать wfl так чтобы можно было легко > инкапсулировать сущности друг от друга. Такая печальная история. Реализовываю табы. Помещаю на одну вкладку GL контрол. Не отображается - хотя процедура рисовки работает и все хэндлы контекстов корректные. При создании контрола делал 0 SELF CGLControl create, т.е. родителем выступает главное окно. Если же поставить вместо SELF обьект TabControl'а, то GL отрисовывается. Отсюда мораль - надо либо делать grid полноценным окном и всё его содержимое форсировать в child-контролы этого grid'а (можно например SetParent'ом после создания), либо для всех контролов-контейнеров предусматривать исключения, либо всегда требовать кадый табконтрол отедльным классом наследованным от стандартного (тогда SELF будет указывать то что надо), либо найти способ отображать GL-окно как есть во вкладке... Смотрел winlib - там нигде похоже таких заморочек нет и все контролы принадлежат главному окну. > Но и здесь неудобно! У нас нет множественного наследования как в c++. > Например у нас есть grid. Допустим для того чтобы контрол сел в нее > надо его унаследовать от объекта класса CGridCell. Но мы не можем > вклинить CGridCell в уже написанную иерархию. А почему нет множественного наследования - обьединить списки методов/переменных двух классов - возможно такое? Уже несколько раз просто просилось. > Вопрос - если запоминать только классы - как проще всего > инициализировать контролы после создания? Например заполнить список > или дерево значениями, задача встречающаяся в каждой программе. Я опять в раздумьях. Если делать откладываемое создание то вот такая запись уже проблематична CEventButton put -yspan 100 -ymin! S" Min height: 100" -text! LAMBDA{ S" button pressed!" ROT => showMessage } -command! т.к. в момент вызова WinAPI для установки текста контрола само окно (кнопки) ещё не создано. Можно конечно попытаться отложить этот код, но стоит ли игра свеч? -- ygrek |
||||||||
|
|
In reply to this post
by Илья Абдрахимов
|
||||||||
|
In reply to this post
by ygrek-3
|
||||||||
|
|
> Есть какие-либо пожелания на рефакторинг кроме унификации create? Вот когда будет окончательный вариант - наверняка что-то ещё вспомнится :) > А нужно ли делать в стиле winlib? Может будет эффектнее что-то новое > придумать? Основа - обьектная модель wfl. Поверх неё делаются макросы а-ляя winlib - просто синтаксический сахар. Это сейчас так. Если придумается более удобные схемы задания интерфейса - её можно будет реализовать на той же основе. -- ygrek |
||||||||
|
In reply to this post
by Andrey Cherezov
|
||||||||
|
|
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
