powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Иструменты для генерации документации API
18 сообщений из 18, страница 1 из 1
Иструменты для генерации документации API
    #39831998
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Стало вдруг интересно, может узнаем про другие инструменты и решения :)
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39831999
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сразу поясню, речь идёт не о публичном API, типа REST API и т.п., а документация кода проекта.
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39832099
Дмитрий77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

Сколько я этот Doxygen применительно к чужим OpenSource ни пытался читать, никогда как правило ничего не понимал без ковыряний самих кодов и разбора примеров (при наличии).
ИМХО, хочешь делать на паблик чтоб тебя понимали, пиши Help сам, тяжело долго и нудно, вооружившись гуглопереводчиком, подсматривая фразообороты у конкурентов по схожей тематике и т.п.
А для себя (чтоб через N лет понять что имелось ввиду) мне отдельных комментариев в коде хватает.
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39832536
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дмитрий77,

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

Генерация документации позволяет давать ссылки на АПИ из постановок задач, добавлять туда примеры, линковать страницы, а нормальный полнотекстовый поиск позволяет в доке быстро находить нужные АПИ.

Жаль, что тенденция отсутствия документации в коде сохраняется.
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833010
Дмитрий77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

Я более 10 лет работаю с вот этим:
OpalVoip
Библиотека ну очень крута и востребована теми кто в теме.

Как видим, ссылки на документацию ныне вообще не доступны (потому что эта "документация" видимо не востребована, чего править ссылки, вчера svn, сегодня git, завтра "сообщество" еще какую-нибудь хрень придумает).
APIDocumentation

Копать нормально можно вместе с кодом только.
Собственно весь этот Doxygen берется очевидно из комментариев из файла ниже, и в общем они не плохи.
https://sourceforge.net/p/opalvoip/opal/ci/master/tree/include/opal.h

Ответная часть с кодами этих API:
https://sourceforge.net/p/opalvoip/opal/ci/master/tree/src/opal/opal_c.cxx

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

Ну, если чего-нибудь простенькое и с закрытыми кодами, тогда м.б. смысл этой документации и есть, но чтоб эти комменты для генерации доков написать, чтоб другому человеку было хоть что-то понятно, все одно надо будет потратить кучу времени.
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833019
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttДмитрий77,

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

Генерация документации позволяет давать ссылки на АПИ из постановок задач, добавлять туда примеры, линковать страницы, а нормальный полнотекстовый поиск позволяет в доке быстро находить нужные АПИ.

Жаль, что тенденция отсутствия документации в коде сохраняется.

а что еще должно там быть? обычно есть некоторый контекст, архитектура, и там нет смысла городить комментарии, это если для внутреннего пользования - решают названия методов, переменных. а для внешнего - одного описания метода мало: надо описывать сценарии, в каких он используется. и там эссе на много буков. это имеет смысл для API, например, припомощи Swagger
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833043
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
love_bachа что еще должно там быть?

1. Пояснение: бизнесовый, инфраструктурный или архитектурный смысл.
2. Ограничения, применение, рекомендации, различные тонкости и ньюансы, если они есть.
3. Примеры использования, ссылки на связанные конструкции.


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

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


love_bachа для внешнего - одного описания метода мало: надо описывать сценарии, в каких он используется. и там эссе на много буков. это имеет смысл для API, например, припомощи Swagger

Если требуется, конечно сценарии использования нужны. Но если весь код правильно документируется, то количество текста, которое надо писать на каждый метод выходит не много. Всё решает полнота и кросс-ссылки по коду.

Одно из крупнейших заблуждений, что дока нужна только для внешнего публичного API. Но не умение писать внутреннюю документацию АПИ также отражается и на качестве внешней. Не вооружённым глазом видны потуги и кровавые страдания человека, который вынужден заниматься тем, чем заниматься абсолютно не умеет и не привык :)
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833046
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дмитрий77Но без самого кода фиг чего поймешь. Плюс примеры, плюс переписка с автором.

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


Дмитрий77Ну, если чего-нибудь простенькое и с закрытыми кодами, тогда м.б. смысл этой документации и есть, но чтоб эти комменты для генерации доков написать, чтоб другому человеку было хоть что-то понятно, все одно надо будет потратить кучу времени.

Насчёт генераторов доки, зачем они нужны.. вот же пример из ссылки, которую ты дал:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
/** Initialise the OPAL system, returning a "handle" to the system that must
    be used in other calls to OPAL.

    The version parameter indicates the version of the API being used by the
    caller. It should always be set to the constant OPAL_C_API_VERSION. On
    return the library will indicate the API version it supports, if it is
    lower than that provided by the application.

    The C string options are space separated tokens indicating various options
    to be enabled, for example the protocols to be available. NULL or an empty
    string will load all available protocols. The current protocol tokens are:
        <code>
        sip sips h323 h323s iax2 pc local pots pstn ivr
        </code>
    The above protocols are in priority order, so if a protocol is not
    explicitly in the address, then the first one of the opposite "category"
    s used. There are two categories, network protocols (sip, h323, iax & pstn)
    and non-network protocols (pc, local, pots & ivr).

    Additional options are in similar form to command line arguments:
        <table border=0>
        <tr><td>-t or --trace         <td>Enable trace log. Multiple instances
                                          increase the trace level.
        <tr><td>-l or --trace-level X <td>Enable trace log and set level to X.
        <tr><td>-o or --output "name" <td>Set the filename for trace log output.
        <tr><td>-l or --trace-option X <td>Enable trace log option, use +X or -X
                                           to add/remove option where X is one of:
            <table>
            <tr><td>block    <td>PTrace::Block constructs in output
            <tr><td>time     <td>time since prgram start
            <tr><td>date     <td>date and time
            <tr><td>gmt      <td>Date/time is in UTC
            <tr><td>thread   <td>thread name and identifier
            <tr><td>level    <td>log level
            <tr><td>file     <td>source file name and line number
            <tr><td>object   <td>PObject pointer
            <tr><td>context  <td>context identifier
            <tr><td>daily    <td>rotate output file daily
            <tr><td>hour     <td>rotate output file hourly
            <tr><td>minute   <td>rotate output file every minute
            <tr><td>append   <td>append to output file, otherwise overwrites
                             &lt;perm&gt; <td>file permission similar to unix chmod,
                             but starts with +/- and only has one combination at a
                             time, e.g. +uw is user write, +or is other read, etc
            </table>
        <tr><td>-c or --config "dir"  <td>Configuration file or directory.
        <tr><td>-p or --plugin "dir"  <td>Plugin module directory.
        <tr><td>-m or --manaufacturer "str" <td>Manufacturer name for application.
        <tr><td>-n or --name "str"    <td>Product name for application.
        <tr><td>-M or --major X       <td>Major version number.
        <tr><td>-N or --minor X       <td>Minor version number.
        <tr><td>-R or --status X      <td>Code status ("alpha", "beta" or "release").
        <tr><td>-B or --build X       <td>Build/patch number.
        </table>
    It should also be noted that there must not be spaces around the '=' sign
    in the above options.

    If NULL is returned then an initialisation error occurred. This can only
    really occur if the user specifies prefixes which are not supported by
    the library.

    Example:
      <code>
      OpalHandle hOPAL;
      unsigned   version;

      version = OPAL_C_API_VERSION;
      if ((hOPAL = OpalInitialise(&version,
                                  OPAL_PREFIX_H323  " "
                                  OPAL_PREFIX_SIP   " "
                                  OPAL_PREFIX_IAX2  " "
                                  OPAL_PREFIX_PCSS
                                  " TraceLevel=4")) == NULL) {
        fputs("Could not initialise OPAL\n", stderr);
        return false;
      }
      </code>
  */
extern OpalHandle OPAL_EXPORT OpalInitialise(unsigned * version, const char * options);

/** String representation of the OpalIntialise() which may be used for late
    binding to the library.
 */
#if _WIN32
  #define OPAL_INITIALISE_FUNCTION MAKEINTRESOURCE(1)
#else
  #define OPAL_INITIALISE_FUNCTION "OpalInitialise"
#endif



В сгенерированном виде это будет явно читабельней, а также с нормальной навигацией по иерархии, навигацией по ссылкам и подсветкой синтаксиса в примерах.

Ну и самое главное. Полнотекстовый поиск по документации -- маст хев.


Дмитрий77Как видим, ссылки на документацию ныне вообще не доступны (потому что эта "документация" видимо не востребована, чего править ссылки, вчера svn, сегодня git, завтра "сообщество" еще какую-нибудь хрень придумает).
APIDocumentation

Просто некому поддерживать видимо. Иначе уже давно бы утащили на гитхаб :)
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833050
Дмитрий77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttПросто некому поддерживать видимо. Иначе уже давно бы утащили на гитхаб :)
Ну, судя по последним изменениям автор либу то поддерживает:
https://sourceforge.net/p/opalvoip/opal/ci/master/tree/

К слову, какие-то старые ссылки открываются (которые depricated, начиная с 3-ей):
http://files.opalvoip.org/docs/opal-v3_14/index.html

hVosttвот же пример из ссылки, которую ты дал:...
В сгенерированном виде это будет явно читабельней, а также с нормальной навигацией по иерархии, навигацией по ссылкам и подсветкой синтаксиса в примерах.
Ну вот оно кажется:
opal.h File Reference

Ну, я лично пользуюсь двумя старыми версиями, 2012 и кажется 2010 года.
Просто в один прекрасный момент автор (фактически автор один, австралиец) начал дурить и портить собственное детище что-то фундаментально переписав,
из-за чего нормальные проекты (не мои) перестали нормально работать, компилироваться и т.д.
Ему про это написали (уважаемые люди), он не согласился. Точка невозврата была пройдена. Последние годы автор так понимаю наедине с собой, видимо кому-то что-то делает какую-то работу, под себя и правит как хочет.
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833057
Дмитрий77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttЖаль, что тенденция отсутствия документации ... сохраняется.
Ну, а что вы хотите.

Допустим у меня есть новая идея, я хочу ее добавить в продукт.
1) Чтоб примерно понять алгоритм чего хочу пары часов - полдня достаточно
2) Чтоб сделать функциональный код (API, классы, говнокод, да какая разница), ну допустим несколько дней - неделя
3) Чтоб сделать достойное GUI под это дело, скажем недели 2-3
4) Чтоб воткнуть "многоязычнось" - механизм, перевод хотя б на один язык - еще столько же
5) сделать En Help (из хэлпа предыдущей версии) -иногда месяц, если идей/изменений несколько и добавлен новый функционал, а не просто фиксы: картинки, описания, навигация
6) сделать еще скажем русский help - не намного меньше
7) скомпоновать все это в готовый setup.exe, размещение, реклама, вэбсайт - еще месяц может уйти

Времени уходит вагон, ну в итоге оно оправдывается.

И естественно большинство людей сосредоточены на п.п. 1-2, потому что все что дальше это рутина (хотя когда-то в освоение GUI, принципа хэлпов, перевода было вложено много творческих "программных" сил - ток. когда это было). "Проф. роста" - никакого, программирование - стремится к нулю, одно копирование кодов и использование своих же когда-то написанных модулей/классов про которые уже порой плохо понимаешь как они устроены, хорошо если помнишь "как приткнуть".
Но в то же время без п.п. 3-7 кота не продашь. Отупеваешь, но продукт то "развивается". А что делать?
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833444
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дмитрий77Ну, судя по последним изменениям автор либу то поддерживает:
https://sourceforge.net/p/opalvoip/opal/ci/master/tree/

в одиночку тяжело тащить такие проекты, контрибьтеров судя по логу больше нет (

Дмитрий77Ему про это написали (уважаемые люди), он не согласился. Точка невозврата была пройдена. Последние годы автор так понимаю наедине с собой, видимо кому-то что-то делает какую-то работу, под себя и правит как хочет.

к успеху идёт... но медленно )


Дмитрий77Допустим у меня есть новая идея, я хочу ее добавить в продукт.
1) Чтоб примерно понять алгоритм чего хочу пары часов - полдня достаточно
2) Чтоб сделать функциональный код (API, классы, говнокод, да какая разница), ну допустим несколько дней - неделя
3) Чтоб сделать достойное GUI под это дело, скажем недели 2-3
4) Чтоб воткнуть "многоязычнось" - механизм, перевод хотя б на один язык - еще столько же
5) сделать En Help (из хэлпа предыдущей версии) -иногда месяц, если идей/изменений несколько и добавлен новый функционал, а не просто фиксы: картинки, описания, навигация
6) сделать еще скажем русский help - не намного меньше
7) скомпоновать все это в готовый setup.exe, размещение, реклама, вэбсайт - еще месяц может уйти

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

мне вот интересно, сколько удовольствия ты найдёшь в том, чтобы согласовывать, пояснять и погрязнуть в коммуникации вместо того, чтобы собственно работой заниматься :)

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

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


Дмитрий775) сделать En Help (из хэлпа предыдущей версии) -иногда месяц, если идей/изменений несколько и добавлен новый функционал, а не просто фиксы: картинки, описания, навигация

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


Дмитрий77хорошо если помнишь "как приткнуть"

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

Дмитрий77Отупеваешь, но продукт то "развивается". А что делать?

ну это как про уровень комфорта. кому-то комфортно жить в бардаке и на дошираке. но повысив свой уровень комфорта, уже непонятно как можно было так жить :)
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833536
Дмитрий77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttэто всё понятно. а теперь заменим в условии "я", на "мы", и это "мы" может быть командой разработчиков десяток другой, в которой также имеется какая никакая текучка.

мне вот интересно, сколько удовольствия ты найдёшь в том, чтобы согласовывать, пояснять и погрязнуть в коммуникации вместо того, чтобы собственно работой заниматься :)

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

Понятно, что с командой можно добиться сильно больше. Но это не каждому дано и не всегда оправдано.
Но команда - это когда команда единомышленников, каждый из которых реальный специалист этого дела.
Можно замутить бизнес, набрать кредитов и прогореть.
А можно спокойно и стабильно заниматься чем-то в одиночку, спокойно и без рисков (и даже без вложений). При этом вполне комфортно и не "на дошираках".
Ну, к "славе Высоцкого Зеленского" (очень хороший пример "команды") конечно таким путем не прийти, это ясно. Но каждому своя ниша.
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833539
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дмитрий77Из того что в бизнесе занято 20 человек, еще не следует что денег будет в 20 или в 200 раз больше и в 20 раз быстрее.

Вроде как не следует. Однако всем известные крупные продукты разрабатывают не три человека :)

Мой же опыт показывает, что командная разработка имеет абсолютное преимущество по всем фронтам без исключения против инди. Из хороших продуктов, написанных одним человеком можно найти разве что вылизанные до блеска утилиты, или крутые плагины. Но не полноценные решения, которые будут интересны бизнесу.

Инди можно найти в кабинетах компаний, не причастных никаким боком к ИТ. Несколько человек в таких конторах не являются командой, они просто коллеги и сидят либо в одном либо в соседних кабинетах, и у каждого свой _проэкт_, а то и несколько. По совокупности, это небольшие АРМы, по большему счёту на сопровождении, так как никто не предъявляет никакие требования ни по качеству, ни по надёжности, ни по расширяемости, ни по чему. Как-то работает вроде, ну и зашибись :)

Ну и фрилансеры конечно, обычно на подряде.

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

Как бы вопрос не в том, как жить хорошо и зарабатывать. И не в славе дело. Тем более это личное дело каждого. И для одиночной разработки писать документацию без желания и видимых перспектив командной работы, это даже выглядит глупо, так что спорить тут я не могу ))
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833545
Дмитрий77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttКак бы вопрос не в том, ...
Согласен. Вопрос/опрос был не в том.
Вопрос был "какие инструменты используете " а не "зачем это надо и чего вообще надо".
Чет меня понесло...
Сам не люблю когда задаю конкретный вопрос, ответ давно получен, а начинаются рассуждения на общие темы.
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833589
Roman Mejtes
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
всё плохо, товарищи
и ни кто не хочет за это платить, хотят, чтоб платили за это мы, по сути
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833599
Дмитрий77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Roman Mejtes,

Кому по сути эти доки нужны. Тому кто писал код - он и без них и через 10 лет легко разберется что он написал и сумеет воспользоваться. А нужны они хозяину "команды", который наемного сотрудника выгонит и посадит на его место другого, а вот и доки - все ходы записаны и оформлены. А тому кто писал код они в этом смысле даже вредны. Нужны эти комменты хозяину - пусть платит, причем в 5 раз больше чем за код, который они описывают.
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833601
Roman Mejtes
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дмитрий77Roman Mejtes,

Кому по сути эти доки нужны. Тому кто писал код - он и без них и через 10 лет легко разберется что он написал и сумеет воспользоваться. А нужны они хозяину "команды", который наемного сотрудника выгонит и посадит на его место другого, а вот и доки - все ходы записаны и оформлены. А тому кто писал код они в этом смысле даже вредны. Нужны эти комменты хозяину - пусть платит, причем в 5 раз больше чем за код, который они описывают.
да вот фиг, есть проект, меньше года на нём, документации кроме моих комментариев никто не ведет. ни черта изначально не продумали, 30 раз всё меняли и переделывали, у меня в голове уже кисель от их "переделок". уже горит жопа прямо, совершенно не проработали на этапе проектирования, я теперь уже сам плохо помню, где, что и как должно и как работает.
короче худший проект в моей жизни.
а когда проект изначально нормально продуман, архитектура, все постановки и спец., то всё помнится и через 5 лет.
...
Рейтинг: 0 / 0
Иструменты для генерации документации API
    #39833608
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Roman Mejtesда вот фиг, есть проект, меньше года на нём, документации кроме моих комментариев никто не ведет. ни черта изначально не продумали, 30 раз всё меняли и переделывали, у меня в голове уже кисель от их "переделок". уже горит жопа прямо, совершенно не проработали на этапе проектирования, я теперь уже сам плохо помню, где, что и как должно и как работает.
короче худший проект в моей жизни.
а когда проект изначально нормально продуман, архитектура, все постановки и спец., то всё помнится и через 5 лет.
Нормальный проект продумать изначально невозможно.
Продумывается некоторый концепт(ы), потом она сама живет и развивается, если это кому то надо.
Обычно все через некоторое время умирает, если никто усиленно не занимается маркетингом.
Но, легче заниматься каким то Орал - Д в плане маркетинга и прибылей, чем ОС/2.
...
Рейтинг: 0 / 0
18 сообщений из 18, страница 1 из 1
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Иструменты для генерации документации API
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]