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

Internal structure and you change requests/suggestions
  • Mario_r4, тогда есть вероятность, что придётся перед копированием в буфер обмена преобразовывать в единственно верный формат. Потому что файлы с различными EOL уже и так существуют, хотим мы этого или нет.
  • 0CodErr wrote:Mario_r4, тогда есть вероятность, что придётся перед копированием в буфер обмена преобразовывать в единственно верный формат. Потому что файлы с различными EOL уже и так существуют, хотим мы этого или нет.
    Да, но не нужно тащить этот же бардак в реализацию буфера обмена. И придется преобразовывать только отличающиеся форматы. В Tinypad придется в любом случае преобразовывать, по причине собственного формата хранения во внутреннем буфере приложения. Я вообще склоняюсь к мысли остановиться на символе 0x0d (код 13) это все же даст некоторую экономию памяти, по сравнению с 0x0d 0x0a ну больших кусках текста.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • 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.
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • 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.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote:
    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.
    Any program should accept any encoding, this has nothing to do with clipboard.
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • hidnplayr wrote:Any program should accept any encoding, this has nothing to do with clipboard.
    However, this increases the number of possible choices and therefore inflates code. I've come across in Windows with the situation where the standard Notepad does not understand line breaks. If the conditions for the buffer exchange would be more rigid, then such situations can be avoided in principle.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • hidnplayr wrote:Text with only CR is nonsense.
    For example:http://en.wikipedia.org/wiki/End_of_lin ... sentations
    • LF: Multics, Unix and Unix-like systems (GNU/Linux, OS X, FreeBSD, AIX, Xenix, etc.), BeOS, Amiga, RISC OS and others.
      CR+LF: Microsoft Windows, DEC TOPS-10, RT-11 and most other early non-Unix and non-IBM OSes, CP/M, MP/M, DOS (MS-DOS, PC DOS, etc.), Atari TOS, OS/2, Symbian OS, Palm OS, Amstrad CPC
      LF+CR: Acorn BBC and RISC OS spooled text output.
      CR: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Mac OS up to version 9 and OS-9
      RS: QNX pre-POSIX implementation.
    I'm not sure, maybe it actually nonsense.
  • 0CodErr wrote:
    hidnplayr wrote:Text with only CR is nonsense.
    For example:http://en.wikipedia.org/wiki/End_of_lin ... sentations
    • LF: Multics, Unix and Unix-like systems (GNU/Linux, OS X, FreeBSD, AIX, Xenix, etc.), BeOS, Amiga, RISC OS and others.
      CR+LF: Microsoft Windows, DEC TOPS-10, RT-11 and most other early non-Unix and non-IBM OSes, CP/M, MP/M, DOS (MS-DOS, PC DOS, etc.), Atari TOS, OS/2, Symbian OS, Palm OS, Amstrad CPC
      LF+CR: Acorn BBC and RISC OS spooled text output.
      CR: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Mac OS up to version 9 and OS-9
      RS: QNX pre-POSIX implementation.
    I'm not sure, maybe it actually nonsense.
    MAC OS 9 was discontinued in 2002, should we still care? maybe.. maybe not :)
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • Mario_r4
    If you want single-byte line break, single LF (Unix style) is better than single CR (Mac style), unless you also want to define your own, incompatible, Kolibri-only format, assumes programs must be written from scratch or specially adopted to Kolibri.
  • Ok, let the majority will be right again - I'm tired of arguing with you guys. Time will heal all.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • SVN r.4343 - изменил документацию, добавил текст с блочным выделением.
    Downloaded 395 times
    Downloaded 376 times
    Если кто может подправить мой кривоватый английский перевод, то просьба сделать, можно даже на SVN сразу.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • А нумерация слотов идет с нуля или единицы?
    to infinity and beyond
  • punk_joker wrote:А нумерация слотов идет с нуля или единицы?
    С нуля разумеется. Я же программист, а не гуманитарий. :mrgreen:
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Если я правильно понял, то при записи номер слота не указывается, но при чтении его указать необходимо. В какой слот тогда происходит запись?
    Spoiler:======================================================================
    ====================== Функция 54, подфункция 2 ======================
    ================== Считать данные из буфера обмена. ==================
    ======================================================================
    Параметры:
    * eax = 54 - номер функции
    * ebx = 2 - номер подфункции
    * eсx = номер слота
    * edx = не используется, оставлено для единообразия
    * esi = указатель на буфер под копируемые данные
    Возвращаемое значение:
    * eax = 0 - успешно
    * eax = 1 - ошибка
    * eax = -1 - отсутствует область главного списка

    ======================================================================
    ====================== Функция 54, подфункция 3 ======================
    ================== Записать данные в буфер обмена. ===================
    ======================================================================
    Параметры:
    * eax = 54 - номер функции
    * ebx = 3 - номер подфункции
    * eсx = не используется, оставлено для единообразия
    * edx = количество копируемых байт
    * esi = указатель на буфер под копируемые данные
    Возвращаемое значение:
    * eax = 0 - успешно
    * eax = 1 - ошибка
    * eax = -1 - отсутствует область главного списка
    to infinity and beyond
  • Who is online

    Users browsing this forum: No registered users and 5 guests