Board.KolibriOS.org

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

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

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

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

Да.

Mario_r4 wrote:SVN r.4343 - изменил документацию, добавил текст с блочным выделением.

clipboard_container_rus.txt

clipboard_container_eng.txt

Если кто может подправить мой кривоватый английский перевод, то просьба сделать, можно даже на SVN сразу.

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

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

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

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

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

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

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

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

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

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

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

Идея годная.

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

Leency wrote:Идея годная.
2. И почему бинарник весит аж 41 Кб ? По-моему это перебор, если переписать на тот же С-- будет пара Киллобайт.

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

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

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

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

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

Leency wrote:Идея годная.

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

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

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

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

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

Siemargl wrote:Перерисовка идет каждые 0.1с

Зачем?

Pathoswithin wrote:

Siemargl wrote:Перерисовка идет каждые 0.1с

Зачем?

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

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

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