2

何年も作業が行われておらず、最後に 32 ビットの Red Hat 4 で正常にビルドされた古い Xt/Motif アプリケーションのソース ビルドを復活させています。ほとんどの場合、64 ビットの Red Hat 5 でビルドして実行しています。アプリケーションの重大な問題が 1 つだけあります。想定されているほとんどのキーボード入力に応答しません。メニュー アクセラレータはどれも機能せず、特定の機能をサポートするはずのその他の変更されたキーと変更されていないキーの多くも機能しません。アプリが認識する唯一のキーストロークは、テキスト入力フィールドへの入力と、データの行/列を含むウィジェット間の矢印キー ナビゲーションです。

これは単純に悪いアプリケーション コードが原因かもしれないと思っていましたが、奇妙なことが起こりました....すべてのキーが機能し始めました! これを引き起こすために何をしたのかわかりません。デバッガーで実行してコードを調べていたところ、アプリがキーボード入力に応答し始めました。この時点で、デバッガーなしで実行してみましたが、キーはまだ機能していました。次に、問題が発生した古いビルドを実行してみましたが、そのビルドも同様に機能しました。

これらの同じ実行可能ファイルを別の Centos 5 マシンにコピーしましたが、それでもキーが機能しませんでした。2 つの環境をかなりの時間調べましたが、2 つの環境の違いはわかりませんでした。次に、自分のマシン (アプリが魔法のように機能したマシン) を再起動しましたが、そのマシンでもキーが機能しなくなりました。キープレスが再び認識されるようにすることは考えられません。

したがって、明らかに、この問題は少なくともいくらか環境に関係しています。ここで何が起こっているのか、誰でも手がかりを提供できますか? アプリケーションが一時的に正しく動作するようになるために、私の環境で何が変更されましたか? ここで何が起こっているのかを知っている Xt/Motif の第一人者がそこにいることを願っています。

4

2 に答える 2

2

それは「numlock」かもしれません。本当。最近の多くの X11 セットアップではモディファイアとして扱われます。これがオンの場合、アプリはキー + モディファイアを取得し、別の方法で処理する可能性が非常に高くなります。

于 2011-02-06T09:28:40.660 に答える
1

キーバインディングとxmodmapを調べます。

(そういうことをやらなくてはならなかったので久しぶりです。)

あなたが説明するように、なぜそれが「スナップイン」するのかについては考えられません。しかし、おそらくあなたの古いアプリは、メモリ内で何らかのオーバーライドを行っている/行っていた、またはそのようなものです。

アプリを閉じた後もそれが続く可能性があるようです。また、他の条件が原因で実行時に発生しない何かがデバッガーでトリガーされた可能性があります。

幸運を

于 2011-01-27T19:33:41.983 に答える