Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
gudleifr писал(а): Фигушки. Давайте попробую еще раз объяснить.Чтобы работала некая фигня, надо создать некие структуры в памяти, привязать какие-то указатели и прочая мелочь... Очень не хватает ТЗ, потому как на вопрос: некие + какие-то и прочая мелочь = хочется ответить: = какая-то фиговина. Возможно, в личном общении, когда можно очень просто уточнить тот или иной момент такая постановка задачи простительна и понятна. Инициализацию и "связывание" каких-либо объектов между собой компиляцией считать не могу. Имхо, тогда любое действие стоит считать компиляцией(типа, создание нового за счет комбинирования имеющегося). gudleifr писал(а): Например, при создании исполняемого Win-файла я в его конец втюхиваю т.н. Win-ресурсы (меню, диалоги, иконки...).А можно проводить эту компиляцию "на лету" - во время работы программы. Например, я могу создать меню или диалог в памяти и сказать Винде: "Загрузи, как из ресурса". Ну, допустим, описание структуры и содержимого меню лежит в отдельном файле, картинки в другом, звуки в третьем и т.д. В чем проблема-то? Что мешает их подключить, когда станет надо? Я правда не могу понять вашего описания проблемы, хотя и стараюсь. И, пожалуста, давайте без генотипов-фенотипов.
[quote="gudleifr"]Фигушки. Давайте попробую еще раз объяснить.Чтобы работала некая фигня, надо создать некие структуры в памяти, привязать какие-то указатели и прочая мелочь...[/quote] Очень не хватает ТЗ, потому как на вопрос: некие + какие-то и прочая мелочь = хочется ответить: = какая-то фиговина. Возможно, в личном общении, когда можно очень просто уточнить тот или иной момент такая постановка задачи простительна и понятна.
Инициализацию и "связывание" каких-либо объектов между собой компиляцией считать не могу. Имхо, тогда любое действие стоит считать компиляцией(типа, создание нового за счет комбинирования имеющегося).
[quote="gudleifr"]Например, при создании исполняемого Win-файла я в его конец втюхиваю т.н. Win-ресурсы (меню, диалоги, иконки...).А можно проводить эту компиляцию "на лету" - во время работы программы. Например, я могу создать меню или диалог в памяти и сказать Винде: "Загрузи, как из ресурса".[/quote] Ну, допустим, описание структуры и содержимого меню лежит в отдельном файле, картинки в другом, звуки в третьем и т.д. В чем проблема-то? Что мешает их подключить, когда станет надо?
Я правда не могу понять вашего описания проблемы, хотя и стараюсь. И, пожалуста, давайте без генотипов-фенотипов.
|
|
|
|
Добавлено: Сб авг 16, 2014 19:33 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
mOleg писал(а): Использование словаря уже нам эту свободу даст Фигушки. Давайте попробую еще раз объяснить. Чтобы работала некая фигня, надо создать некие структуры в памяти, привязать какие-то указатели и прочая мелочь... С точки зрения FORTH эту процедуру имеет смысл считать "компиляцией", чтобы потом сигналы о состоянии фигни выглядели для FORTH "просто словами". Т.е. процедура опроса фигни (или реакции на сообщение от нее) та же старая добрая процедура FIND... Конечно, можно честно прописать (скомпилировать) фигню еще в исходном коде. Например, при создании исполняемого Win-файла я в его конец втюхиваю т.н. Win-ресурсы (меню, диалоги, иконки...). А можно проводить эту компиляцию "на лету" - во время работы программы. Например, я могу создать меню или диалог в памяти и сказать Винде: "Загрузи, как из ресурса". Конечно, при компиляции на лету, я теряю в пространстве: в довесок к готовому словарю (который тоже будет занимать место), я имею словарь зародышей и лексиконы для компиляции. Но, зато, я имею возможность подгонять зародышей под разный фенотип, хранить только генотип и пр. Вопрос же собственно состоял в границах применимости первого и второго методов. И в том, чем второй метод должен "выглядеть с точки FORTH".
[quote="mOleg"]Использование словаря уже нам эту свободу даст[/quote]Фигушки. Давайте попробую еще раз объяснить. Чтобы работала некая фигня, надо создать некие структуры в памяти, привязать какие-то указатели и прочая мелочь...
С точки зрения FORTH эту процедуру имеет смысл считать "компиляцией", чтобы потом сигналы о состоянии фигни выглядели для FORTH "просто словами". Т.е. процедура опроса фигни (или реакции на сообщение от нее) та же старая добрая процедура FIND...
Конечно, можно честно прописать (скомпилировать) фигню еще в исходном коде. Например, при создании исполняемого Win-файла я в его конец втюхиваю т.н. Win-ресурсы (меню, диалоги, иконки...). А можно проводить эту компиляцию "на лету" - во время работы программы. Например, я могу создать меню или диалог в памяти и сказать Винде: "Загрузи, как из ресурса".
Конечно, при компиляции на лету, я теряю в пространстве: в довесок к готовому словарю (который тоже будет занимать место), я имею словарь зародышей и лексиконы для компиляции. Но, зато, я имею возможность подгонять зародышей под разный фенотип, хранить только генотип и пр.
Вопрос же собственно состоял в границах применимости первого и второго методов. И в том, чем второй метод должен "выглядеть с точки FORTH".
|
|
|
|
Добавлено: Сб авг 16, 2014 12:21 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
перенес лишнее, посему возвращаю кусок ответа: Цитата: gudleifr писал(а): Речь о выборе между "полной компиляцией заранее" и "саморазворачиванием в процессе".
Использование словаря уже нам эту свободу даст (хотя нужна ли эта свобода? для меня ответ не очевиден). Однако, если пойти дальше, и вспомнить, что у нас есть шикарный контекст словарей, мы можем создать некую иерархию словарей и совсем произвольным образом управлять оконными объектами (убирая, добавляя, заменяя словари в контексте, можно добиться любого необходимого эффекта). Имхо, так.
перенес лишнее, посему возвращаю кусок ответа: [quote]gudleifr писал(а): Речь о выборе между "полной компиляцией заранее" и "саморазворачиванием в процессе".
Использование словаря уже нам эту свободу даст (хотя нужна ли эта свобода? для меня ответ не очевиден). Однако, если пойти дальше, и вспомнить, что у нас есть шикарный контекст словарей, мы можем создать некую иерархию словарей и совсем произвольным образом управлять оконными объектами (убирая, добавляя, заменяя словари в контексте, можно добиться любого необходимого эффекта). Имхо, так.[/quote]
|
|
|
|
Добавлено: Сб авг 16, 2014 11:49 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
gudleifr писал(а): Это как раз та часть "словаря", которая из-за сложноустроенности Винды "компилируется отдельно". это не особо важно. Трюк у меня тут другой - я не хочу в колбэке ничего обрабатывать, т.к. каждое окно у меня крутится в отдельном потоке и имеет собственные USER переменные (одноименные но разные у каждого потока). Вот теперь, второй CASE можно заменить словарем, т.е. вместо Refelex будет поиск по словарю. Не имею ничего против, а вы?
[quote="gudleifr"]Это как раз та часть "словаря", которая из-за сложноустроенности Винды "компилируется отдельно".[/quote] это не особо важно. Трюк у меня тут другой - я не хочу в колбэке ничего обрабатывать, т.к. каждое окно у меня крутится в отдельном потоке и имеет собственные USER переменные (одноименные но разные у каждого потока). Вот теперь, второй CASE можно заменить словарем, т.е. вместо Refelex будет поиск по словарю. Не имею ничего против, а вы? 8)
|
|
|
|
Добавлено: Ср авг 13, 2014 17:40 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
mOleg писал(а): code... Это как раз та часть "словаря", которая из-за сложноустроенности Винды "компилируется отдельно". Т.е. управление и рисование win-объектов лежит "где-то рядом".
[quote="mOleg"]code...[/quote]Это как раз та часть "словаря", которая из-за сложноустроенности Винды "компилируется отдельно". Т.е. управление и рисование 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 ;
[quote="gudleifr"]Так вот, заранее[/quote] А как это делается сейчас? Я, вот, долго не занимался измышлизмами, выходит как-то так: [code]\ Обработчик сообщений окна \ нельзя внутри использовать 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 ; [/code]
|
|
|
|
Добавлено: Ср авг 13, 2014 17:21 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
mOleg писал(а): Ну, допустим, есть отдельный словарь, в котором находится список всех обработчиков, имя каждого - это идентификатор события. Именно. Есть словарь "событие-код", обрабатывающий ПОТОК нужных сообщений. От этого не уйти. Но этот словарь должен быть дополнен "полями" для "прочих событий" - инициализации, рисования, управления (пусть даже, они компилируются не в наш СЛОВАРЬ, а в структуры Винды). Так вот, заранее компилировать эту лабуду при написании программы, и иметь дополнительный словарь компактных "смысловых объектов", которые по потребности перекомпилировать в "визуальные" по месту? Например, в примере про кнопку иметь в "смысловом словаре" только тройку "заголовок-действие", а при указании на то, что она вдруг понадобилась в каком-либо диалоге, рассчитать флаги-размеры исходя из политики выравнивания диалога и скомпилировать полную строку диалога в "визуальном словаре".
[quote="mOleg"]Ну, допустим, есть отдельный словарь, в котором находится список всех обработчиков, имя каждого - это идентификатор события.[/quote]Именно. Есть словарь "событие-код", обрабатывающий ПОТОК нужных сообщений. От этого не уйти. Но этот словарь должен быть дополнен "полями" для "прочих событий" - инициализации, рисования, управления (пусть даже, они компилируются не в наш СЛОВАРЬ, а в структуры Винды). Так вот, заранее компилировать эту лабуду при написании программы, и иметь дополнительный словарь компактных "смысловых объектов", которые по потребности перекомпилировать в "визуальные" по месту?
Например, в примере про кнопку иметь в "смысловом словаре" только тройку "заголовок-действие", а при указании на то, что она вдруг понадобилась в каком-либо диалоге, рассчитать флаги-размеры исходя из политики выравнивания диалога и скомпилировать полную строку диалога в "визуальном словаре".
|
|
|
|
Добавлено: Ср авг 13, 2014 17:00 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
gudleifr писал(а): Т.е. до обработчика еще очередь не дошла (он будет отдельно привязываться к идентификатору 3006), а достаточно внушительный объект уже "откомпилирован" - координаты, размеры, флаги... (Это все будет использовано Виндой при отрисовке кнопочки). Ну, допустим, есть отдельный словарь, в котором находится список всех обработчиков, имя каждого - это идентификатор события. Возникло событие - выполнилось имя? Я правильно понимаю ваше: gudleifr писал(а): Допустим, я рассматриваю поток событий сообщений Windows как ПОТОК. Т.е. получение системного сообщения после прохождения некоторого FIND заканчивается вызовом некоторого слова.
[quote="gudleifr"]Т.е. до обработчика еще очередь не дошла (он будет отдельно привязываться к идентификатору 3006), а достаточно внушительный объект уже "откомпилирован" - координаты, размеры, флаги... (Это все будет использовано Виндой при отрисовке кнопочки).[/quote] Ну, допустим, есть отдельный словарь, в котором находится список всех обработчиков, имя каждого - это идентификатор события. Возникло событие - выполнилось имя? Я правильно понимаю ваше: [quote="gudleifr"]Допустим, я рассматриваю поток событий сообщений Windows как ПОТОК. Т.е. получение системного сообщения после прохождения некоторого FIND заканчивается вызовом некоторого слова.[/quote]
|
|
|
|
Добавлено: Ср авг 13, 2014 16:45 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
mOleg писал(а): Зачем? Почему обязательно кучу входных точек? Нафига сей мазохизм? Например, рассмотрим пример создания кнопочки в Win-API в окне диалога: Код: 3006 13 52 10 141 HEX 50010001 DECIMAL S" Say Hello" BUTTON-IS Т.е. до обработчика еще очередь не дошла (он будет отдельно привязываться к идентификатору 3006), а достаточно внушительный объект уже "откомпилирован" - координаты, размеры, флаги... (Это все будет использовано Виндой при отрисовке кнопочки). Кроме того, кнопочка может быть дополнительно быть привязана к спискам табуляций, разрешающих/запрещающих зависимостей и пр. Их придется "компилировать" отдельно. Так что, компиляция полного описания визуального объекта на все случаи жизни - техника по-умолчанию, а не извращение. Если хотите, плата за неумение отличить генотип от фенотипа.
[quote="mOleg"]Зачем? Почему обязательно кучу входных точек? Нафига сей мазохизм?[/quote] Например, рассмотрим пример создания кнопочки в Win-API в окне диалога: [code]3006 13 52 10 141 HEX 50010001 DECIMAL S" Say Hello" BUTTON-IS[/code] Т.е. до обработчика еще очередь не дошла (он будет отдельно привязываться к идентификатору 3006), а достаточно внушительный объект уже "откомпилирован" - координаты, размеры, флаги... (Это все будет использовано Виндой при отрисовке кнопочки). Кроме того, кнопочка может быть дополнительно быть привязана к спискам табуляций, разрешающих/запрещающих зависимостей и пр. Их придется "компилировать" отдельно. Так что, компиляция полного описания визуального объекта на все случаи жизни - техника по-умолчанию, а не извращение. Если хотите, плата за неумение отличить генотип от фенотипа.
|
|
|
|
Добавлено: Ср авг 13, 2014 16:32 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
gudleifr писал(а): следует КОМПИЛИРОВАТЬ не одну процедуру, а некий "визуальный объект", с кучей входных точек для всех потребных эвентов и пропертей, Зачем? Почему обязательно кучу входных точек? Нафига сей мазохизм? Нет, правда, не могу понять вашей мысли, нарисуйте, пожалуйста, понятный пример. Или речь о сложности ради сложности?
[quote="gudleifr"]следует КОМПИЛИРОВАТЬ не одну процедуру, а некий "визуальный объект", с кучей входных точек для всех потребных эвентов и пропертей,[/quote] Зачем? Почему обязательно кучу входных точек? Нафига сей мазохизм? Нет, правда, не могу понять вашей мысли, нарисуйте, пожалуйста, понятный пример.
Или речь о сложности ради сложности?
|
|
|
|
Добавлено: Ср авг 13, 2014 16:22 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
mOleg писал(а): ок, тогда в чем проблема? gudleifr писал(а): следует КОМПИЛИРОВАТЬ не одну процедуру, а некий "визуальный объект", с кучей входных точек для всех потребных эвентов и пропертей, или привязывать процесс компиляции к рисованию Control, записывая в словарь только обработчик, а пропертя не компилировать - применять немедленно.
[quote="mOleg"]ок, тогда в чем проблема?[/quote] [quote="gudleifr"]следует КОМПИЛИРОВАТЬ не одну процедуру, а некий "визуальный объект", с кучей входных точек для всех потребных эвентов и пропертей, или привязывать процесс компиляции к рисованию Control, записывая в словарь только обработчик, а пропертя не компилировать - применять немедленно.[/quote]
|
|
|
|
Добавлено: Ср авг 13, 2014 16:13 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
gudleifr писал(а): В случае другого эвента, т.е. другого сообщения/события. ок, тогда в чем проблема? gudleifr писал(а): Где Вы в моей фразе углядели "разные ответы на один вопрос"? я написал, что вас совсем не понял.
[quote="gudleifr"]В случае другого эвента, т.е. другого сообщения/события. [/quote] ок, тогда в чем проблема?
[quote="gudleifr"]Где Вы в моей фразе углядели "разные ответы на один вопрос"?[/quote] я написал, что вас совсем не понял.
|
|
|
|
Добавлено: Ср авг 13, 2014 16:11 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
gudleifr писал(а): один Control может порождать компиляцию более одного слова-обработчика (на разные "эвенты", как говорят визуальные программисты) mOleg писал(а): и в каком случае обработчик должен быть другой. В случае другого эвента, т.е. другого сообщения/события. Где Вы в моей фразе углядели "разные ответы на один вопрос"?
[quote="gudleifr"]один Control может порождать компиляцию более одного слова-обработчика (на разные "эвенты", как говорят визуальные программисты)[/quote] [quote="mOleg"]и в каком случае обработчик должен быть другой.[/quote]В случае другого эвента, т.е. другого сообщения/события. Где Вы в моей фразе углядели "разные ответы на один вопрос"?
|
|
|
|
Добавлено: Ср авг 13, 2014 15:57 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
gudleifr писал(а): Как-то так: ну, биологию в школе вы таким образом еще сдадите, дальше вам поставят нехорошую оценку. давайте без биологии обойдемся. Раз уж так все сложно, приведите пару примеров, как должно обрабатываться очередное сообщение и в каком случае обработчик должен быть другой.
[quote="gudleifr"]Как-то так:[/quote] ну, биологию в школе вы таким образом еще сдадите, дальше вам поставят нехорошую оценку. давайте без биологии обойдемся. Раз уж так все сложно, приведите пару примеров, как должно обрабатываться очередное сообщение и в каком случае обработчик должен быть другой.
|
|
|
|
Добавлено: Ср авг 13, 2014 15:45 |
|
|
|
|
|
Заголовок сообщения: |
Re: Требуются контрпримеры |
|
|
mOleg писал(а): можно техническим, а не литературным языком вести диалог? Цитата: Как-то так: Программа - организм. Смысловая часть - генотип. Принятые в твоей конторе оформительские соглашения - ограничения фенотипа. Зародыш развивается, заполняя своей биомассой структуру оконных форм (может - консоль, может - MDI). Гены лишь определяют ветвление в судьбоносные для зародыша моменты. Фенотип может быть представлен таблицей всех параметров всех окон, может списком отклонений стиля каждого окна от стандартного, может описанием совсем уж аппаратно-независимого дисплея. Главное - минимум универсальности и максимум удобства.
[quote="mOleg"]можно техническим, а не литературным языком вести диалог?[/quote] [quote]Как-то так: Программа - организм. Смысловая часть - генотип. Принятые в твоей конторе оформительские соглашения - ограничения фенотипа. Зародыш развивается, заполняя своей биомассой структуру оконных форм (может - консоль, может - MDI). Гены лишь определяют ветвление в судьбоносные для зародыша моменты. Фенотип может быть представлен таблицей всех параметров всех окон, может списком отклонений стиля каждого окна от стандартного, может описанием совсем уж аппаратно-независимого дисплея. Главное - минимум универсальности и максимум удобства.[/quote]
|
|
|
|
Добавлено: Ср авг 13, 2014 15:42 |
|
|
|
|