Page 10 of 13
Re: Общесистемный буфер обмена
Posted: Sun Nov 10, 2013 7:12 am
by Mario_r4
SVN r.4199 код Clipboard (ф.54) залит в исходники ядра. Описание в файлах sysfuncs.txt и sysfuncr.txt
Внимание! API изменился и предыдущие примеры выложенные в этой теме корректно работать не будут.
Re: Общесистемный буфер обмена
Posted: Sun Nov 10, 2013 7:21 am
by Mario_r4
SVN r.4200 примеры работы с буфером обмена.
Для совсем ленивых - качаете ночную сборку r.4199 или новее, а для примеров вот архив:
Re: Общесистемный буфер обмена
Posted: Wed Nov 13, 2013 3:15 pm
by IgorA
Чего-то не сходится документация с примером, в 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.
Re: Общесистемный буфер обмена
Posted: Wed Nov 13, 2013 3:21 pm
by Mario_r4
IgorA
Да, ты прав - меня кажется переглючило, т.к. писал код ночью.
Re: Общесистемный буфер обмена
Posted: Thu Nov 14, 2013 2:56 pm
by IgorA
В связи с ревизией 4228 возник вопрос, есть ли в буфере обмена ограничение на число слотов хранимых в нем? Потому что я могу копировать в буфер текст, а очистка буфера не происходит сама по себе, разве что только с тестовым примером могу чистить.
Re: Общесистемный буфер обмена
Posted: Thu Nov 14, 2013 3:44 pm
by Mario_r4
1023 или 1024, я точно не проверял. В принципе ограничение только выделенной странице памяти и при желании количество слотов можно даже увеличить, но зачем?
1) У меня была идея по умолчанию сделать ограничение на один слот, а при помощи подфункции увеличивать при необходимости.
2) Еще есть идея реализовать закольцованность, чтобы при исчерпании всех слотов самый первый удалялся, а весь список смещался вверх.
Re: Общесистемный буфер обмена
Posted: Thu Nov 14, 2013 5:52 pm
by IgorA
Mario_r4 wrote:при желании количество слотов можно даже увеличить, но зачем?
Увеличивать не нужно. Просто возник вопрос о том, что память буфера каждый раз при копировании увеличивается и будет ли тормозить вся система при забивании буфера "на максимум".
Mario_r4 wrote:2) Еще есть идея реализовать закольцованность, чтобы при исчерпании всех слотов самый первый удалялся, а весь список смещался вверх.
Думаю это лучший вариант.
Re: Общесистемный буфер обмена
Posted: Sun Dec 01, 2013 1:29 pm
by Mario_r4
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
Re: Общесистемный буфер обмена
Posted: Sun Dec 01, 2013 5:47 pm
by Mario_r4
Все еще стоит на повестке дня вопрос с символами перевода строки. Пока что я имею два наглядных варианта Tinypad использующий 0x0d 0x0a и T_edit использующий 0xd, в качестве символов перевода строки.
Статья на википедии утверждает, что для надежности нужно использовать 0x0d 0x0a.
Есть какие то еще варианты перевода строк? И какой все же выбрать вариант для единообразия подхода?
Re: Общесистемный буфер обмена
Posted: Sun Dec 01, 2013 5:56 pm
by 0CodErr
Mario_r4, а зачем это нужно в буфере обмена? Какая ядру разница?
Mario_r4 wrote:Статья на википедии утверждает, что для надежности нужно использовать 0x0d 0x0a.
Я думаю, надо делать надёжно.
Или, как вариант, указывать тип содержимого(что-то вроде TEXT_CR, TEXT_LF, TEXT_CR_LF).
Re: Общесистемный буфер обмена
Posted: Sun Dec 01, 2013 6:12 pm
by Mario_r4
0CodErr wrote:а зачем это нужно в буфере обмена? Какая ядру разница?
Ядру разницы нет, но есть разница приложениям. Внутри себя они могут использовать все что душе программиста угодно, но вот в буфер засылать все что угодно - это создавать лишние проблемы. Так что лучше определиться со стандартом заранее, чтобы не было неожиданных сюрпризов.
0CodErr wrote:Я думаю, надо делать надёжно.
Или, как вариант, указывать тип содержимого(что-то вроде TEXT_CR, TEXT_LF, TEXT_CR_LF).
Лишний геморрой с дополнительными данными. Лучше уж единообразие для всех без исключения.
З.Ы. Также если сделать требование следовать одному стандарту, не придется писать лишний код, учитывающий все возможные варианты.
Re: Общесистемный буфер обмена
Posted: Sun Dec 01, 2013 7:02 pm
by 0CodErr
Mario_r4, тогда есть вероятность, что придётся перед копированием в буфер обмена преобразовывать в единственно верный формат. Потому что файлы с различными EOL уже и так существуют, хотим мы этого или нет.
Re: Общесистемный буфер обмена
Posted: Sun Dec 01, 2013 7:27 pm
by Mario_r4
0CodErr wrote:Mario_r4, тогда есть вероятность, что придётся перед копированием в буфер обмена преобразовывать в единственно верный формат. Потому что файлы с различными EOL уже и так существуют, хотим мы этого или нет.
Да, но не нужно тащить этот же бардак в реализацию буфера обмена. И придется преобразовывать только отличающиеся форматы. В Tinypad придется в любом случае преобразовывать, по причине собственного формата хранения во внутреннем буфере приложения. Я вообще склоняюсь к мысли остановиться на символе 0x0d (код 13) это все же даст некоторую экономию памяти, по сравнению с 0x0d 0x0a ну больших кусках текста.
Re: Общесистемный буфер обмена
Posted: Sun Dec 01, 2013 8:28 pm
by hidnplayr
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.
Re: Общесистемный буфер обмена
Posted: Sun Dec 01, 2013 8:47 pm
by Mario_r4
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.