Board.KolibriOS.org

>файлы разделяются нулями, список заканчивается двойным нулём

а многотомные архивы WinRar *.r00?

Wildwest
Обычными нулями, а не '0'

на тип содержимого хватит и одного байта, зачем dword? не думаю что будет больше 256-ти типов содержимого

а так - поддерживаю вариант системной функции..

Gluk
я конечно понимаю, что некоторые хотят сэкономить аж целых 3 байта , но по-моему, в данном случае dword смотрится красивее и использовав его вместо байта, потери производительности не произойдёт. зато размер структуры - 16 байт, а это IMHO красиво. к тому же при использовании 32-разр. регистров dword использовать проще. а насчёт запаса форматов, то почему обязательно нумеровать их так: 0, 1, 2, 3? можно же и так: ...00000b, ...00001b, ...00010b, ...00100b?

просто потом мы можем придумать как заюзать эти три байта, а пока оставить пустыми..

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

Есть еще одна идея в общесистемном буфере только хранить пид последнего процесса положившего в свой внутренний буфер некую инфу, и тип буфера коий может быть например - текстовые данные, битмап, или просто двоичные даные.
Тогда процесс обратившийся с запросом - "дайте мне буфер" просто вызывает функцию пересылки данных через канал у процесса который последний положил инфу свой буфер.
Таким нехитрым образом можно будет поддерживать много буферов, например у редакторов RTF свой, у нотпадов свой, у граф редакторов свой и т.д.
Преимущества такие:
- локальные операции (CTRL+C, CTRL+V) будут занимать меньше времени, ибо данные хранятся во внутреннем буфере
самого процесса.
- Обращение к буферу текстового редактора, не затрет содержимое буфера скажем граф редактора.

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

последнее означает, что скопировав в animage картинку, мы потеряем текст из tinipad'a, лежащий в буфере?

Gluk wrote:последнее означает, что скопировав в animage картинку, мы потеряем текст из tinipad'a, лежащий в буфере?

Нет? Я-же написал в общеистемном буфере хранить инфу о процессе который последний положил в свой внутренний буфер инфу и тип буфера (текстовый, RTF, Image и т.д.) Положив текст из тинипада, потеряем текст во всех тинипадах и т.п. (у кого тектовый буфер) и получим доступ только к последнему тинипаду положившему инфу во внутренний буфер при этом всех у кого Image это не касается.

Serge:

Кстати для работы черес IPC надо знать PID сервиса.

PID процесса можно найти по имени процесса, используя функцию 9 (информация
о потоке выполнения) в цикле.
Например, таким способом выводится список процессов по команде PS в приложении CMD.
Соответственно, процесс буфера обмена назвать @CLIP.

ИМХО не надо делать буфер, храня только PID процесса. Копируем большой текст, и вдруг закрываем прогу. И результат как минимум не приятен.

DonPedro, под PID процесса подразумевался PID самого менеджера буфера обмена.

Перечитал, понял)

Вот моя реализация буфера обмена через процесс-демон и IPC-сообщения. Размер буфера ограничен 16 Мб, одновременно поддерживается до 16 буферов с id размером в 2 байта. Подробности в архиве.

id формата предлагаю резервировать здесь, в этой ветке. Сейчас id=1 занят для обычного текста, остальные до 65534 свободны.

Имхо, может иметь смысл также добавить в демон горячую клавишу (например Ctrl-Alt-V) для вставки текста в приложения, которые не поддерживают работу с буфером. По этой клавише будет нужно отправить содержимое буфера с id=1 (текст) через сообщения о нажатии клавиши.

А может лучше, своего рода, контейнер файлов? Ну типа папка, только её файлы в RAM.
Наподобии врЕменной папки в far'e. Горячие клавишы: скопировать в эту папку, и загрузить из неё последний скопированный в нее элемент.
И даже демоны не нужны.
Что бы поудалять что-нибудь, нет нужны писать специальную прогу, это можно сделать в файловом менеджере.
Данные можно будет загрузить в прогу не умеюшую работать с буф.

Ну, а если все таки через демон, то все равно как файлы хранить.

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