SIGBREAKをメニューイベントとして認識している

[yamahubuki]

Ctrl+CのSIGINTは大丈夫ですが、BREAKキー(≒Ctrl+Pause)のSIGBREAKがくると、メニューイベントとしてID=2が飛んできている。
これだとid=2のメニューなのかSIGBREAKなのかわからなくて困る。

なお、

import signal
signal.signal(signal.SIGBREAK,app.hMainView.OnClose)

をやってもダメなようである。

[yncat]

普通はコマンドラインから起動することはなく、テスト時にのみ遭遇する問題だと考えられるので、わざわざ対応する必要はないと思います。

[yncat]

コマンドラインからというか、普通は windowed モードでの起動であって、シグナルを送ることはないので、という意味。

[yamahubuki]

既に、exe版でも再現するとの報告が入っています。

[yncat]

exe版で立ち上げて、わざわざsigbreakを送るようなシチュエーションがどういう場合にあるのかということです。たぶんwxがハンドリングしてしまってるので、それを強引な方法でなんとかしてまで対処する必要があるようには思えません。

[yncat]

あ、思いついた。id==2を終了にすればいい。

[yamahubuki]

確かに面倒です。 私が振っているのは番号が大きいものばかりなので、SIGNALに使われそうな100番以前は全部event.Skip()してしまうという解決も不 可能ではないです。 その場合、そちらで作っているContextMenuとの関係で問題になることはないですか？

[yncat]

それはcontextMenuのID開始位置と終了位置を指定できるので、ぶつからないところにさくっと入れればいけそう(もともと問題がないかもしれない)

[yamahubuki]

では、面倒なので100番以下のものは無視するように後日修正します。 constants.pyにてメニューイベントの番号を管理しているので、相手そうな場所を見つけて使ってください。そして、管理上そこに追 記してください。 現状ではPythonよりもそちらが先にメニューイベントを捕まえているようなので、今回の処理でそちらに影響はなさそうですが、番号 は重ねない方が将来のためだと思います。