mikronТеперь думаю над добавлением табов / регистров.
Однооконный интерфейс имеет и минусы: операции через буфер обмена не эффевны, просмотр одного буфера в двух окнах одновременно невозможен etc.

Очередной апдейт:
Желание иметь несколько окон на один буфер победило. Ещё не всё детали обкатаны но общая картина складывается.
По открытию файла (Ctl-N) открывается новый таб если его ещё нету в текущем окне.
По открытию окна (Ctl-Shift-N) открывается новое окно с текущим буфером.

Как обычно, будут конструктивной критике.

буду рад конструктивной критике.

love_bachа где можно скачать?
Всё на том же месте.

maytonСсылка на скачивание смотрит на какой то левый ресурс. Заведи персонально хостинг под это приложение.
Он не "левый", это мой ресурс. Бесплатная версия должна хоть на рекламу работать.
Ты прав конечно, нужна отдельная страница для продукта. Я сам не специалист в вебе и тем более в дизайне,
а заказывать работу на стороне пока рано - основные задуманные функции ещё не все готовы, их ни показать ни описать.

maytonБагтрекер тоже нужен.
Нужно будет сделать. Но когда созреет. Пока ещё сыроват. (Хотя тот-же Notepad++ местами ещё недоделаней)

love_bachmikronпропущено...

Всё на том же месте.

не запускается
Опиши пожалуйста подробней. Что не запускается? Что происходит?
_{На всякий случай - по ссылке не сам редактор, а SFX - SelFeXtracted archive.}

love_bachmikronпропущено...

Опиши пожалуйста подробней. Что не запускается? Что происходит?
_{На всякий случай - по ссылке не сам редактор, а SFX - SelFeXtracted archive.}

ничего не происходит
Посмотри пожалуйста, что у тебя в EventLoge записано и отправь пожалуйста майлом на bss_editor@bergstreiser.com

интересная заметка.
Мне пришлось писать работу с clipboard в обход библиотечных фукций .Net. С учётом того что вся обработка идёт в фоновом процессе а clipboard в STA и в GUI потоке проблемы предопределены.

love_bach, Valentin Kolesnikov,

Спасибо, поправил.

maytonВсе exceptions ты должен обрабатывать в приложении и формировать бланк с сообщением и стектрейсом и предлагать отправить на поддержку.

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

Такая ситуация уже полное дерьмо и этого никому не надо.

Сегодня ситуация уже меняется. Диагностика и сбор информации - задача операционной системы. Так же как и передача диагностической информации разработчикам. Примеры тому AppleStore, Microsoft-Store или независимые дистрибьютеры.

В моём случае Windows делает всё необходимое.

mayton,

Для корпоративных клиентов - задача администратора.
Для частных клиентов - задача для Store.
Тут для виндовса

maytonmikronmayton,

Для корпоративных клиентов - задача администратора.
Для частных клиентов - задача для Store.
Тут для виндовса
Вы рассказываете мне о том чего у вас нет.

Сделайте нечто что бы дало вам возможность в полу автоматическом режиме собирать с пользователя сведенья о сбоях.
Я ценю ваше мнение, но здесь у меня другое представление. Я его уже высказал 21668838 : Это всё задачи ОС. У меня этого нет, но я делаю редактор а не ОС. И поэтому делать не буду. Решение осмысленное.

Столкнулся с интересной проблемой связанной с работой с буфером обмена.
Но чтобы её понять нужно немного истории. Первоначальная версия работала с одним файлом, но все команды выполнялись в фоновом потоке. Более того, для команд работы с файлом существует отдельный конвейер команд и один task обслуживает конвейер когда в нём появляются команды. Зачем эта сложность? Для макросов, они тоже будут.
Теперь рассмотрим, что происходит при наполнении конвейера командами работы с буфером обмена.
Пусть пользователь наполнил конвейер:
_{Я предполагаю здесь что операция поиска выполняется относительно долго.}
Первый интересный момент здесь - копирование в буфер обмена возможно только из ГУИ потока. Так же как и вставка из.
Второй интересный момент - Что ожидается как содержание буфера обмена на момент выполнения последней операции вставки.
Ответ далеко не тривиальный.

1 возможный ответ: текст из предидущей в конвейере операции копирования в буфер.
Не верно. После конвееризации команды "копирование в буфер обмена" но до "вставка из буфера обмена" пользователь мог переключится в другое приложение и сделать в нём "Ctrl-C".


2 возможный ответ: текст из буфера обмена на момент выполнения.
Не верно. Не работает.

3 возможный ответ: текст из буфера обмена на момент вставки.
Не верно. Не работает на первом приведённом сценарии

и правильный ответ: зависит от ...

В последней версии улучшения в работа с буфером обмена связанные с поддержкой многобуферного режима:
улутшения в передаче данных и её синхронизации.
Следующая версия будет посвящена стабилизации и работе с длинными строками.

Изменения

Очередное улучшение: добавил на закладки кнопки для закрытия.

Вообще задумывал ранее доделать работу с длинными строками, но приоритеты определяются собственными потребностями.
На первый взгляд это незначительное изменение: я знал что стандартный TabControl поддерживает пользовательскую отрисовку, но я ему посвятил в общей сложности 2 дня работы. Что я не учёл: при пользовательской отрисовке закладки все фиксированного размера. Это выглядело не красиво для коротких названий, и работало ужасно - отсекало имена длинных файлов.
открывая одновременно файлы с длинными именами
EngineServer_20181016_inctanceXXX_alert.log и
EngineServer_20181016_inctanceXXX.log
уже нельзя было с первого взгляда определить где какой.
Возможное решение было бы самому вычислять место и сокращать названия но вызывало сомнения что для пользователей это было бы естественно и понятно. Таким образом пришлось браться за разработку собственного TabBar и в течении 3 вечеров он был готов и я заменил им TabControl в редакторе.
Но первые же дни продуктивного использования сразу показали и недостатки: если названия файлов одинаковые но полные пути разные то необходим ToolTip.
Вроде бы опять ничего не предвещало работы, ведь в стандартном наборе для этого уже есть компонент - ToolTip. Но к сожаления он позволяет задать только один tip text для всего control-а и не позволяет задавать отдельные регионы в Control-е, которые к тому же ещё и перемещаются. Похожая динамика есть у TreeViev и ListView но они сами предоставляют tooltext и обрабатываются специальным образом методами ToolTip. Пришлось ещё и собственный ToolWindow добавить, но теперь можно вернутся к длинным строкам.
Очередная версия доступна всё там же .

Очередной анонс после продолжительный паузы.

** Много времени уделил работе с длинными строками.
Собственно их всегда приходится разбивать, иначе я не представляю как можно работать с мегабайтным файлом как например XML без переноса строк. Основная сложность заключается здесь в поддержании корректного размера табуляции. Это в свою очередь необходимо для корректного отображения выбранного региона в колоночном режиме. Да и сам колоночный режим для для длинных строк не тривиален. Для примера выбранный регион <Сторока 1, Колонка 43210> и <Строка 25, Колонка 15> приводит к тому что для его правильного отображения необходимо правильно определит начало выбранного региона на строке 1 и строке 25.
В принципе работает пока сносно но есть после выбора региона начать удалять переносы строк то нарушается отображение.
Мне пока для работы не мешает но в следующей версии буду просто убирать выделение.

** Добавил всплывающее окно для списка регистров. Когда их открывается много то искать окна в регистре переключением не удобно.
Добавил shortcut для переключения табов, их перемещения и поиска. Тут интересный момент с проблемой раскладок клавиатур.
Например на английской их легко запомнить (Ctl-<, Ctl->, Ctl-?, Ctl-Shift-<, Ctl-Shift->)
Но на немецкой это уже не работает, и получается <Ctl-, Ctl-. Ctl-'. Здесь еще предстоит подумать.

** Добавил команды для отделения регистра в отдельное окно и для переноса регистра из окна в другое окно. И так-же всплывающее окно для списка для списка всех окон. (Ctl-u, Ctl-Shift-u, Ctl-Shift-? или в зависимости от раскладки Ctl-Shift-')


Как обычно, загрузить можно здесь

И конечно все конструктивные предложения приветствуются.

И пара вопросов для сбора мнений:
-- Есть идея сделать ещё одно окно со списком всех окон. Отличие от уже существующего: Список из двух колонок с именем файла и пути и с группами по окну. То есть каждый регистр как строчка и строчки в группе - все регистры в окне. С таким GUI мне кажется можно понятнее реализовать перегруппировку окон / регистров, закрытие и возможно сохранение / востановление workspace.
Какие будут мнения - нужно ли это?

-- И какие функции вы считаете наиболее востребованными / недостающими или плохо реализованными?