Общесистемный буфер обмена

Internal structure and you change requests/suggestions
  • Wildwest
    Обычными нулями, а не '0'
    Last edited by Serge on Thu Feb 21, 2008 8:12 pm, edited 1 time in total.
  • на тип содержимого хватит и одного байта, зачем 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.
    Last edited by shurf on Sun Apr 06, 2008 1:45 pm, edited 1 time in total.
  • ИМХО не надо делать буфер, храня только PID процесса. Копируем большой текст, и вдруг закрываем прогу. И результат как минимум не приятен.
  • DonPedro, под PID процесса подразумевался PID самого менеджера буфера обмена.
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Перечитал, понял)
  • Вот моя реализация буфера обмена через процесс-демон и IPC-сообщения. Размер буфера ограничен 16 Мб, одновременно поддерживается до 16 буферов с id размером в 2 байта. Подробности в архиве.

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

    Имхо, может иметь смысл также добавить в демон горячую клавишу (например Ctrl-Alt-V) для вставки текста в приложения, которые не поддерживают работу с буфером. По этой клавише будет нужно отправить содержимое буфера с id=1 (текст) через сообщения о нажатии клавиши.
    Attachments
    clip.7z (29.68 KiB)
    Downloaded 305 times
  • А может лучше, своего рода, контейнер файлов? Ну типа папка, только её файлы в RAM.
    Наподобии врЕменной папки в far'e. Горячие клавишы: скопировать в эту папку, и загрузить из неё последний скопированный в нее элемент.
    И даже демоны не нужны.
    Что бы поудалять что-нибудь, нет нужны писать специальную прогу, это можно сделать в файловом менеджере.
    Данные можно будет загрузить в прогу не умеюшую работать с буф.

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

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

    Users browsing this forum: No registered users and 6 guests