Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 14:33

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - Требуются контрпримеры
Автор Сообщение
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
gudleifr писал(а):
Фигушки. Давайте попробую еще раз объяснить.Чтобы работала некая фигня, надо создать некие структуры в памяти, привязать какие-то указатели и прочая мелочь...

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

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

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

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

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

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

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

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

Вопрос же собственно состоял в границах применимости первого и второго методов. И в том, чем второй метод должен "выглядеть с точки FORTH".
Сообщение Добавлено: Сб авг 16, 2014 12:21
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
перенес лишнее, посему возвращаю кусок ответа:
Цитата:
gudleifr писал(а):
Речь о выборе между "полной компиляцией заранее" и "саморазворачиванием в процессе".

Использование словаря уже нам эту свободу даст (хотя нужна ли эта свобода? для меня ответ не очевиден). Однако, если пойти дальше, и вспомнить, что у нас есть шикарный контекст словарей, мы можем создать некую иерархию словарей и совсем произвольным образом управлять оконными объектами (убирая, добавляя, заменяя словари в контексте, можно добиться любого необходимого эффекта). Имхо, так.
Сообщение Добавлено: Сб авг 16, 2014 11:49
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
gudleifr писал(а):
Это как раз та часть "словаря", которая из-за сложноустроенности Винды "компилируется отдельно".

это не особо важно. Трюк у меня тут другой - я не хочу в колбэке ничего обрабатывать, т.к. каждое окно у меня крутится в отдельном потоке и имеет собственные USER переменные (одноименные но разные у каждого потока).
Вот теперь, второй CASE можно заменить словарем, т.е. вместо Refelex будет поиск по словарю.
Не имею ничего против, а вы? 8)
Сообщение Добавлено: Ср авг 13, 2014 17:40
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
mOleg писал(а):
code...
Это как раз та часть "словаря", которая из-за сложноустроенности Винды "компилируется отдельно".
Т.е. управление и рисование win-объектов лежит "где-то рядом".
Сообщение Добавлено: Ср авг 13, 2014 17:26
  Заголовок сообщения:  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 ;
Сообщение Добавлено: Ср авг 13, 2014 17:21
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
mOleg писал(а):
Ну, допустим, есть отдельный словарь, в котором находится список всех обработчиков, имя каждого - это идентификатор события.
Именно. Есть словарь "событие-код", обрабатывающий ПОТОК нужных сообщений. От этого не уйти. Но этот словарь должен быть дополнен "полями" для "прочих событий" - инициализации, рисования, управления (пусть даже, они компилируются не в наш СЛОВАРЬ, а в структуры Винды). Так вот, заранее компилировать эту лабуду при написании программы, и иметь дополнительный словарь компактных "смысловых объектов", которые по потребности перекомпилировать в "визуальные" по месту?

Например, в примере про кнопку иметь в "смысловом словаре" только тройку "заголовок-действие", а при указании на то, что она вдруг понадобилась в каком-либо диалоге, рассчитать флаги-размеры исходя из политики выравнивания диалога и скомпилировать полную строку диалога в "визуальном словаре".
Сообщение Добавлено: Ср авг 13, 2014 17:00
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
gudleifr писал(а):
Т.е. до обработчика еще очередь не дошла (он будет отдельно привязываться к идентификатору 3006), а достаточно внушительный объект уже "откомпилирован" - координаты, размеры, флаги... (Это все будет использовано Виндой при отрисовке кнопочки).

Ну, допустим, есть отдельный словарь, в котором находится список всех обработчиков, имя каждого - это идентификатор события. Возникло событие - выполнилось имя? Я правильно понимаю ваше:
gudleifr писал(а):
Допустим, я рассматриваю поток событий сообщений Windows как ПОТОК. Т.е. получение системного сообщения после прохождения некоторого FIND заканчивается вызовом некоторого слова.
Сообщение Добавлено: Ср авг 13, 2014 16:45
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
mOleg писал(а):
Зачем? Почему обязательно кучу входных точек? Нафига сей мазохизм?

Например, рассмотрим пример создания кнопочки в Win-API в окне диалога:
Код:
3006 13 52 10 141 HEX 50010001 DECIMAL S" Say Hello" BUTTON-IS

Т.е. до обработчика еще очередь не дошла (он будет отдельно привязываться к идентификатору 3006), а достаточно внушительный объект уже "откомпилирован" - координаты, размеры, флаги... (Это все будет использовано Виндой при отрисовке кнопочки).
Кроме того, кнопочка может быть дополнительно быть привязана к спискам табуляций, разрешающих/запрещающих зависимостей и пр. Их придется "компилировать" отдельно.
Так что, компиляция полного описания визуального объекта на все случаи жизни - техника по-умолчанию, а не извращение.
Если хотите, плата за неумение отличить генотип от фенотипа.
Сообщение Добавлено: Ср авг 13, 2014 16:32
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
gudleifr писал(а):
следует КОМПИЛИРОВАТЬ не одну процедуру, а некий "визуальный объект", с кучей входных точек для всех потребных эвентов и пропертей,

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

Или речь о сложности ради сложности?
Сообщение Добавлено: Ср авг 13, 2014 16:22
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
mOleg писал(а):
ок, тогда в чем проблема?

gudleifr писал(а):
следует КОМПИЛИРОВАТЬ не одну процедуру, а некий "визуальный объект", с кучей входных точек для всех потребных эвентов и пропертей, или привязывать процесс компиляции к рисованию Control, записывая в словарь только обработчик, а пропертя не компилировать - применять немедленно.
Сообщение Добавлено: Ср авг 13, 2014 16:13
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
gudleifr писал(а):
В случае другого эвента, т.е. другого сообщения/события.

ок, тогда в чем проблема?

gudleifr писал(а):
Где Вы в моей фразе углядели "разные ответы на один вопрос"?

я написал, что вас совсем не понял.
Сообщение Добавлено: Ср авг 13, 2014 16:11
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
gudleifr писал(а):
один Control может порождать компиляцию более одного слова-обработчика (на разные "эвенты", как говорят визуальные программисты)

mOleg писал(а):
и в каком случае обработчик должен быть другой.
В случае другого эвента, т.е. другого сообщения/события. Где Вы в моей фразе углядели "разные ответы на один вопрос"?
Сообщение Добавлено: Ср авг 13, 2014 15:57
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
gudleifr писал(а):
Как-то так:

ну, биологию в школе вы таким образом еще сдадите, дальше вам поставят нехорошую оценку.
давайте без биологии обойдемся. Раз уж так все сложно, приведите пару примеров, как должно обрабатываться очередное сообщение и в каком случае обработчик должен быть другой.
Сообщение Добавлено: Ср авг 13, 2014 15:45
  Заголовок сообщения:  Re: Требуются контрпримеры  Ответить с цитатой
mOleg писал(а):
можно техническим, а не литературным языком вести диалог?

Цитата:
Как-то так:
Программа - организм. Смысловая часть - генотип. Принятые в твоей конторе оформительские соглашения - ограничения фенотипа. Зародыш развивается, заполняя своей биомассой структуру оконных форм (может - консоль, может - MDI). Гены лишь определяют ветвление в судьбоносные для зародыша моменты. Фенотип может быть представлен таблицей всех параметров всех окон, может списком отклонений стиля каждого окна от стандартного, может описанием совсем уж аппаратно-независимого дисплея.
Главное - минимум универсальности и максимум удобства.
Сообщение Добавлено: Ср авг 13, 2014 15:42

Часовой пояс: UTC + 3 часа [ Летнее время ]


cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB