BOARD - вывод отладочной информации

...
  • Я сейчас напишу кое чего и некоторые люди вероятно будут недовольны.

    Я считаю, что в ЭТОЙ ПРОГРАММЕ область вывода рабочего текста ВСЕГДА должна быть БЕЛОЙ, а текст ВСЕГДА должен быть ЧЕРНЫМ.
    Почему? Да, потому что спустя пару часов разглядывания текста хочется ВЫКОЛОТЬ ГЛАЗА, когда разглядываешь ТЕМНЫЙ ШРИФТ на ТЕМНО-СЕРОМ фоне. Это ПИЗДЕЦ!
    И не рассказывайте мне сказки, что нужно настроить цвет. Мне некогда это делать! Особенно если кто-то с особым "специфическим" вкусом выберет вообще темную цветовую схему, как дефолтную.

    Потому плевать мне на ваш дизайнерский изыск - срите кирпичами хоть тоннами.
    Я сделаю ЭТО, потому что НЕ ВЫ пишите код по 10-12 часов для Колибри!

    Сделано в SVN r. 2484. Сделано ДЛЯ ЛЮДЕЙ, а не для ЭСТЕТОВ.
  • Поддерживаю, давно пора. Любой дизайн - это прежде всего удобство, а уже потом заокругленные окошки и кнопочки.
    Из хаоса в космос
  • Прошу переделать сделать окно доски отладки растягиваемым и чтобы выводилось именно столько строк отладочной информации, сколько помещается. Будет полезно многим, отладочной информации иногда бывает много.
    Из хаоса в космос
  • Я не понимаю сути предложенного, также как не понимаю зачем была сделана r.2743, ведь окно программы вполне себе растягивалось на усмотрение пользователя, без дополнительных артефактов. Более того r.2743 сделала часть моих изменений направленных на учет растяжения окна, совершенно бесполезными. Чем была вызвана такая необходимость мне совершенно не понятно - нигде на форуме обсуждения не было. Программы принято "прибивать гвоздями" к фиксированным размерам, лишь в одном оправданном случае - код окна программы сделан без учета возможности растяжения. Хотелось бы видеть комментарии автора r.2743.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • И буфер побольше сделать, а то некоторые драйверы столько пишут, что часть теряется.
  • Serge wrote:И буфер побольше сделать, а то некоторые драйверы столько пишут, что часть теряется.
    Теряется потому что в ядре места мало, а программа вполне себе отрабатывает в текстовый лог.
    З.Ы. А кто у нас программист-ядерщик?
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Не знаю, я туда 100 лет не лазил
  • Mario_r4 wrote:Я не понимаю сути предложенного, также как не понимаю зачем была сделана r.2743, ведь окно программы вполне себе растягивалось на усмотрение пользователя, без дополнительных артефактов. Более того r.2743 сделала часть моих изменений направленных на учет растяжения окна, совершенно бесполезными. Чем была вызвана такая необходимость мне совершенно не понятно - нигде на форуме обсуждения не было. Программы принято "прибивать гвоздями" к фиксированным размерам, лишь в одном оправданном случае - код окна программы сделан без учета возможности растяжения. Хотелось бы видеть комментарии автора r.2743.
    Когда изменяешь размер области с текстом, то ожидаешь, что текст "зальёт" всю образовавшуюся площадь. В случае board количество строк лога задаётся константой при компиляции. Выводить количество строк по размеру окна (то, о чём говорит Leency) я тогда не осилил, поэтому сделал так, чтобы программа не обманывала, будто умеет это.

    Я не против возврата к старому поведению, но не вижу, какие преимущества оно даёт.
  • dunkaist wrote:Когда изменяешь размер области с текстом, то ожидаешь, что текст "зальёт" всю образовавшуюся площадь. В случае board количество строк лога задаётся константой при компиляции. Выводить количество строк по размеру окна (то, о чём говорит Leency) я тогда не осилил, поэтому сделал так, чтобы программа не обманывала, будто умеет это.
    Там по идее всего-то убрать в коде:

    Code: Select all

    	mov	esi,80
    	cmp	eax,esi
    	ja	@f
    
    Остальное я уже оформил, но не знал что бывают строки длиннее 80 символов - вроде это такой негласный стандарт.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Это ведь никак не влияет на размер буфера TMP и сравнения типа "cmp [ebp-4],dword MAXSTRINGS". А без этого лишних 30 строк в растянутое окно не выведешь.

    Я не считаю, что без динамического изменения буфера изменение размера окна оправдано.
  • Нужен ли переход от Доски отладки к Консоле отладки?
    Плюсы:
    - большой шрифт
    - нет ограничения на 16 строк, как в доске - можно будет промотать сообщения в консоле, если их много

    Попробовать альфу можно уже сейчас.
    Attachments
    debug.kex (1.32 KiB)
    Downloaded 367 times
    Из хаоса в космос
  • консолИ
  • Чтобы не забыть:
    1) Нужно сделать построчную запись на накопитель, вместо посимвольной - очень актуально для USB флеш накопителей, т.к. ресурс у них исчерпывается почем зря.
    2) При запуске программы старый файл лога удаляется, что не во всех случаях хорошо, так что лучше сделать размещение записи о начале новой сессии лога (к примеру с датой) и продолжать в старый файл записывать.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote:2) При запуске программы старый файл лога удаляется, что не во всех случаях хорошо, так что лучше сделать размещение записи о начале новой сессии лога (к примеру с датой) и продолжать в старый файл записывать.
    Или создавать файл с датой и временем создания в имени файла. Тогда каждый раз будет новый файл, но старый не перезапишется.
  • Who is online

    Users browsing this forum: No registered users and 1 guest