Board.KolibriOS.org

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Правильно ли я понимаю, если скажем у нас имеется один слот, под номером 0, мы заносим новый текст в буфер, то брать его следует из слота 1. Так?

_________________
я лишь учусь

Да.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Ещё не заливалось на SVN?
Неплохо бы указать в документации, что буфер - это не plain text, а он имеет специфический формат.

_________________
Звиздеть не мешки ворочать

Формально буфер это контейнер, а уж его формат по идее может быть любым - все исключительно на соглашениях и честном слове.
Заливал вместе с примерами http://websvn.kolibrios.org/listing.php ... 574a3a49dd

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

SVN r.4588 функция 2 (получить код нажатой клавиши) доработана, теперь кроме ASCII еще одновременно возвращается и SCANCODE. Эта доработка необходима для реализации поддержки Ctrl+C|V в Editbox, поскольку в режиме ASCII ранее было проблематично однозначно определить нажатие нужных комбинаций клавиш, из-за меняющегося от языковой раскладки кода. Изменение API описано в файлах sysfuncr.txt и sysfuncs.txt. Также возможно возникновение глюков, в программах написанных без учета подробностей документации ф.2, так что просьба быть внимательными и сообщать на форуме о возникновении проблем в работе с клавиатурой после этой ревизии.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Программы имеющие (на текущий момент) поддержку общесистемного буфера обмена:
1) TextEdit
2) Tinypad
3) Shell
4) Editbox (компонент Box_Lib)

Программы для которых желательно наличие поддержки общесистемного буфера обмена:
1) KFAR (встроенный редактор)
2) Calc
3) HEXEDIT
4) ASCIIVju (таблица символов)
5) Table

Есть задача написать менеджер буфера обмена. Возможно потребуется доработка ф.54, для введения функции превью.

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Написал программку, показывающую содержимое. ClipboardViewer

Пока сюда, после обкатки на SVN.

Великовата из-за статической линковки. Но libc.dll пока не в образе ISO - неудобно тестировать.

Идея годная.

1. Перерисовка колбасит http://i.imgur.com/lC6y6xd.gif
2. И почему бинарник весит аж 41 Кб ? По-моему это перебор, если переписать на тот же С-- будет пара Киллобайт.

_________________
Звиздеть не мешки ворочать

Все дело в статической линковке с newlib

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

_________________
я лишь учусь

Мне, как пользователю, нужна следующая информация:
1) откуда
и
2) что
по первому пункту - ПУТЬ и программа ( если в буфере не целый файл, а кусок чего нибудь)
по второму - имя файла (да, отдельно) и описание (размер, дата создания и др) файла,
ИЛИ информация по куску чего нибудь.(текст это, или же рисунок, или..).

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

_________________
Юзер, просто юзер...со времён MS-DOS.

1) Такая информация в буфере не хранится.
2) На данный момент стандартизировано 3 типа данных: текст, изображение, любые данные.

Уменьшить будет можно, парой способов
-убрать вызов sprintf и зависимости от newlib
-линковать динамически
-пересобрать с уменьшенной libc, с помощью msvc, tinyc или c--

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

А вот почему моргает, надо думать. У меня в VmWare такого эффекта нет. Перерисовка идет каждые 0.1с.
ОС не буферизует что ли отрисовку окна между вызовами begin_draw, end_draw (sys fn 12) ?

Кстати eolite формирует отличный от всех заголовок в буфере (10 байт вместо 12) - может переделать в нем для унификации?

Зачем?

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

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

Upd. Наверное, с учетом того, что в буфер копируют ручками, достаточно проверять количество слотов.
А дополнительно принудительно перерисовывать, скажем раз в 5с.