Windows タッチ処理の対応

[schedul-xor]

現行の実装は、ポインティングデバイスとしてマウスのみを想定していると思われます。 しかしWindows10タブレットは、ものによっては2点以上同時にタッチできるものがあります。 UniWinApiで開発した「伺か」モドキはマウスであれば正常に動作しますが、同一の動作をタッチ処理に替えると一部が正常に動作しません。

具体的な再現手順は次のとおりです。

1. Google Chromeなどのマルチタッチ対応プロセスウィンドウをデスクトップに展開 (最大化されていなくても良い)
2. その上にUniWinApi製「伺か」モドキを起動
3. UniWinApi製「伺か」モドキから離れた場所でGoogle Chromeをタッチ→伺かモドキからウィンドウのフォーカスが外れる、しかし「伺か」自体は最前面に表示されっぱなし
4. 最前面に表示されっぱなしの伺かをタップしても反応がない。イベントがすり抜け、下のGoogle Chromeがイベントをキャッチしてしまう。

[kirurobo]

すみません。 現在の仕組みですと、マウスカーソル直下を見て操作対象となるかを切り替えています。 そのため、カーソル移動が伴わないタッチ操作には対応できていません。

解決策としては結構仕組みを変えないといけませんので、そのうち対応できると良いとは考えますが、そうすぐに直る予定ではありません。

当方にはタッチ対応のWindows機がないため確認できてはいませんが、例えばアセットストアの Desktop Mascot Maker ならばその点は良さそうに思います。 https://assetstore.unity.com/packages/templates/systems/desktop-mascot-maker-23732

[schedul-xor]

ご回答ありがとうございます。当方にタッチ対応のWindows機がありますので、動作確認後にPull requestをお出しするかもしれません。

改造メモ:

1. 現行ではマウス位置のみを使用して直下のピクセルの透過判定を行っているところを、1番目のタッチも「マウス位置」扱いすることで検出対象に加える https://github.com/kirurobo/UniWinApiAsset/blob/e9970e93c4c02f71b4c890c19f24a2d962ebe901/Scripts/WindowController.cs#L360
2. フォーカスwindow判定も、マウス位置だけでなく1番目のタッチも使用する https://github.com/kirurobo/UniWinApiAsset/blob/e9970e93c4c02f71b4c890c19f24a2d962ebe901/Scripts/WindowController.cs#L229

[kirurobo]

ありがとうございます！ お手数をおかけします。 こちらでもAndroidかiPadなどでタッチの検証ができないものか、試してみたいと思います。

[kirurobo]

なかなか対応できておらずすみません。 次のようなことで、結局あまり整理がついていない状況です。

• こちらで iPad の Duet Display アプリを使ってみた際、なぜか最初のタッチが常にどこかで反応していて、うまく動作しない。
• 別のPCでは動作しましたが、タッチをした後で操作可能かが変化するためマウスと違う操作感になってしまうため、修正を試みている。

今後の方針として下記3通りなどを考えています。

1. 現在のDWMを利用する透過の他に layered window を利用する透過方法も用意し、タッチの場合はそちらを使う。
2. タッチの場合は、一度タッチすると"タッチ操作モード"となり移動、回転、拡大縮小もタッチで行える状態にする。しばらく操作しないとモードが解除される。
3. （タスクバーを押すなどで）アクティブにされていれば操作を受け付け、非アクティブならば操作を受け付けない。

1にあたる機能は develop では入れてみましたが、それだと美しくないために DWM にしていたため、2の方法で行こうかと考えています。

[kirurobo]

タッチ特化として、透明化方法に ColorKey を選択できるようにしました。 半透明の描画が不可能になりますが、Windowsの単色抜きを使うことでタッチに対しては自然になります。