[スレッド全体]

2014/4/16 (水) 23:33:38 Viu89r9VV  
Mozilla/5.0 (Windows NT 6.1; rv:28.0) Gecko/20100101 Firefox/28.0
[2152] 不具合:「開きません」のキャンセルが存在しません
環境(Environment): Windows 7, サクラエディタ 2.1.1.1

前回ファイルを「UTF-8」で開き、今回「SJIS」で開こうとした場合、以下の警告メッセージが表示されます。

----------------------------------------
文字コード情報
パス\ファイル名.txt

このファイルを文字コード SJIS で開こうとしていますが、前回は別の文字コード UTF-8 で開かれています。前回と同じ文字コードを使いますか?

・[はい(Y)] =UTF-8
・[いいえ(N)]=SJIS
・[キャンセル]=開きません


[はい] [いいえ]
----------------------------------------

しかし、「キャンセル」のボタンが存在しないため、キャンセルできません。画面右上に [×] マークは存在しますが、グレー アウトしていて押せません。これは不具合ということで よろしいのでしょうか。報告しておきます。

2014/4/19 (土) 23:27:52 novice  
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
[2153] Re:不具合:「開きません」のキャンセルが存在しません
▼ Viu89r9VVさん
> しかし、「キャンセル」のボタンが存在しないため、キャンセルできません。画面右上に [×] マークは存在しますが、グレー アウトしていて押せません。これは不具合ということで よろしいのでしょうか。報告しておきます。

patchを登録しました。
http://sourceforge.net/p/sakura-editor/patchunicode/800/

2014/4/20 (日) 17:05:00 神楽  
Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0
[2154] Re2:不具合:「開きません」のキャンセルが存在しません
▼ noviceさん
> ▼ Viu89r9VVさん
> > しかし、「キャンセル」のボタンが存在しないため、キャンセルできません。画面右上に [×] マークは存在しますが、グレー アウトしていて押せません。これは不具合ということで よろしいのでしょうか。報告しておきます。
>
> patchを登録しました。
> http://sourceforge.net/p/sakura-editor/patchunicode/800/

ANSI版(1.6.6.0)にはキャンセルの説明があり、キャンセルボタンもあります。
ANSI版の仕様に合わせた方が良いのではないでしょうか?

2014/4/20 (日) 17:50:43 novice  
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
[2155] Re3:不具合:「開きません」のキャンセルが存在しません
▼ 神楽さん
Unicode版は、r1587でキャンセルが削除されたようです。
http://sourceforge.net/p/sakura-editor/code/1587/

PatchUnicodeは未登録で、掲示板にログが残ってましたが、キャンセルの削除については特に記載が見つかりませんでした。
http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?log=unicode&v=950

2014/5/8 (木) 06:21:50 神楽  
Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
[2165] Re4:不具合:「開きません」のキャンセルが存在しません
▼ noviceさん
2.1.1.1も同じ挙動だったのですが、2.1.1.2で文字コード情報の
メッセージダイアログがアクティブの時に、
Ctrl+Cでダイアログタイトルバー通りの「文字コード情報」とコピーされず、
「(保存されていません)」と「(印刷プレビューでのみ使用できます)」が
Ctrl+Cする度に、交互に繰り返されます。
1.6.6.0ではタイトルバー通りにコピーされますので、できれば対策をお願い致します。

2014/5/16 (金) 00:29:53 もか  
INCM1.23a
[2183] Re5:不具合:「開きません」のキャンセルが存在しません
MessageBoxやDialogBox*(ついでにSHBrowseForFolder、GetOpenFileName等)は内部でGetMessage等を呼び出してメッセージ処理をするから、
BlockingHookと同じように他のウィンドウのメッセージが処理されることを意識する必要があるってことですね
(サクラのコードはBlockingHookもほとんど他の処理が走ることを考慮していませんけど)

VMessageBoxFを表示中にさらにVMessageBoxFが表示されることがあるようです。
何かのダイアログが表示された状態で、親ウィンドウにWM_CLOSEが送られてきたとか。
ためしに、編集中ドキュメントを[X]で閉じようとして「保存しますか?」ときかれてきて、
その状態でタスクバー(Win7)から「このウィンドウを閉じる」を選んだら、
もう一つ「保存しますか?」が表示されました。
1つめが他のダイアログだった場合は、VMessageBoxFのszBufはstaticなので、
2つめをキャンセルして1つめに戻ってきた場合に、よろしくないんじゃないでしょうか。
LR4さんの代替案ならWarpでコピーされて問題なさそうです。

考慮したほうがいいことで思いつくことは
1.バッファのリサイクル(LS/LSW/to_*char)
2.staticになってる変数等の再入問題
3.API呼び出し前にチェックしたファイル・ウィンドウ・共有変数等の内容が変更になっている可能性
4.プロセス(親ウィンドウ)の終了
とかいろいろありますが現状は結構手抜きのはず。

2014/5/16 (金) 09:50:12 LR4  
Mozilla/5.0 (Windows NT 6.1; rv:29.0) Gecko/20100101 Firefox/29.0
[2186] Re6:不具合:「開きません」のキャンセルが存在しません
残念なことですが、複数のメッセージボックスを表示している場合ですが、*各メッセージボックスの文字列バッファが独立したものになっていても*、どのメッセージボックスに対するCtrl+Cも、常に最後に出したメッセージボックスのテキストがクリップボードに入ります。
最後のメッセージボックスを閉じるとひとつ前のメッセージボックスのテキストになります。
(MessageBox APIの側で常に末尾スタックに積まれたバッファポインタを参照しているのかな?という挙動です)

サクラとは別に、Visual Studioが生成する最も単純なWin32 Appに少し手を加えただけのプログラムで検証しても同様でした。

サクラでは検索ボックスと置換ボックスを同時に出して、
検索ボックス:検索条件を指定してください
置換ボックス:前方(↓) に文字列 'x' が1つも見つかりません
のメッセージを同時に出すことができます。
上記に加えて、「閉じる前に保存しますか?」も簡単に出せますね。

メッセージフックでもして自コード内にクリップボード処理を回せば矯正できるとは思いますが、さすがにそれはアレなので、複数表示についてはあきらめて期待通りには動かないのが「仕様」ということにしておくほうが賢明と思います。
1個だけ表示しているときは期待通り動く、というところまでの対策で妥協しましょう(汗)

2014/5/16 (金) 10:30:39 LR4  
Mozilla/5.0 (Windows NT 6.1; rv:29.0) Gecko/20100101 Firefox/29.0
[2187] Re7:不具合:「開きません」のキャンセルが存在しません
> 最後のメッセージボックスを閉じるとひとつ前のメッセージボックスのテキストになります。

すみません、必ずしもこのルール通りではないようです。時折、違う挙動が起きるような?…
ちなみに、メモ帳でも検索ダイアログの「"x"が見つかりません」と「無題 への変更内容を保存しますか?」を同時に出したりできますが、やはり変な挙動になります。

[▼次のスレッド]
INCM/CMT
Cyclamen v3.81
[ut:0.020][st:0.000]