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

Sun Nov 10, 2013 7:12 am

SVN r.4199 код Clipboard (ф.54) залит в исходники ядра. Описание в файлах sysfuncs.txt и sysfuncr.txt

Внимание! API изменился и предыдущие примеры выложенные в этой теме корректно работать не будут.

Sun Nov 10, 2013 7:21 am

SVN r.4200 примеры работы с буфером обмена.

Для совсем ленивых - качаете ночную сборку r.4199 или новее, а для примеров вот архив:

: clipboard_r4200.7z (4.34 KiB)
Downloaded 492 times

Wed Nov 13, 2013 3:15 pm

Чего-то не сходится документация с примером, в clipboard_container.txt сказано:

2.1 Текст
Данные в третьем dword содержат тип:
0 = UTF
1 = 0866

А в примере clip_put.asm видим следущее:

Code: Select all

buffer_data:
	dd buffer_data.end - buffer_data
	dd 0	; type 'text'
	dd 866	; text encoding
	db 'Test message to the clipboard'
.end:

Видимо в примере вместо 866 нужно поставить 1.

Wed Nov 13, 2013 3:21 pm

IgorA
Да, ты прав - меня кажется переглючило, т.к. писал код ночью.

Thu Nov 14, 2013 2:56 pm

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

Thu Nov 14, 2013 3:44 pm

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

1) У меня была идея по умолчанию сделать ограничение на один слот, а при помощи подфункции увеличивать при необходимости.
2) Еще есть идея реализовать закольцованность, чтобы при исчерпании всех слотов самый первый удалялся, а весь список смещался вверх.

Thu Nov 14, 2013 5:52 pm

Mario_r4 wrote:при желании количество слотов можно даже увеличить, но зачем?

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

Mario_r4 wrote:2) Еще есть идея реализовать закольцованность, чтобы при исчерпании всех слотов самый первый удалялся, а весь список смещался вверх.

Думаю это лучший вариант.

Sun Dec 01, 2013 1:29 pm

IgorA wrote:Чего-то не сходится документация с примером, в clipboard_container.txt сказано:
2.1 Текст
Данные в третьем dword содержат тип:
0 = UTF
1 = 0866
А в примере clip_put.asm видим следущее:
Code: Select all
buffer_data:
	dd buffer_data.end - buffer_data
	dd 0	; type 'text'
	dd 866	; text encoding
	db 'Test message to the clipboard'
.end:
Видимо в примере вместо 866 нужно поставить 1.

Исправлено в SVN r.4317

Sun Dec 01, 2013 5:47 pm

Все еще стоит на повестке дня вопрос с символами перевода строки. Пока что я имею два наглядных варианта Tinypad использующий 0x0d 0x0a и T_edit использующий 0xd, в качестве символов перевода строки.

Статья на википедии утверждает, что для надежности нужно использовать 0x0d 0x0a.

Есть какие то еще варианты перевода строк? И какой все же выбрать вариант для единообразия подхода?

Sun Dec 01, 2013 5:56 pm

Mario_r4, а зачем это нужно в буфере обмена? Какая ядру разница?

Mario_r4 wrote:Статья на википедии утверждает, что для надежности нужно использовать 0x0d 0x0a.

Я думаю, надо делать надёжно.
Или, как вариант, указывать тип содержимого(что-то вроде TEXT_CR, TEXT_LF, TEXT_CR_LF).

Sun Dec 01, 2013 6:12 pm

0CodErr wrote:а зачем это нужно в буфере обмена? Какая ядру разница?

Ядру разницы нет, но есть разница приложениям. Внутри себя они могут использовать все что душе программиста угодно, но вот в буфер засылать все что угодно - это создавать лишние проблемы. Так что лучше определиться со стандартом заранее, чтобы не было неожиданных сюрпризов.

0CodErr wrote:Я думаю, надо делать надёжно.
Или, как вариант, указывать тип содержимого(что-то вроде TEXT_CR, TEXT_LF, TEXT_CR_LF).

Лишний геморрой с дополнительными данными. Лучше уж единообразие для всех без исключения.

З.Ы. Также если сделать требование следовать одному стандарту, не придется писать лишний код, учитывающий все возможные варианты.

Sun Dec 01, 2013 7:02 pm

Mario_r4, тогда есть вероятность, что придётся перед копированием в буфер обмена преобразовывать в единственно верный формат. Потому что файлы с различными EOL уже и так существуют, хотим мы этого или нет.

Sun Dec 01, 2013 7:27 pm

0CodErr wrote:Mario_r4, тогда есть вероятность, что придётся перед копированием в буфер обмена преобразовывать в единственно верный формат. Потому что файлы с различными EOL уже и так существуют, хотим мы этого или нет.

Да, но не нужно тащить этот же бардак в реализацию буфера обмена. И придется преобразовывать только отличающиеся форматы. В Tinypad придется в любом случае преобразовывать, по причине собственного формата хранения во внутреннем буфере приложения. Я вообще склоняюсь к мысли остановиться на символе 0x0d (код 13) это все же даст некоторую экономию памяти, по сравнению с 0x0d 0x0a ну больших кусках текста.

Sun Dec 01, 2013 8:28 pm

0CodErr wrote:Mario_r4, а зачем это нужно в буфере обмена? Какая ядру разница?
Mario_r4 wrote:Статья на википедии утверждает, что для надежности нужно использовать 0x0d 0x0a.
Я думаю, надо делать надёжно.
Или, как вариант, указывать тип содержимого(что-то вроде TEXT_CR, TEXT_LF, TEXT_CR_LF).

Text with only CR is nonsense.
To me it seems very simple, when writing text, use CR LF (for compatibility)
When reading text, parse only LF and ignore CR.

Sun Dec 01, 2013 8:47 pm

hidnplayr wrote:To me it seems very simple, when writing text, use CR LF (for compatibility)
When reading text, parse only LF and ignore CR.

Why? After all, to any program we add support for clipboard from scratch. There is no established standard already. However, if we use 1 byte instead of 2 bytes, then a large amount of text, we can get savings of memory.

On the other hand, if the use of 2 byte code will simplify working with the clipboard, we can leave 2 bytes . I'm still thinking.

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

Who is online