Состав библиотеки:

• CDialogXML — диалог на основе XML-"шаблона"
  Автор: SchweinDeBurg
  Дата: 10.01.05
  
  
• CMenuXML/CHotKeysXML — меню/акселераторы на основе XML
  Автор: SchweinDeBurg
  Дата: 17.01.05
  
  
• CStringsXML — таблица строк на основе XML
  
• вспомогательные классы
  
• пример использования (находится в папке Samples\Generic)

Исходные тексты: InterfaceXML.zip (72,3 Кб)

Внимание: файл InterfaceXML.zip содержит более поздние версии исходных файлов, чем те архивы, которые можно скачать по ссылкам, указанным в топиках "CDialogXML" и "CMenuXML/CHotKeysXML". Например, в класс CDialogXML добавлена возможность указывать в текстах элементов управления перенос на новую строку с помощью символа "|".

Класс CStringsXML

Представляет собой аналог ресурса "таблица строк" (String Table) на основе XML-файла следующего формата:

<?xml version="1.0" encoding="Windows-1252"?>
<Strings>
    <String ID="40001" Text="Shows the test dialog|Test Dialog"/>
    <String ID="40002" Text="Quits the application|Exit"/>
    <String ID="40003" Text="Displays program information and copyright|About"/>
    ...
</Strings>

Атрибут "ID" задает идентификатор строки и должен быть строковым представлением 4-байтового целого числа в десятичной системе счисления. Атрибут "Text" задает текст строки; все символы "|" будут заменены на символ "новая строка" ("\n").

Конструктор имеет вид

CStringsXML(LPCTSTR pszStringsName);

В качестве параметра pszStringsName необходимо передать имя таблицы строк (принципы обработки этого имени подробно изложены в сообщении [MFC] CDialogXML — rev. 3

Автор: SchweinDeBurg
Дата: 14.01.05

).

Доступ к строкам осуществляется при помощи оператора индексации

CString operator [](DWORD dwID);

принимающем через параметр dwID идентификатор требуемой строки. Если строка с таким атрибутом отсутствует в XML-файле, оператор возвращает пустую строку. Заметим, что единожды полученные строки кэшируются и при повторном запросе обращения к XML-файлу не происходит. Данный кэш можно очистить при помощи метода

void CleanupCache(void);

При желании, после конструирования объекта можно закэшировать сразу все строки соответствующего XML-файла; для этого предназначен метод

int PutStringsToCache(void);

возвращающий колчество успешно добавленных в кэш строк.

Предусмотрен также метод

CString Format(DWORD dwID, ...);

который использует строку с идентификатором dwID в качестве форматирующего выражения и возвращает результирующую строку аналогичто методу CString::Format() или функции CRT sprintf().

Заметим, что количество экземпляров CStringsXML, одновременно используемых в приложении, может быть произвольным (в прилагающемся примере их два — CGenericApp::m_stringsMain и CMainFrame::m_stringsStatus); идентификаторы строк должны быть уникальными в пределах одной таблицы.

Вспомогательные классы CDialogXML_t, CMenuXML_t, CHotKeysXML_t и CStringsXML_t

Данные шаблонные потомки (интерфес и реализация находятся в файле "GetXMLpath.h") соответствующих классов предназначены для упрощения использования библиотеки в том случае, когда XML-файлы должны располагаться в папке, имя которой определяется отличным от предусмотренной реализации образом. Вместо того, чтобы наследоваться от C*XML и перекрывать виртуальный метод GetXMLpath, достаточно просто реализовать единую функцию, возвращающую требуемый путь, и воспользоваться ей в качестве параметра шаблона. Ниже приведен простой пример:

// stdafx.h

void GetAppDataPath(CString& strDest);

typedef CDialogXML_t<GetAppDataPath> CMyDialogXML;
typedef CMenuXML_t<GetAppDataPath> CMyMenuXML;
typedef CHotKeysXML_t<GetAppDataPath> CMyHotKeysXML;
typedef CStringsXML_t<GetAppDataPath> CMyStringsXML;

// GetAppDataPath.cpp

void GetAppDataPath(CString& strDest)
{
    strDest = ...
}

Теперь можно создавать объекты-экземпляры CMyMenuXML, CMyHotKeysXML и CMyStringsXML; а также использовать CMyDialogXML в качестве базового класса для всех диалогов приложения:

// AboutDialog.h

class CAboutDialog: public CMyDialogXML
{
    DECLARE_DYNAMIC(CAboutDialog)
    DECLARE_MESSAGE_MAP()
...
};

// AboutDialog.cpp

IMPLEMENT_DYNAMIC(CAboutDialog, CDialogXML)

// message map
BEGIN_MESSAGE_MAP(CAboutDialog, CDialogXML)
    ...
END_MESSAGE_MAP()

Обратите внимание, что в макросах IMPLEMENT_DYNAMIC() и BEGIN_MESSAGE_MAP() в качестве базового класса необходимо указывать CDialogXML, поскольку CDialogXML_t не содержит MFC-шной RTTI (то же самое касается и остальных C*XML_t классов).

Я, конечно, извиняюсь,но никак не могу придумать применения этому делу, кроме локализации...
Ведь логика ui остается в исходном коде и как следствие, практички можно только двигать имеющеиеся контролы,
да текст менять.

Если к этому скриптинг приделать, чтобы "серить"() контролы, в зависимости от других, скрывать/показывать области и т.д. Еще оченно неплохо бы иметь тег для вставки одного диалога в другой в качестве child, группировку контролов (невизульную). А в программный интерфес ввести возможность снятия информации с произвольного диалога, без заранее утвержденного набора контролов. В таком случае, примение есть: можно писать в клиентсерверном стиле: ui отдельно и вообще внешне, функционал отдельно.

Здравствуйте, Рома Мик, Вы писали:

РМ>Ведь логика ui остается в исходном коде и как следствие, практички можно только двигать имеющеиеся контролы,
РМ>да текст менять.

Ну, вот Вам пара примеров навскидку:

1. Я делал ГУЙ на 15-дюймовом монике в разрешении 800 х 600 (зрение плохое), а у клиента — 21 дюйм и диалоги выглядят "маленькими", путь к файлу целиком в поле ввода не помещается. "Настраиваем" на его машине XML-"шаблоны" — и вуаля.
   
   
2. Приложение содержит навороченный функционал, а "бабушка"-бухгалтер теряется в обилии команд меню — лично ей нужен всего пяток. Опять-таки "настраиваем" XML-шаблон и все довольны.

РМ>Если к этому скриптинг приделать, [ ... ]

Этим, вроде как, брат c-smile занимается.

Здравствуйте, SchweinDeBurg, Вы писали:

[ ... ]

РМ>>Если к этому скриптинг приделать, [ ... ]
SDB>Этим, вроде как, брат c-smile занимается.
Да я в курсе, и даже активно использую. И кстати, именно это меня всегда останавливало, когда хотелось в таком духе извратиться.
НО! На самом деле, моя глубокая ИМХА в том, что html — это хорошо, но нечто создающее в результате стандартные системные диалоги из стандартных контролов и т.д. — для многих целей лучше. Да и нет пока у Андрея такой системы, насколько я в курсе.
На самом деле, я понимаю, что то, о чем я говорю, и субж — это две большие разницы, но на мысли наводит.

Здравствуйте, Рома Мик, Вы писали:

РМ>Да я в курсе, и даже активно использую. И кстати, именно это меня всегда останавливало, когда хотелось в таком духе извратиться.
РМ>НО! На самом деле, моя глубокая ИМХА в том, что html — это хорошо, но нечто создающее в результате стандартные системные диалоги из стандартных контролов и т.д. — для многих целей лучше. Да и нет пока у Андрея такой системы, насколько я в курсе.
РМ>На самом деле, я понимаю, что то, о чем я говорю, и субж — это две большие разницы, но на мысли наводит.

а вообще есть в природе такие библиотеки, позволяющие создавать гуи на основе xml/html? (может даже со скриптингом есть? )

Здравствуйте, yxiie, Вы писали:

Y>а вообще есть в природе такие библиотеки, позволяющие создавать гуи на основе xml/html? (может даже со скриптингом есть? )
HTML — в принципе вполне подходит для целей создания ГУЯ, а у Андрея ака c-cmile есть engine как раз для этого и предназначаенный. Скриптинг в процессе засовывания туда, или даже уже засунут, я на пару месяцев отвлекся от этого дела. http://terrainformatica.com Сам этот engine существует давно и вполне стабилен.

В приницпе люди умудряются делать гуй на основе webbrowser control или hta-файлов. Но ИМХО страшно гемморойно это.

Здравствуйте, Рома Мик, Вы писали:

РМ>HTML — в принципе вполне подходит для целей создания ГУЯ, а у Андрея ака c-cmile есть engine как раз для этого и предназначаенный. Скриптинг в процессе засовывания туда, или даже уже засунут, я на пару месяцев отвлекся от этого дела. http://terrainformatica.com Сам этот engine существует давно и вполне стабилен.

вещь неплохая, но есть несколько но:

1. платный (это в принципе не так уж и страшно)
2. нет исходников (а это уже приговор)
3. глючный (не знаю как насчет заявленной тобою стабильности, но визуальные глюки я наблюдал почти в каждой второй демке, и я только раз мельком просмотрел)
4. также примеры бесполезные. показано как может быть красиво, но как интегрировать это в свою программу? по интеграции только один RSSComposer на WTL, но этого мало.
5. ну и в довершение убивает архиубогая doxygen-овская документация.
в итоге внедрить и поддержвать код на основе этого компонента будет очень дорого, намного дороже стоимости самой библиотеки.

в общем я не назвал бы это готовым коммерческим продуктом, который стоит использовать — это бета или даже альфа версия.

РМ>В приницпе люди умудряются делать гуй на основе webbrowser control или hta-файлов. Но ИМХО страшно гемморойно это.

да не, это не конечно же не то

Здравствуйте, yxiie, Вы писали:

Y>1. платный (это в принципе не так уж и страшно)
А ты сделай Андрею что-нибудь хорошее! (Я ничего не обещаю, это просто предложение) И кроме того, по-моему он для некоммерческих проектов бесплатный (было раньше точно, сейчас не знаю).

Y>2. нет исходников (а это уже приговор)
Ну не знаю, ты представляешь себе колоссальный труд по деланию всего этого? И после этого всем направо и налево раздавать?

Y>3. глючный (не знаю как насчет заявленной тобою стабильности, но визуальные глюки я наблюдал почти в каждой второй демке, и я только раз мельком просмотрел)
ПИШИ АНДРЕЮ! Я лично не знаю, что именно ты обзываешь глюками, у меня правда старая версия, но используется в хвост и в гриву и все глюки какие были замечены, давно исправлены.

Y>4. также примеры бесполезные. показано как может быть красиво, но как интегрировать это в свою программу? по интеграции только один RSSComposer на WTL, но этого мало.
Отличная идея, что ты можешь хорошего Андрею сделать ИМХО.

Y>5. ну и в довершение убивает архиубогая doxygen-овская документация.
Она просто еще не сделана (это я ее делаю, но временно очень занят на работе и учебе, так что вот), но есть где-то документация к старой версии http://www.terrainformatica.com/htmlayout.old/API.htm и http://www.terrainformatica.com/htmlayout.old/htmlex.htm .

Y>в итоге внедрить и поддержвать код на основе этого компонента будет очень дорого, намного дороже стоимости самой библиотеки.
Ну не знаю, мой опыт говорит об обратном...

Y>в общем я не назвал бы это готовым коммерческим продуктом, который стоит использовать — это бета или даже альфа версия.
Тут видимо согласен, но лежащий в основе этого дела engine довольно хорошо отлажен, а в бете только обертка.

Здравствуйте, Рома Мик, Вы писали:

Y>>1. платный (это в принципе не так уж и страшно)
РМ>А ты сделай Андрею что-нибудь хорошее! (Я ничего не обещаю, это просто предложение) И кроме того, по-моему он для некоммерческих проектов бесплатный (было раньше точно, сейчас не знаю).

это конечно замечательно для всех тех, кого интересуют некоммерческие проекты, но к сожалению (или к счастью ) я не из их числа.

Y>>2. нет исходников (а это уже приговор)
РМ>Ну не знаю, ты представляешь себе колоссальный труд по деланию всего этого? И после этого всем направо и налево раздавать?

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

Y>>3. глючный (не знаю как насчет заявленной тобою стабильности, но визуальные глюки я наблюдал почти в каждой второй демке, и я только раз мельком просмотрел)
РМ>ПИШИ АНДРЕЮ! Я лично не знаю, что именно ты обзываешь глюками, у меня правда старая версия, но используется в хвост и в гриву и все глюки какие были замечены, давно исправлены.

версию сегодня с сайта скачал, не знаю старая или новая это.
куда писать?

Y>>4. также примеры бесполезные. показано как может быть красиво, но как интегрировать это в свою программу? по интеграции только один RSSComposer на WTL, но этого мало.
РМ>Отличная идея, что ты можешь хорошего Андрею сделать ИМХО.


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

Y>>в итоге внедрить и поддержвать код на основе этого компонента будет очень дорого, намного дороже стоимости самой библиотеки.
РМ>Ну не знаю, мой опыт говорит об обратном...

можно ссылку на продукт, которое ваше предприятие выпустило с использованием этого компонента?

Y>>в общем я не назвал бы это готовым коммерческим продуктом, который стоит использовать — это бета или даже альфа версия.
РМ>Тут видимо согласен, но лежащий в основе этого дела engine довольно хорошо отлажен, а в бете только обертка.

ну, от этого легче разве что на душе
использование компонента от этого не упрощается.

Здравствуйте, yxiie, Вы писали:

РМ>>Ну не знаю, ты представляешь себе колоссальный труд по деланию всего этого? И после этого всем направо и налево раздавать?
Y>а ты представь коммерческий проект, в который вложено немало бабок и начинают вылазить глюки (а их я уверенн немало скрывается, и не надо отрицать ) которые нет возможности исправить, что тогда? писать разработчику чтобы тот исправил? может и исправит но вопрос когда? делать сроки разработки зависящими от посторонних людей может обойтись в копеечку, срывами сроков и другими неприятностями.
Насколько я знаю Андрей дает исходники крупным клиентам.

Y>>>3. глючный (не знаю как насчет заявленной тобою стабильности, но визуальные глюки я наблюдал почти в каждой второй демке, и я только раз мельком просмотрел)
РМ>>ПИШИ АНДРЕЮ! Я лично не знаю, что именно ты обзываешь глюками, у меня правда старая версия, но используется в хвост и в гриву и все глюки какие были замечены, давно исправлены.
Y>версию сегодня с сайта скачал, не знаю старая или новая это.
Y>куда писать?
Ну в профайле на rsdn у него написано news@terrainformatica.com
Давать его частное мыло мне как-то неудобно.

Y>>>4. также примеры бесполезные. показано как может быть красиво, но как интегрировать это в свою программу? по интеграции только один RSSComposer на WTL, но этого мало.
РМ>>Отличная идея, что ты можешь хорошего Андрею сделать ИМХО.

Y>
Y>очень смешно.
Y>это я должен разобраться, и показать разработчику как интегрировать его движок в мою программу???
Y>у меня нет времени, да и к тому же это совсем не весело ковыряться в чужих малодокументированых библиотеках.
Это было только предложение, на случай, если ты не хочешь платить несколько сот баксов. Не хочешь, не надо... И я даже не обещал, что Андрей согласится.

Y>>>в итоге внедрить и поддержвать код на основе этого компонента будет очень дорого, намного дороже стоимости самой библиотеки.
РМ>>Ну не знаю, мой опыт говорит об обратном...
Y>можно ссылку на продукт, которое ваше предприятие выпустило с использованием этого компонента?
Он не публичный. Используется широко, насколько мне известно под сотню инсталляций существует уже более двух лет, правда изначально он был без htmlayout. Дальнейшую информацию могу раскрыть в приват, т.к. заказчик может быть не в восторге от такой публикации.

А вообще что-то я периодически стал попадать адвокатом... Надо что-то с собой делать.

Здравствуйте, yxiie, Вы писали:

Y>можно ссылку на продукт, которое ваше предприятие выпустило с использованием этого компонента?

Например вот:
http://blocknote.net
http;//evernote.com

Это правда версия 2.0 engine.

Версия 3.0 — hsmile engine которая появится через пару недель включает в себя
также scripting engine и расширенный набор styleable input elements.
http://terrainformatica.com/hsmile/images/controls.jpg
http://terrainformatica.com/hsmile/images/controls2.jpg

Стилировать в CSS можно все вплоть до вида элементов scrollbar
(http://terrainformatica.com/hsmile/images/netbrowser1.png)

Y>>>в общем я не назвал бы это готовым коммерческим продуктом, который стоит использовать — это бета или даже альфа версия.
РМ>>Тут видимо согласен, но лежащий в основе этого дела engine довольно хорошо отлажен, а в бете только обертка.

Y>ну, от этого легче разве что на душе
Y>использование компонента от этого не упрощается.

HTMLayout в версии на сайте это скорее technology preview и дальше развиваться не будет.
На смену ему — hsmile.dll — windowless component для win32 и mac.

В настоящее время готовы врапперы для WTL и .NET () и активно разарабатываются врапперы ActiveX и для языка D.
wxWindows делает Зверь из Харькова. Под Борланд наверное тоже нужно — место вакантное.

hsmile sdk доступен уже сейчас на нашем рабочем SVN сервере. Для доступа киньте мне запрос на hsmile@terrainformatica.com. и вообще по всем вопросам можно на этот адрес писать.

Здравствуйте, yxiie, Вы писали:

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

Кто-то мне говорил что в bug tracking системе для MS Word 5 тыс висящих entries.
В IE багов — весь интернет на эту тему шипит. Тем не менее ежики плачут но юзают IWebBrowser.

С нами хоть можно поговорить вживую — во всяком случае мы можем сказать не только "Q34785: да падает, но вот workaround" а и "вот три варианта — второй самый эффективный".

Ладно это лирика.

На самом деле встраиваемый HTML компонент должен обладать немного другим API чем тот который может предоставить browser общего назначения.

Например один из заказчиков использует hsmile в UI на основе OpenGL. Т.е. HTML rendering осуществляется в OpenGL surface напрямую. (Это одна из крупнейших online "бродилок" в стиле Диптаун )

В определенных ситуациях и use cases например security model просто мешает. И т.д.

Поэтому следует ожидать некоторых скажем неочевидностей. Например hsmile.dll не использует ни COM ни .NET ни изнутри ни снаружи — чистый extern "C" API соответсвенно. Что в общем тоже накладывает некую специфику.

Документация и примеры.
У нас такая практика: вы говорите что вам надо — мы вам делаем demo — заготоовку под use case.
Примеры из htmengine SDK рождались именно так. Не хочется лепить никому не нужные ни доки ни демы.

Андрей.

Здравствуйте, c-smile, Вы писали:

CS>для WTL и .NET () и активно разарабатываются врапперы ActiveX...

CS>врапперы ... для языка D.


CS>wxWindows делает Зверь из Харькова.


CS>Под Борланд наверное тоже нужно — место вакантное.
а Дима? Flamer?

Здравствуйте, Зверёк Харьковский, Вы писали:

CS>>Под Борланд наверное тоже нужно — место вакантное.
ЗХ>а Дима? Flamer?

Я ему от всей души желаю закончить начатое

К тому же он использует HTMEngine — это предыдущая версия и к тому же WYSIWYG editor,

Здравствуйте, Зверёк Харьковский, Вы писали:

CS>>врапперы ... для языка D.
ЗХ>

Ага. D рулез. Мне он на порядок больше нравится чем C#.
Как минимум тем что гуёвая "hello world" — 64k и никакого Frameworka не надо — "Зачем нам кузнец?"

И есть заказчик.

Здравствуйте, c-smile, Вы писали:

CS>>>Под Борланд наверное тоже нужно — место вакантное.
ЗХ>>а Дима? Flamer?

CS>Я ему от всей души желаю закончить начатое

Закончим, закончим

CS>К тому же он использует HTMEngine — это предыдущая версия и к тому же WYSIWYG editor,

Ага, так и есть. Если вдруг надо враппер под деБилдер — валяется у меня. Полёты показывают, что вроде получился нормальным и без ярких косяков — работает стабильно и не падает.

Здравствуйте, Рома Мик, Вы писали:

РМ>Я, конечно, извиняюсь,но никак не могу придумать применения этому делу, кроме локализации...
РМ>Ведь логика ui остается в исходном коде и как следствие, практички можно только двигать имеющеиеся контролы,
РМ>да текст менять.

РМ>Если к этому скриптинг приделать, чтобы "серить"() контролы, в зависимости от других, скрывать/показывать области и т.д. Еще оченно неплохо бы иметь тег для вставки одного диалога в другой в качестве child, группировку контролов (невизульную). А в программный интерфес ввести возможность снятия информации с произвольного диалога, без заранее утвержденного набора контролов. В таком случае, примение есть: можно писать в клиентсерверном стиле: ui отдельно и вообще внешне, функционал отдельно.
Писал как-то на ATL Хостинг ActiveX c поддержкой MS Script — все читалось из XML Табы поддерживались (правда гемору с этим)-
Ну и вот что получалось
http://gzip.rsdn.ru:80/File/3242/xmlexample.gif

Здравствуйте, c-smile, Вы писали:

CS>Ага. D рулез. Мне он на порядок больше нравится чем C#.
CS>Как минимум тем что гуёвая "hello world" — 64k и никакого Frameworka не надо — "Зачем нам кузнец?"
Сначала написал пространный текст на тему того, что пока еще не рулез, ибо сырой, в отличие от C#. Затем стер, потому что мне хочется больше узнать об обертке для D и о hsmile вообще. Например поверх чего будет обертка для D. Остальные обертки сделаны на базе высокоуровневых GUI библиотек. Неужели для обертки на D есть приемлимый вариант? Или чистый Win32API?

CS>И есть заказчик.
Это на самом деле удивительно. Получается, что обертка для hsmile это одна из первых коммерческих разработок на D.
Заказчик случаем не Walter Bright?

Здравствуйте, uw, Вы писали:

uw>Например поверх чего будет обертка для D. Остальные обертки сделаны на базе высокоуровневых GUI библиотек. Неужели для обертки на D есть приемлимый вариант? Или чистый Win32API?
они не "на базе". они просто позволяют встроить готовый контрол (hsmile) в приложение на [VCL/WTL/MFC/.Net/wxWindows]. Чувствуешь разницу? Вся функциональность внутри hsmile.dll. Точно так же контрол можно встроить в обычную WinAPI-шную программу: его API — это просто Plain C.

Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>они не "на базе". они просто позволяют встроить готовый контрол (hsmile) в приложение на[VCL/WTL/MFC/.Net/wxWindows]. Чувствуешь разницу? Вся функциональность внутри hsmile.dll.
ЗХ>Точно так же контрол можно встроить в обычную WinAPI-шную программу: его API — это просто Plain C.

Я в курсе, более того я чувствую разницу начиная с первых версий htmlayout и htmengine. Но речь шла не о функциональности, а об обертке. Чувствуешь разницу? Вопрос — "обертка(wrapper) для языка D будет написана для встраивания в приложение использующее X?",. Теперь понятно?

Для D нет GUI библиотек подобного масштаба и единственный вариант, который пришел мне в голову — WinAPI, о чем собственно я и задал уточняющий вопрос.

Здравствуйте, uw, Вы писали:

[зверьковыгрызено]
недоразумение, понял, виноват, каюсь.

Здравствуйте, uw, Вы писали:

uw>Здравствуйте, c-smile, Вы писали:

CS>>Ага. D рулез. Мне он на порядок больше нравится чем C#.
CS>>Как минимум тем что гуёвая "hello world" — 64k и никакого Frameworka не надо — "Зачем нам кузнец?"
uw>Сначала написал пространный текст на тему того, что пока еще не рулез, ибо сырой, в отличие от C#. Затем стер, потому что мне хочется больше узнать об обертке для D и о hsmile вообще. Например поверх чего будет обертка для D. Остальные обертки сделаны на базе высокоуровневых GUI библиотек. Неужели для обертки на D есть приемлимый вариант? Или чистый Win32API?

Внешне hsmile это windowless engine состоящий из одного inbound интерфейса выполненного в виде
набора функций:

CFUNC HSMILE HSMILEAPI create_hsmile_engine(HS_DWORD tag);
CFUNC void   HSMILEAPI destroy_hsmile_engine(HSMILE hs);

CFUNC HS_BOOL HSMILEAPI hsmile_handle_mouse( 
        HSMILE    hs,
        HS_DWORD  event_type, 
        HS_INT    x, 
        HS_INT    y, 
        HS_DWORD  mouse_buttons, 
        HS_DWORD  keyboard_states);

CFUNC HS_BOOL HSMILEAPI hsmile_handle_paint(
        HSMILE hs,
#if defined(WIN32)
        HDC hdc, 
#elif defined(MACOSX)
        // nothing here as it draws on current Carbon's CGrafPort
#endif
        HS_INT          x,        //  Specifies a rectangle of area to paint
        HS_INT          y,        //  in device units relative to 
        HS_INT          width,    //  the upper-left corner of the client area. 
        HS_INT          height);  //  

 ....

Эти функции оборачиваются в C++ html_view класс (в комплекте SDK)

Архитектура проста: host вызывает сам функции hsmile когда он считает
это нужным. Например hsmile_handle_mouse может быть вызвана до, после или вместо
стандартной обработки WM_LBUTTONDOWN WM_MOUSEMOVE и т.д.

Так как HWND hsmile'у не нужен то можно сделать несколько engine на одном HWND
Например темы в виртуальном list view — разные HTML документы. Собственно так отображает
список note Flamer в MeineLiebenNotes.

Имея такую схему HTML rendering можно прицепить к любому окну — например отрисовка
background как HTML в некоем CDialog. hsmile там "стоит рядом" не мешая обрабатывать
всю остальную функциональность dialog системе.

В примере netbrowser.exe (.NET )
http://terrainformatica.com/hsmile/images/netbrowser1.png
стек документов для хождения Previous/Next устроен просто как массив hsmile'ов

hsmilenet11.Engine stack[];

Сам hsmile внутри себя стек документов не держит. Что имхо правильно.
Этот стек очень application specific и хост должен сам им управлять.

------------------------------------------
Также есть два других outbound interface — это адреса callback функций предоставляемые
хостом :

struct HSMILE_HOST_CALLBACK 
{
  // host's chance to load data for the engine
  HS_BOOL (HSMILE_CB *load_data)(void* p, const HS_WCHAR* url, HS_DWORD data_type);
  // host's chance to save received data somewhere
  void    (HSMILE_CB *data_loaded)(void* p, const HS_WCHAR* url, const HS_BYTE* data, HS_DWORD data_size, HS_DWORD data_type);
  HS_BOOL (HSMILE_CB *start_timer)(void* p, HS_DWORD timer_id, HS_DWORD millis);
  HS_BOOL (HSMILE_CB *stop_timer)(void* p, HS_DWORD timer_id);
...
}

И scripting callback

struct CSMILE_HOST_CALLBACK 
{
  // stdin/stdout/stderr for scripting engine
  CS_BOOL (CSMILE_CB *stdin_getc)(void* p, CS_WCHAR* wc);
  CS_BOOL (CSMILE_CB *stdout_putc)(void* p, CS_WCHAR wc);
  CS_BOOL (CSMILE_CB *stderr_putc)(void* p, CS_WCHAR wc);

  // user defined function callback - call from script 
  CS_VALUE (CSMILE_CB *udf_call)(void* p, CS_VALUE* argv, int argn );
};

Пояснение: В скрипте hsmile (JavaScript++) есть понятие streams поэтому можно писать так:

        function onclick() // function call happens in context
                    // of element the behavior attached so
                    // 'this' is the element
        {
            stdout << "Gotcha! Click on " << this << "\n"; // вызовы stdout_putc....
        }

        function onmousemove() 
        {
            statusbar.innerText = String.printf("x=%d y=%d",event.x, event.y);
        }

Для debugging stdin/stdout удобнее чем alert(something) в стандартном JavaScript


"Неужели для обертки на D есть приемлимый вариант?"

Все зависит от задачи.
Например написане на D servlet'a html2png не требует практически ничего кроме как CreateCompatibleBitmap со товарищи.

Собственно сам по себе hsmile и есть GUI engine. C минимальной оберткой со стороны D . D получает события, исполняет мой eval() и генерирует нужный HTML если надо. Типа того.

А список gui libs для D здесь: http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries

uw>Заказчик случаем не Walter Bright?

Нет

Здравствуйте, SchweinDeBurg, Вы писали:

SDB>Ну, вот Вам пара примеров навскидку:

SDB>

SDB>
1. Я делал ГУЙ на 15-дюймовом монике в разрешении 800 х 600 (зрение плохое), а у клиента — 21 дюйм и диалоги выглядят "маленькими", путь к файлу целиком в поле ввода не помещается. "Настраиваем" на его машине XML-"шаблоны" — и вуаля.

Несколько идей:

• В CDialogXML на titlebar можно добавить кнопочку edit — в результате которой открывался бы встроенный редактор, в котором каждый желающий мог бы настроить контролы диалога "под себя" — это было бы реально круто.
  
  
• В XML можно хранить всё состояние контролов. Default-ные значение контролов для диалога "Preferences" можно вполне рассматривать как настройки приложения.
  
  
• Если также сохранять все .xml-ки программы вместе со всеми остальными её настройками в одном архиве — и это могло бы стать чем-то вроде стандарта backup/restore приложений.

Здравствуйте, SchweinDeBurg, Вы писали:

SDB>Внимание: файл InterfaceXML.zip содержит более поздние версии исходных файлов, чем те архивы, которые можно скачать по ссылкам, указанным в топиках "CDialogXML" и "CMenuXML/CHotKeysXML". Например, в класс CDialogXML добавлена возможность указывать в текстах элементов управления перенос на новую строку с помощью символа "|".

Ненавижу макросы. А вот у тебя в файле PugXML.h

#define Pop()                { pCursor = pCursor->parent; }

что конфликтует с методом класса CPushRoutingView в afximpl.h.

И так будет с каждым, кто полезет [чистыми|грязными] руками в структуры языка. Это я по поводу ЯОП.

Здравствуйте, George Seryakov, Вы писали:

GS>Ненавижу макросы. А вот у тебя в файле PugXML.h

Это не у меня, это у автора парсера.

Здравствуйте, SchweinDeBurg, Вы писали:

GS>>Ненавижу макросы. А вот у тебя в файле PugXML.h

SDB>Это не у меня, это у автора парсера.

С поправкой согласен, но, как ты понимаешь, это мало что меняет.

А ошибка шикарная, давно такой не видел. Еще бы то макроопределение как-то извратить, чтобы контекстным поиском не находилось, а только просмотром файла после препроцессинга.

Здравствуйте, George Seryakov, Вы писали:

GS>С поправкой согласен, но, как ты понимаешь, это мало что меняет.

Да я понимаю, я сам там #undef-ил некоторые вещи, из-за которых не собиралось у меня. Кстати, более актуальный вариант лежит вот здесь, так что если соберетель пользовать — то лучше его.

GS>А ошибка шикарная, давно такой не видел. Еще бы то макроопределение как-то извратить, чтобы контекстным поиском не находилось, а только просмотром файла после препроцессинга.

Мсье знает толк...