>файлы разделяются нулями, список заканчивается двойным нулём
а многотомные архивы WinRar *.r00?
Общесистемный буфер обмена
Wildwest
Обычными нулями, а не '0'
Обычными нулями, а не '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?
я конечно понимаю, что некоторые хотят сэкономить аж целых 3 байта , но по-моему, в данном случае dword смотрится красивее и использовав его вместо байта, потери производительности не произойдёт. зато размер структуры - 16 байт, а это IMHO красиво. к тому же при использовании 32-разр. регистров dword использовать проще. а насчёт запаса форматов, то почему обязательно нумеровать их так: 0, 1, 2, 3? можно же и так: ...00000b, ...00001b, ...00010b, ...00100b?
просто потом мы можем придумать как заюзать эти три байта, а пока оставить пустыми..
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Народ, если это будет функция ядра, тогда и буфер будет хранится в пространстве ядра.
Может просто стандартный демон клибоарда и системная функции для обращиний к нему?
Есть еще одна идея в общесистемном буфере только хранить пид последнего процесса положившего в свой внутренний буфер некую инфу, и тип буфера коий может быть например - текстовые данные, битмап, или просто двоичные даные.
Тогда процесс обратившийся с запросом - "дайте мне буфер" просто вызывает функцию пересылки данных через канал у процесса который последний положил инфу свой буфер.
Таким нехитрым образом можно будет поддерживать много буферов, например у редакторов RTF свой, у нотпадов свой, у граф редакторов свой и т.д.
Преимущества такие:
- локальные операции (CTRL+C, CTRL+V) будут занимать меньше времени, ибо данные хранятся во внутреннем буфере
самого процесса.
- Обращение к буферу текстового редактора, не затрет содержимое буфера скажем граф редактора.
Недостаток один (и то решаемый) внутренний буфер предпоследнего процесса положившего инфу в буфер не очищается, что ведет к перерасходу памяти. Решить можно с помощью посылки сообщения всем процессам с данным типом буфера (кроме последнего положившего в буфер данные естественно) очистить внутренний буфер.
Может просто стандартный демон клибоарда и системная функции для обращиний к нему?
Есть еще одна идея в общесистемном буфере только хранить пид последнего процесса положившего в свой внутренний буфер некую инфу, и тип буфера коий может быть например - текстовые данные, битмап, или просто двоичные даные.
Тогда процесс обратившийся с запросом - "дайте мне буфер" просто вызывает функцию пересылки данных через канал у процесса который последний положил инфу свой буфер.
Таким нехитрым образом можно будет поддерживать много буферов, например у редакторов RTF свой, у нотпадов свой, у граф редакторов свой и т.д.
Преимущества такие:
- локальные операции (CTRL+C, CTRL+V) будут занимать меньше времени, ибо данные хранятся во внутреннем буфере
самого процесса.
- Обращение к буферу текстового редактора, не затрет содержимое буфера скажем граф редактора.
Недостаток один (и то решаемый) внутренний буфер предпоследнего процесса положившего инфу в буфер не очищается, что ведет к перерасходу памяти. Решить можно с помощью посылки сообщения всем процессам с данным типом буфера (кроме последнего положившего в буфер данные естественно) очистить внутренний буфер.
Если бы строители строили здания, так же как программисты пишут программы первый же залетевший дятел разрушил бы цивилизацию.
последнее означает, что скопировав в animage картинку, мы потеряем текст из tinipad'a, лежащий в буфере?
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Нет? Я-же написал в общеистемном буфере хранить инфу о процессе который последний положил в свой внутренний буфер инфу и тип буфера (текстовый, RTF, Image и т.д.) Положив текст из тинипада, потеряем текст во всех тинипадах и т.п. (у кого тектовый буфер) и получим доступ только к последнему тинипаду положившему инфу во внутренний буфер при этом всех у кого Image это не касается.Gluk wrote:последнее означает, что скопировав в animage картинку, мы потеряем текст из tinipad'a, лежащий в буфере?
Если бы строители строили здания, так же как программисты пишут программы первый же залетевший дятел разрушил бы цивилизацию.
Serge:
о потоке выполнения) в цикле.
Например, таким способом выводится список процессов по команде PS в приложении CMD.
Соответственно, процесс буфера обмена назвать @CLIP.
PID процесса можно найти по имени процесса, используя функцию 9 (информацияКстати для работы черес IPC надо знать PID сервиса.
о потоке выполнения) в цикле.
Например, таким способом выводится список процессов по команде 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 (текст) через сообщения о нажатии клавиши.
id формата предлагаю резервировать здесь, в этой ветке. Сейчас id=1 занят для обычного текста, остальные до 65534 свободны.
Имхо, может иметь смысл также добавить в демон горячую клавишу (например Ctrl-Alt-V) для вставки текста в приложения, которые не поддерживают работу с буфером. По этой клавише будет нужно отправить содержимое буфера с id=1 (текст) через сообщения о нажатии клавиши.
- Attachments
-
-
clip.7z (29.68 KiB)Downloaded 306 times
-
А может лучше, своего рода, контейнер файлов? Ну типа папка, только её файлы в RAM.
Наподобии врЕменной папки в far'e. Горячие клавишы: скопировать в эту папку, и загрузить из неё последний скопированный в нее элемент.
И даже демоны не нужны.
Что бы поудалять что-нибудь, нет нужны писать специальную прогу, это можно сделать в файловом менеджере.
Данные можно будет загрузить в прогу не умеюшую работать с буф.
Ну, а если все таки через демон, то все равно как файлы хранить.
Для текста, хорошо бы прогу, которая могла бы эммулируя нажатия клавиш впечатывать текст(тогда не нужно делать поддержку буффера в прогах, для того что бы вставить текст)
Наподобии врЕменной папки в far'e. Горячие клавишы: скопировать в эту папку, и загрузить из неё последний скопированный в нее элемент.
И даже демоны не нужны.
Что бы поудалять что-нибудь, нет нужны писать специальную прогу, это можно сделать в файловом менеджере.
Данные можно будет загрузить в прогу не умеюшую работать с буф.
Ну, а если все таки через демон, то все равно как файлы хранить.
Для текста, хорошо бы прогу, которая могла бы эммулируя нажатия клавиш впечатывать текст(тогда не нужно делать поддержку буффера в прогах, для того что бы вставить текст)
Who is online
Users browsing this forum: No registered users and 3 guests