Forth
http://fforum.winglion.ru/

Требуются контрпримеры
http://fforum.winglion.ru/viewtopic.php?f=2&t=3012		 Страница 2 из 2
Автор:  gudleifr [ Ср авг 13, 2014 17:00 ]
Заголовок сообщения:  Re: Требуются контрпримеры
mOleg писал(а):
Ну, допустим, есть отдельный словарь, в котором находится список всех обработчиков, имя каждого - это идентификатор события.
Именно. Есть словарь "событие-код", обрабатывающий ПОТОК нужных сообщений. От этого не уйти. Но этот словарь должен быть дополнен "полями" для "прочих событий" - инициализации, рисования, управления (пусть даже, они компилируются не в наш СЛОВАРЬ, а в структуры Винды). Так вот, заранее компилировать эту лабуду при написании программы, и иметь дополнительный словарь компактных "смысловых объектов", которые по потребности перекомпилировать в "визуальные" по месту?

Например, в примере про кнопку иметь в "смысловом словаре" только тройку "заголовок-действие", а при указании на то, что она вдруг понадобилась в каком-либо диалоге, рассчитать флаги-размеры исходя из политики выравнивания диалога и скомпилировать полную строку диалога в "визуальном словаре".
Автор:  mOleg [ Ср авг 13, 2014 17:21 ]
Заголовок сообщения:  Re: Требуются контрпримеры
gudleifr писал(а):
Так вот, заранее

А как это делается сейчас?
Я, вот, долго не занимался измышлизмами, выходит как-то так:
Код:
\ Обработчик сообщений окна
\ нельзя внутри использовать hwin и screen, если они USER переменные
\ здесь только фильтр для нужных сообщений, чтоб их не обрабатывал DefProc
CB: 'WINMES ( --> addr )
            DUP message @
            CASE wm:: mousemove   OF POFF ENDOF   \ обработку предполагаю делать в MAINLOOP
                 wm:: quit        OF  ENDOF       \
                 wm:: close       OF  ENDOF       \
                 wm:: keydown     OF  ENDOF       \
                 wm:: timer       OF  ENDOF
                 wm:: ncmousemove OF PON ENDOF
              DROP DefProc                        \ отдаем только, если сообщение не опознано
            ENDCASE ;

\ обработка событий (вне колбэка)
: Reflex ( addr --> )    1 msgs +!
         DUP message @
                                  ( addr --> )
         CASE wm:: mousemove   OF lParam @ GetCurXY ~pnt IS ~pointer ENDOF
              wm:: paint       OF DROP b>scr ENDOF

             ...........

            DDROP
\            TranslateMessage DROP
         ENDCASE ;
Автор:  gudleifr [ Ср авг 13, 2014 17:26 ]
Заголовок сообщения:  Re: Требуются контрпримеры
mOleg писал(а):
code...
Это как раз та часть "словаря", которая из-за сложноустроенности Винды "компилируется отдельно".
Т.е. управление и рисование win-объектов лежит "где-то рядом".
Автор:  mOleg [ Ср авг 13, 2014 17:40 ]
Заголовок сообщения:  Re: Требуются контрпримеры
gudleifr писал(а):
Это как раз та часть "словаря", которая из-за сложноустроенности Винды "компилируется отдельно".

это не особо важно. Трюк у меня тут другой - я не хочу в колбэке ничего обрабатывать, т.к. каждое окно у меня крутится в отдельном потоке и имеет собственные USER переменные (одноименные но разные у каждого потока).
Вот теперь, второй CASE можно заменить словарем, т.е. вместо Refelex будет поиск по словарю.
Не имею ничего против, а вы? 8)
Автор:  mOleg [ Сб авг 16, 2014 11:49 ]
Заголовок сообщения:  Re: Требуются контрпримеры
перенес лишнее, посему возвращаю кусок ответа:
Цитата:
gudleifr писал(а):
Речь о выборе между "полной компиляцией заранее" и "саморазворачиванием в процессе".

Использование словаря уже нам эту свободу даст (хотя нужна ли эта свобода? для меня ответ не очевиден). Однако, если пойти дальше, и вспомнить, что у нас есть шикарный контекст словарей, мы можем создать некую иерархию словарей и совсем произвольным образом управлять оконными объектами (убирая, добавляя, заменяя словари в контексте, можно добиться любого необходимого эффекта). Имхо, так.
Автор:  gudleifr [ Сб авг 16, 2014 12:21 ]
Заголовок сообщения:  Re: Требуются контрпримеры
mOleg писал(а):
Использование словаря уже нам эту свободу даст
Фигушки. Давайте попробую еще раз объяснить.
Чтобы работала некая фигня, надо создать некие структуры в памяти, привязать какие-то указатели и прочая мелочь...

С точки зрения FORTH эту процедуру имеет смысл считать "компиляцией", чтобы потом сигналы о состоянии фигни выглядели для FORTH "просто словами". Т.е. процедура опроса фигни (или реакции на сообщение от нее) та же старая добрая процедура FIND...

Конечно, можно честно прописать (скомпилировать) фигню еще в исходном коде. Например, при создании исполняемого Win-файла я в его конец втюхиваю т.н. Win-ресурсы (меню, диалоги, иконки...).
А можно проводить эту компиляцию "на лету" - во время работы программы. Например, я могу создать меню или диалог в памяти и сказать Винде: "Загрузи, как из ресурса".

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

Вопрос же собственно состоял в границах применимости первого и второго методов. И в том, чем второй метод должен "выглядеть с точки FORTH".
Автор:  mOleg [ Сб авг 16, 2014 19:33 ]
Заголовок сообщения:  Re: Требуются контрпримеры
gudleifr писал(а):
Фигушки. Давайте попробую еще раз объяснить.Чтобы работала некая фигня, надо создать некие структуры в памяти, привязать какие-то указатели и прочая мелочь...

Очень не хватает ТЗ, потому как на вопрос: некие + какие-то и прочая мелочь =
хочется ответить: = какая-то фиговина.
Возможно, в личном общении, когда можно очень просто уточнить тот или иной момент такая постановка задачи простительна и понятна.

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

gudleifr писал(а):
Например, при создании исполняемого Win-файла я в его конец втюхиваю т.н. Win-ресурсы (меню, диалоги, иконки...).А можно проводить эту компиляцию "на лету" - во время работы программы. Например, я могу создать меню или диалог в памяти и сказать Винде: "Загрузи, как из ресурса".

Ну, допустим, описание структуры и содержимого меню лежит в отдельном файле, картинки в другом, звуки в третьем и т.д. В чем проблема-то? Что мешает их подключить, когда станет надо?

Я правда не могу понять вашего описания проблемы, хотя и стараюсь. И, пожалуста, давайте без генотипов-фенотипов.
Страница 2 из 2 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/