RawInput WinAPI: GetRawInputBuffer () и обработка сообщений

Question

Почему
Я пытаюсь получить данные от сканера штрих-кода в моем (визуальном) приложении. Я хотел бы игнорировать ввод с других устройств и получать ввод, даже если приложение теряет фокус. Я нашел API RawInput, рекомендованный для SO, а также для других целей, для достижения этой цели.

Я сосредоточился на GetRawInputBuffer () для чтения ввода, поскольку я ожидаю ~ 2 сканирования в второе и ~ 700 событий (нажатие клавиши / нажатие клавиши вверх) запускаются для каждого сканирования (при условии, что сканер работает как клавиатура). В документации упоминается использование GetRawInputBuffer () «для устройств, которые могут генерировать большое количество необработанного ввода». Я не знаю, соответствует ли вышесказанное действительности ...

Проблема
Я успешно получил входные данные - но есть кое-что, что я должен делать неправильно (возможно, фундаментально. ..) поскольку я не могу найти хороший способ получить последовательные результаты. Необработанные данные, кажется, «исчезают» очень быстро, и я часто не получаю никаких данных. Существуют аналогичные существующие вопросы о SO по поводу GetRawInputBuffer (), но они дошли до меня до сих пор ... Некоторые примечания:

• Я использую 'unRawInput.pas' из https://github.com/lhengen/RawInput
• Я создаю дескриптор окна с помощью AllocateHwnd () и регистрирую его для необработанного ввода

(редактировать) Вопрос
Как / когда я должен ( правильно) вызвать GetRawInputBuffer () в визуальном приложении, чтобы получить согласованные результаты, например, все ключевые события с момента последнего вызова? Или: Как / почему события «отбрасываются» между вызовами и как я могу предотвратить это?

Код
Приведенный ниже код представляет собой 64-битное консольное приложение, демонстрирующее 3 подхода. До сих пор пробовали и их проблемы (подходы раскомментирования / комментирования, как описано в комментариях к коду основного блока begin-end.-block).

• подход # 1: Sleep () во время ввода происходит, то читая буфер сразу. Мне пришла в голову идея Sleep () из примера кода docs.microsoft.com - и он работает очень хорошо, поскольку кажется, что он получает все входные данные, но я не думаю, что это практично, так как мой Приложение должно оставаться отзывчивым.
• подход № 2: используйте GetMessage () - обычно это не дает никаких данных, если вы не набираете очень быстро (например, клавиши ma sh) и даже тогда, это может быть 50% ввода, вершины.
• подход № 3: используйте PeekMessage () и PM_NOREMOVE - это, кажется, получает ввод очень последовательно, но максимизирует поток.

program readrawbuffer;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  WinAPI.Windows,
  WinAPI.Messages,
  System.Classes,
  System.SysUtils,
  URawInput in '..\URawInput.pas';       // from: https://github.com/lhengen/RawInput

type
  TGetInput = class
  strict private
    fRawInputStructureSize: UINT;
    fRawInputHeaderSize: UINT;
    fRawInputBufferSize: Cardinal;
    fRawInputDevice: RAWINPUTDEVICE;
    fRawInputBuffer: PRAWINPUT;
    procedure RawInputWndProc(var aMsg: TMessage);
  public
    fRawInputWindowHnd: HWND;
    function ReadInputBuffer(): String;
    constructor Create();
    destructor Destroy(); override;
  end;

  constructor TGetInput.Create();
  begin
    inherited;
    fRawInputStructureSize := SizeOf(RAWINPUT);
    fRawInputHeaderSize := SizeOf(RAWINPUTHEADER);
    // create buffer
    fRawInputBufferSize := 40 * 16;
    GetMem(fRawInputBuffer, fRawInputBufferSize);
    // create handle and register for raw (keyboard) input
    fRawInputWindowHnd := AllocateHWnd(RawInputWndProc);
    fRawInputDevice.usUsagePage := $1;
    fRawInputDevice.usUsage := $6;
    fRawInputDevice.dwFlags := RIDEV_INPUTSINK;
    fRawInputDevice.hwndTarget := fRawInputWindowHnd;
    if RegisterRawInputDevices(@fRawInputDevice, 1, SizeOf(RAWINPUTDEVICE)) then
      WriteLn('device(s) registered; start typing...')
    else
      WriteLn('error registering device(s): ' + GetLastError().ToString());
  end;

  destructor TGetInput.Destroy();
  begin
    if Assigned(fRawInputBuffer) then
      FreeMem(fRawInputBuffer);

    DeallocateHWnd(fRawInputWindowHnd);
    inherited;
  end;

  function TGetInput.ReadInputBuffer(): String;
  var
    pcbSize, pcbSizeT: UINT;
    numberOfStructs: UINT;
    pRI: PRAWINPUT;

  begin
    Result := String.Empty;
    pcbSize := 0;
    pcbSizeT := 0;

    numberOfStructs := GetRawInputBuffer(nil, pcbSize, fRawInputHeaderSize);
    if (numberOfStructs = 0) then
    begin
      // docs.microsoft.com says for 'nil'-call: "minimum required buffer, in bytes, is returned in *pcbSize"
      // though probably redundant, I guess it can't hurt to check:
      if (fRawInputBufferSize < pcbSize) then
      begin
        fRawInputBufferSize := pcbSize * 16;
        ReallocMem(fRawInputBuffer, fRawInputBufferSize);
      end;

      repeat
        pcbSizeT := fRawInputBufferSize;
        numberOfStructs := GetRawInputBuffer(fRawInputBuffer, pcbSizeT, fRawInputHeaderSize);
        if ((numberOfStructs > 0) and (numberOfStructs < 900000)) then
        begin
          {$POINTERMATH ON}
          pRI := fRawInputBuffer;

          for var i := 0 to (numberOfStructs - 1) do
          begin
            if (pRI.keyboard.Flags = RI_KEY_MAKE) then
              Result := Result + pRI.keyboard.VKey.ToHexString() + #32;

            pRI := NEXTRAWINPUTBLOCK(pRI);
          end;
          {$POINTERMATH OFF}
          // DefRawInputProc();   // doesn't do anything? http://blog.airesoft.co.uk/2014/04/defrawinputproc-rastinating-away/
        end
        else
          Break;
      until False;

    end
  end;

  procedure TGetInput.RawInputWndProc(var aMsg: TMessage);
  begin
    // comment-out case block for Sleep() approach; leave last DefWindowProc() line
    // leave case block for GetMessage() / PeekMessage() -approaches; comment-out last DefWindowProc() line
//    case aMsg.Msg of
//      WM_INPUT:
//        begin
//          Write(ReadInputBuffer(), '-');
//          aMsg.Result := 0;
//        end
//    else
//      aMsg.Result := DefWindowProc(fRawInputWindowHnd, aMsg.Msg, aMsg.WParam, aMsg.LParam);
//    end;

    // comment-out for GetMessage() / PeekMessage() -approaches
    aMsg.Result := DefWindowProc(fRawInputWindowHnd, aMsg.Msg, aMsg.WParam, aMsg.LParam);
  end;


var
  getInput: TGetInput;
  lpMsg: tagMSG;

begin
  getInput := TGetInput.Create();


////////////////////////////////////////////////////////////////////////////////
// approach #1: Sleep()
// >> comment-out other aproaches; comment-out case block in RawInputWndProc(), leave last DefWindowProc() line

  repeat
    WriteLn('sleeping, type now...');
    Sleep(3000);
    WriteLn('VKeys read: ', getInput.ReadInputBuffer());
  until False;


////////////////////////////////////////////////////////////////////////////////
// approach #2: GetMessage()
// >> comment-out other approaches; comment-out last DefWindowProc() line in RawInputWndProc(), leave case block

//  repeat
//    // docs.microsoft.com: "Use WM_INPUT here and in wMsgFilterMax to specify only the WM_INPUT messages."
//    if GetMessage(lpMsg, getInput.fRawInputWindowHnd, WM_INPUT, WM_INPUT) then
//      DispatchMessage(lpMsg);
//  until False;


////////////////////////////////////////////////////////////////////////////////
// approach #3: PeekMessage()
// >> comment-out other approaches; comment-out last DefWindowProc() line in RawInputWndProc(), leave case block

//  repeat
//    if PeekMessage(lpMsg, getInput.fRawInputWindowHnd, WM_INPUT, WM_INPUT, PM_NOREMOVE) then
//      DispatchMessage(lpMsg);
//
//    if PeekMessage(lpMsg, 0, 0, 0, PM_REMOVE) then
//      DispatchMessage(lpMsg);
//  until False;

  getInput.Free();
end.

Answer 1

Я пересмотрел этот «ответ» на основе обмена в комментариях ниже и участия тестирования. Он не обязательно отвечает на мой вопрос, но отражает мой текущий уровень понимания и описывает подход, который я в итоге использовал (и который, кажется, работает до сих пор)

• Кажется, что через RawInput Сообщения окна WM_INPUT в любом случае; используется ли GetRawInputData() или GetRawInputBuffer()
• Это означает, что требуется какое-то окно, в которое можно отправлять сообщения. Это может быть скрытое окно. Использование CreateWindowEx(0, PChar('Message'), nil, 0, 0, 0, 0, 0, HWND_MESSAGE, 0, 0, nil); пока работает для меня очень хорошо
• Это также означает, что должно быть какое-то сообщение l oop, чтобы сообщения могли обрабатываться (и не накапливаться).
• Разница с GetRawInputData() заключается в том, что Windows будет "ставить в очередь" сообщения WM_INPUT, а GetRawInputBuffer() получает и удаляет (из очереди) несколько сообщений одновременно . И я думаю, что единственным преимуществом является то, что входные данные могут быть «получены» быстрее (с более высокой пропускной способностью), чем необходимость «обрабатывать каждое сообщение WM_INPUT индивидуально».
• Хитрость в том, что это похоже на * Чтобы работать 1021 *, крайне важно, чтобы сообщения , за исключением WM_INPUT, обрабатывались обычным способом - и затем регулярно вызывался GetRawInputBuffer(), который имеет дело с сообщениями WM_INPUT, находящимися в очереди. Любой выбранный мной подход, который каким-то образом «смотрел» на сообщения WM_INPUT, в конечном итоге приводил к получению противоречивых / неполных результатов от GetRawInputBuffer()

Ниже мое сообщение l oop, которое в значительной степени вдохновлено этот SO-ответ и выполняется в отдельном потоке

repeat
  TThread.Sleep(10);

  while True do
  begin
    if (Not PeekMessage(lpMsg, 0, 0, WM_INPUT - 1, PM_NOYIELD or PM_REMOVE)) then System.Break;
    DefWindowProc(lpMsg.hwnd, lpMsg.message, lpMsg.wParam, lpMsg.lParam);
  end;

  while True do
  begin
    if (Not PeekMessage(lpMsg, 0, WM_INPUT + 1, High(Cardinal), PM_NOYIELD or PM_REMOVE)) then System.Break;
    DefWindowProc(lpMsg.hwnd, lpMsg.message, lpMsg.wParam, lpMsg.lParam);
  end;

  ReadRawInputBuffer();     // shown below; essentially reads out all queued-up input
until SomeCondition;

Чтение буфера (в значительной степени вдохновлено примером кода на docs.microsoft.com):

procedure ReadInputBuffer();
var
  // ...

begin
  // this returns the minimum required buffer size in ```pcbSize```
  numberOfStructs := GetRawInputBuffer(nil, pcbSize, rawInputHeaderSize);
  if (numberOfStructs = 0) then
  begin
    // read out all queued-up data
    repeat
      // ... allocate pBuffer as needed
      numberOfStructs := GetRawInputBuffer(pBuffer, pcbSize, rawInputHeaderSize);
      if ((numberOfStructs > 0) and (numberOfStructs < 900000)) then
        // do something with pBuffer / its data
        // I use a TThreadedQueue<T>; the items/data is worked off outside this thread
      else
        System.Break;
    until False;
  end
end;

(В тестах продолжительностью более 10 минут чтение в> 700'000 ключевых событий, похоже, не потеряло меня ни одного (если мои цифры не l ie). Использование TStopWatch и запуск / остановка на начало сообщения l oop (после TThread.Sleep(10)) и остановка в конце после исчерпания входной очереди, в одном тестовом чтении около 12 000 событий за 15 секунд (это близко к 800 событиям в секунду), самый медленный запуск измеряется ... 0 мс.)