Встала сейчас проблема выбора системы справки, которая будет распространяться вместе с .net-овской программой (дотнет 2-й). От справки хочется, как возможность читать в обычном стиле (типа книжки, по разделам), так и возможность контектной справки из программы. В то же время, поиск по ключевым словам хотя и желателен, но не критичен.
Известными мне вариантами для организации системы справки являются:
Просто текстовый или Word-овский документ. Прост для чтения, но не подходит для контекстной справки.
Старый win16 help. Устарел по ряду причин. Кроме того, он неудобен и пользователи его уже толком не знают, т.к. встречается такой help редко.
chm-файлы. Всем игрушка хороша, но: случается, что она не открывается, если скопировать в каталог, в пути которого есть русские буквы; на вход компилятору Html Help Workshop подается с понтом xml (на самом деле там какой-то свой и весьма странный парсер, который иногдп не понимает валидный xml). Данное решение устроило бы, если нашелся бы способ обойти указанные проблемы. Особенно критичен в данном случае вопрос открывания chm из русской директории.
справка а ля msdn. Как ею пользоваться (и возможно ли), если нет установленного msdn. Программа нацелена на конечных пользователей, а не на разработчиков, поэтому надо расчитывать только на то, что ставится в систему по умолчанию, либо на то, что несется с собой (тут нет напрягов по месту, т.к. продукт распространяется на CD, но зато возможно есть проблемы с лицензированием — ту же основу msdn поставить скорее всего нельзя, я прав?)
справка а ля windows help and support (тот, что Start->Help And Support). Тут пока не понятно, можно ли и как с ним работать. Имел ли с такой справкой дело, какие есть для работы с ней инструменты и насколько удобно общаться с ней из .net?
рассматривается также любой другой вариант справки
Спасибо за внимание.
т.е. генеральная линия партии — трахайтесь с прикручиванием Help 2 для пользовательского применения и использования из под .net, и не трахайтесь с глюками Help 1?
и генеральной линии партии без "трахаться" не существует?
Здравствуйте, DarkGray, Вы писали:
DG>т.е. генеральная линия партии — трахайтесь с прикручиванием Help 2 для пользовательского применения и использования из под .net, и не трахайтесь с глюками Help 1?
я не вижу у chm каких-то таких глюков, которые бы не давали мне его применять
Здравствуйте, Odi$$ey, Вы писали:
OE>Здравствуйте, DarkGray, Вы писали:
DG>>т.е. генеральная линия партии — трахайтесь с прикручиванием Help 2 для пользовательского применения и использования из под .net, и не трахайтесь с глюками Help 1?
OE>я не вижу у chm каких-то таких глюков, которые бы не давали мне его применять
С этим глюком очень не хочется применять:
не открывается, если скопировать в каталог, в пути которого есть русские буквы
Поскольку пользователи вполне вероятно скопируют его в Мои документы или куда-то в подобное место. Таких будет, конечно, мало, но достаточно, чтобы обеспечить постоянный поток обращений в службу поддержки.
OE>я не вижу у chm каких-то таких глюков, которые бы не давали мне его применять
1. частичная поддержка unicode
2. недо-xml-ный формат файлов проекта (усложняется задачи генерации и частичной генерации)
3. сырость (вернее устарелость) компилятора hhc — постоянно какие-то подводные камни всплывают: то пути слишком длинные, то у строк длина слишком большая, то файлов слишком много и т.д.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, krasin, Вы писали:
A>А просто набор HTML файлов? Единственное существенно отличие от CHM — отсутсвие сжатия. А дерево и проч можно сделать. RoboHelp умеет.
Это вариант. Минус, понятно, в том, что пользователь может "поломать" справку. Плюс — в гарантированной работе.
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, krasin, Вы писали:
K>>Это вариант. Минус, понятно, в том, что пользователь может "поломать" справку.
HL>Так он при наличии кривых рук все, что хочешь поломает.
Имелось ввиду, что степень кривизны рук в данном случае может быть и не очень большой, для того чтобы можно было поломать справку.
A>А просто набор HTML файлов? Единственное существенно отличие от CHM — отсутсвие сжатия. А дерево и проч можно сделать. RoboHelp умеет.
минусы:
нет общего поиска
тяжелее распространять (хотя бы, например, создание инсталяшки — в одном случае, файл с фиксированным именем, в другом — меняющееся дерево файлов, или, например, замена на более новую версию)
более тяжеловесные (более тормозные) — содержание и index (т.к. они обычно большие, и в html-е требуют полного распарсивания и полного рендеринга)
необходимо изобретать велосипед для работы с такой справкой из под .net-а
В принципе появилась такая вот идея. Взять HTMLayout (потому что шустрый и нравится) для отображения файлов. Сами HTML файлы хранить внутри ZIP/RAR/7Z/Whatever. Наваять элемент управления для отображения всего этого чуда дело пары дней. Дерево и так есть в виде дерева файлов в архиве — его и отображать. Прикрутить относительные ссылки по самопальному протоколу а ля help:// дело 5 минут. Редакторов HTML файлов завались. Единственная существенная загвоздка в индексации и поиске.
А так, не внешний просмотрщик, а именно .Net компонент куда круче. Текст справки можно и в тултипе показывать, и в окне программы открывать (как VS), и рядом (как офис). Да и с путями файлов и прочьей ерундой проблем быть уже не должно. Вот я думаю, если бы мне кто-то помог разобратсья с индексацией и поиском, я бы может и написал в свободное время что-то подобное...
Можно сделать небольшой мостик между HTML файлами и пользователем — справку поместить в архив и налету ее показывать с помощью небольшой программки, включающей в себя Web Browser.
Здравствуйте, krasin, Вы писали:
OE>>я не вижу у chm каких-то таких глюков, которые бы не давали мне его применять
K>С этим глюком очень не хочется применять: K>
K>не открывается, если скопировать в каталог, в пути которого есть русские буквы
K>Поскольку пользователи вполне вероятно скопируют его в Мои документы или куда-то в подобное место. Таких будет, конечно, мало, но достаточно, чтобы обеспечить постоянный поток обращений в службу поддержки.
у меня все chm -ы нормально открываются в каталогах с русскими именами Не открываются они только если в пути есть символ #.
Здравствуйте, DarkGray, Вы писали:
OE>>я не вижу у chm каких-то таких глюков, которые бы не давали мне его применять
DG>1. частичная поддержка unicode
м.б., меня не напрягает DG>2. недо-xml-ный формат файлов проекта (усложняется задачи генерации и частичной генерации)
м.б., генерацией не занимался, тем не менее таковые генераторы chm по коментариям в тексте программ существуют DG>3. сырость (вернее устарелость) компилятора hhc — постоянно какие-то подводные камни всплывают: то пути слишком длинные, то у строк длина слишком большая, то файлов слишком много и т.д.
это есть, русские имена htm лучше не использовать (но у меня и нет такой привычки), ограничения по количеству файлов вполне решаются разбиением справки на несколько chm (оно вообще говоря и само по себе не вредно), да и возникает эта проблема если в chm заталкивать сайт типа rsdn
Здравствуйте, Odi$$ey, Вы писали:
OE>у меня все chm -ы нормально открываются в каталогах с русскими именами Не открываются они только если в пути есть символ #.
ОС какая? Я проверял на Win2k3.
Спасибо за то, что сообщили. Если эта проблема специфична для Win2k3, то на нее точно можно забить.
Здравствуйте, c-smile, Вы писали:
CS>Joel сделал из htmlayout "родной" .NET component. CS>Он как-то даже исхитрился саму dll в сборку засунуть.
Хм... а смысл?
Вобщем я прикручу поддержку событий (всё руки не доходят) и пользовательских протоколов загрузки данных (типа локального APP) и будет замечательный .Net Interop.
Здравствуйте, krasin, Вы писали:
OE>>у меня все chm -ы нормально открываются в каталогах с русскими именами Не открываются они только если в пути есть символ #. K>ОС какая? Я проверял на Win2k3.
Win2k3, открывать я пробовал из OC и программно через HtmlHelp(). Или речь шла именно о .net-ской реализации обращения к chm?
Не открываются они только если в пути есть символ #.
