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

Internal structure and you change requests/suggestions
  • Ну вот предлагаю так:

    Code: Select all

    OpenClipboard
    Read/Write/Clear/GetInfoClipboard
    CloseClipboard
    
    OpenClipboard - блокирует буфер только для этого приложения. CloseClipboard - разблокирует. Только надо чтобы было максимальное время в пределах которого можно вызывать остальные функции. Иначе ядро закрывает буфер и на запросы приложения отвечает ошибкой.
  • Можно и без блокировки для чтения.
    Приложение создаёт буфер 68.12 и передаёт ядру указатель и размер. Ядро при необходимости увеличит размер буфера или создаст новый. Когда буфер будет ненужен приложение освободит его. Надо только учитывать что после вызова функции адрес буфера может поменяться.
  • Serge, чем проще (для использования), тем лучше.
    Использовать 68.11 не стоит - это ограничит использование буфера обмена только для приложения которые не используют ф.64
    Лучше блокировать буфер явно. Кстати, в Windows именно так и сделано и работает вполне хорошо.
  • Чёртов файрфокс упал и убил стену текста :evil:
  • А если так:

    Подфункция 2: Прочитать из буфера
    ebx = 2
    ecx = размер буфера-приёмника
    edx = тип данных
    edi = указатель на буфер-приёмник

    Если в буфере есть запрашиваемый тип данных, то
    скопировать данные
    вернуть успех
    Иначе
    вернуть ошибку.

    Количество одновременно хранимых данных разных типов
    ядро определяет в зависимости от размера этих данных
    и размера свободной памяти.

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

    Если же всё-таки размер буфера-приёмника окажется меньше, чем размер данных, то
    вернуть ошибку и размер данных.
    Если приложение захочет, то оно сделает новый запрос с учётом этого размера.
  • johnfound
    ф64. не позволяет загружать длл и другие ограничения у неё есть. К тому же она легко эмулируется набором 68.12 и 68.26.

    read_clipboard:
    in:
    eax = ?
    ebx = ?
    ecx = buffer
    edx = format
    out:
    eax = size
    edx = buffer

    Самый простой вариант > 90% случаев

    Code: Select all

    /*    somwhere in .bss   */
    
    void *buffer;
    int   size;
    
    /*    main code          */
    
        buffer = read_clipboard(buffer, &size, format);
        if( size != 0 )
        {
            profit();
        }
    Bce операции с блокировками и памятью выполняет ядро. Если приложение передаёт ненулевой указатель то буфер должен быть создан 68.12.

    Если приложение умеет вставлять не только текст

    Code: Select all

        if( open_clipboard() )
        {
            get_clipborad_info(&info_text, FORMAT_TEXT);
            get_clipborad_info(&info_bitmap, FORMAT_BITMAP);
            get_clipborad_info(&info_raw, FORMAT_RAW);
    
            do_something();
    
            buffer = read_clipboard(buffer, &size, format);
    
            if( size != 0 )
            {
                do_even_more();
                profit();
            }
            close_clipboard();
        }
    После обработки буфера приложение может его сохранить, удалить , изменить размер, или вернуть физические страницы ядру.
  • Serge, мне твои разсуждения напоминают на Linux с котором мучаюсь напоследок. Там можно конечно делать потоки через sys_clone, но если хочется использовать xlib, то обязательно надо использовать pthreads, а память выделять через libc иначе не работает.
    Дизаин системы нужно обдумывать внимательно чтобы не допускать ненужные зависимости.
  • johnfound
    ф.68 всё же ядерные функции, а не libc. А ф.64 давно устарела.
    Дизаин системы нужно обдумывать внимательно чтобы не допускать ненужные зависимости.
    Этим и занимаемся. Пусть отпишутся те, кому этот буфер нужен.
  • Мне нужен. :) Для консольных утилит, и всех остальных тоже.
  • Отпишутся в смысле что они думают по поводу API. И про кодировку текста. Использовать unicode или нет ?
  • Мне нужен для FreshLib. FreshLib работает только в UTF-8. Но мне кажется, что ядро не надо знать ничего о данных в буфере. Только надо объявить стандартные типы данных чтобы все пользовались им, а не придумывали каждый свои. И вот в этих кодов будут и TEXT_WIN1251 и TEXT_UTF8 и т.д. (кстати я назвал бы их: cltTextWin1251 и cltTextUtf8 :) )
    Last edited by johnfound on Sun Dec 09, 2012 1:48 pm, edited 1 time in total.
  • Мне кажется, что оптимальный вариант - две подфункции.

    1) Поместить данные в буфер. Через структуру.
    dd type
    dd size
    dd address

    2) Получить данные из буфера. Через ту же структуру. Буфер не очищается.

    Преимущества: не нужно делать проверку перед тем, как забрать данные из буфера; скорее всего не нужно блокировать буфер (вытекает из первого); простота использования (например, установка type = 0 означает очистку буфера).
    Недостатки: type для каждого типа данных должно быть уникальным; пока не могу ничего сказать о расширяемости возможностей данной функции.
  • johnfound
    Всё же кодировка для текста должна быть единственной. Иначе к каждой программе надо будет цеплять конвертер на все возможные варианты.
  • Serge wrote:Можно и без блокировки для чтения.
    Приложение создаёт буфер 68.12 и передаёт ядру указатель и размер. Ядро при необходимости увеличит размер буфера или создаст новый. Когда буфер будет ненужен приложение освободит его. Надо только учитывать что после вызова функции адрес буфера может поменяться.
    Ядро создаёт буфер и передаёт во владение приложению. Когда буфер будет ненужен приложение освободит его. Такое технически возможно в даный момент?

    Нельзя давать право приложению дёргать ф-цию для чтения буфера когда хочет. Только когда пользователь нажал ctrl+c в одном окне и ctrl+v вдругом. И ядро будет разбираться со всеми указателями и размерами. А если приложение хочет в другой буфер то оно может скопировать или попросить ядро перемапить для больших размеров.

    Сама ф-ция чтение буфера вприципе-то не нужна за исключение когда размер скопировано превышает размер доступной памяти

    Приложение посылает данные в буфер обмена если какая-то глобальная комбинация клавиш нажата. И если другая глобальная комбинация нажата в окне в фокусе то окно получает право читать из буфера для текужего ID.
  • Who is online

    Users browsing this forum: No registered users and 7 guests