ViVi210xx - ViVi SPR System

ViVi SPR System build 0025 project:	Mail: Pass:
[ 新規アカウント作成 \| パスワード忘れ ]

[ 新規SPR | SPR一覧

[ ▲ ページ表示 | ▼ ページ表示 ] 700件のコメントがあります。

SPR#	Date Time	by	コメント
0396	10/02/26 15:10	さかい	はい、わかりました。
0396	10/02/26 14:58	つだ	本件は半角スペースを1個だけ変換した場合の話ですよね？「半角スペース → 全角スペース変換」はカラム数を変えない変換ですので、半角1個 → 全角1個とは変換されません。そのような変換を行いたい場合は、置換を利用してください。
0395	10/02/19 12:37	そと	はい。できるかぎり協力しますよ。文書比較は毎日20回くらいは使っていますので、そればかりを付きっ切りで確認するのは難しいですが、お役に立てると思います。
0395	10/02/19 09:54	つだ	動作が混乱しててすみません。後で、文書比較相手デフォルトについて、いろんな場合を洗い出して仕様を明確にしたいと思います。できましたら、抜けている場合がないかなどのチェックをお願いしたいのですが可能でしょうか？＃念のために言っておきますが、意見は伺いますが、仕様の決定はわたしの好みで決めます。
0386	10/02/18 11:18	j	2.10.073 で修正されていることを確認しました。 vim も使っている私としては、これでより使いやすくなりました。対応ありがとうございました。
0386	10/02/17 10:04	つだ	大変ながらくお待たせしました。本件は 2.10.073 で対処できたと思いますので、ご確認のほどよろしくお願いします〜
0393	10/02/12 14:16	つだ	対処すると仕様が変わってしまうので、本件は 2.10 では却下とします。 3.x でわたしの気が変わったら仕様を変更するかもしれません。
0393	10/02/12 13:21	そと	やっぱりちょっと気になりましたので追記します。「比較対象が開かれていない場合に開いて比較する」という仕様については私の認識も一致しています。とても便利に使わせていただいています。本事象で私がおかしいな？？？と感じたのは、先入観を列挙しましたように、デフォルトで入力される比較相手は、開かれている文書が優先されるだろう。という推測の元に操作したからです。デフォルトで入力される対象について、ご検討お願いします。その上で、やはり却下としても異議は申しません。
0393	10/02/12 13:04	そと	よく分かりました。では本件クローズします。
0393	10/02/12 12:34	つだ	もう少し補足しますと、添付画像の状態で diff を実行すると 2.txt がオープンされて、3.txt と 2.txt が比較されますよね？つまり、指定された比較先文書がオープンされていないと、オープンして比較をする、という仕様なんですよ。もう少し検討しますが、本件を対処するにはオプションを導入するしかないかもしれませんが、2.10 ではもうオプションの追加は行いませんし、3.x 以降でもオプションの追加は可能な限り行わない方針です。なので、たぶん本件は仕様で却下にすると思います。ちなみに、ViVi の仕様は、どちらが多数派かは関係なく、理由を聞いた上で、わたしの独断と偏見と好みで決定します。
0393	10/02/12 11:23	そと	なるほど、そういう仕様だったのですね。私の先入観でしかありませんが、こう思っていました。・３つ以上文書が開かれた状態で文書比較　=>　今アクティブな文書と、直前にアクティブだった文書を比較　　　（ただし、閉じたファイルは直前のアクティブには入れない）・２つの文書を開いた状態で文書比較　=>　開いている２つの文書を比較・１つだけ文書を開いた状態で文書比較　=>　開いている文書と、指定した文書を比較　　　（文書比較ダイアログで比較相手エディットボックスが空っぽの状態）私は現象が起きてしまう操作では、比較したい２つの文書以外を閉じて「:diff」=>「Enter」「Enter」と、お決まりの操作パターンなので高速にキータイプします。このとき、先に書いた先入観があるため、 ViVi内に残っている２つの文書が比較されるものと信じ込んで、「Enter」は文書比較ダイアログの内容を確認することなく連続で押します。結果的に閉じたファイルがまた開かれてしまい、発生するときとしないときの違いが分からずにいました。個人的には、直前のアクティブに閉じたファイルが含まれていないほうが使い勝手よいです。私の先入観と現行の仕様、どちらが多数派か分かりませんので、対応は津田さんのご判断にお任せします。振る舞いを変更していただける場合は、動作確認テストはおこないます。
0394	10/02/12 10:52	そと	よろしくお願いしまーす。
0394	10/02/12 10:43	つだ	非常にわかりやすく、的を射た問題レポートありがとうございます。本件はファイルをドロップした時、無条件に直前ファイルを更新しているのが原因だと思います。早急に調査・対処します。
0393	10/02/12 10:41	つだ	最小再現条件の探求ありがとうございます。が、文書比較相手のデフォルトは Ctrl + ^ で表示される直前ファイルで、本件の状態では閉じたばかりの 2.txt が直前ファイルなんですよ。なので、本件は意図した動作なんです。が、使い勝手が悪いのであれば修正を検討します。
0394	10/02/12 10:30	そと	fileName = '/SPR/pict/14-113.jpg' ファイル３つで同じことをした場合のイメージも添付します。
0392	10/02/10 08:34	つだ	^^;;; やぱりそうでしたか。しっかし、ctags を利用しないと tags ジャンプや型を認識した動的補完などが動作しないのですっごく不便なのではないでしょうか？以下からDLできますので、セットアップして使用されることを＊強く＊お奨めします。 http://hp.vector.co.jp/authors/VA025040/ctags/
0392	10/02/09 15:49	和田＠神奈川	な、なるほど・・・仰る通りでした。プロジェクトのプロパティにもtagsの設定があったんですね。おかげでダイアログが出なくなりましたので、本件は取下げますね。お騒がせしました。
0392	10/02/09 14:56	つだ	>>2 では、プロジェクトプロパティで「tags ファイル自動更新」オプションがONになっているだけではないでしょうか？
0392	10/02/09 14:26	和田＠神奈川	いえ、ctags.exeは持っていないみたいです^^; 試しに、GlobalSettings->その他->tagsファイル生成プログラムを空にしてみましたが、「tagsファイル生成プログラムが指定されていません」といわれてしまいましたorz
0392	10/02/09 14:06	つだ	確認ですが、ctags.exe はパスの通ったところにあるんですよね？
0388	10/02/02 13:10	waken	確かに非折り返しモード時には問題が発生しますね。本件はクローズしておきますので、別SPR側の対応よろしくお願い致します。
0388	10/02/02 12:33	つだ	再現条件が分かりました。非折り返しモードの時に問題が発生するようです。 ↑これは別SPRとしますので、本件はクローズにしてください。よろしくお願いします。
0388	10/02/02 12:31	つだ	fileName = '/SPR/pict/14-107.png' >>2 早速のご確認、ありがとうございます。わたしのところでは添付画像のように再現しなくなりました。何か再現条件があるのか、または設定に依存しているのだと思います。 ↓の添付画像のように単純な場合でも再現しますでしょうか？もし再現するようであれば、設定ファイルをメールで送ってください。よろしくお願いします。
0388	10/02/02 10:36	waken	早速の対応ありがとうございます。 2.10.068にバージョンアップして、同じファイルで確認したのですが、残念ながら不具合解消されていない模様です。申し訳ありませんが再度確認していただけませんでしょうか？ ※vivi.exe自体は更新されているようですが。。。
0388	10/02/02 08:11	つだ	fileName = '/SPR/pict/14-106.png' 具体的でわかりやすい問題レポートありがとうございました。本件は添付画像の様に 2.10.068 で対処できたと思いますので、ご確認のほどよろしくお願いします〜
0385	10/01/07 16:20	つだ	>>1 いえいえ。ちなみに、[編集] をクリックすれば、ステータスが New の間は中身を編集できますよ。
0385	10/01/07 13:02	j	すみません、入力中にEnterキーを押してしまい、誤って登録されてしまいました。 Closeにさせていただきます。すみませんでした。
0382	09/12/25 17:04	つだ	早速のご確認ありがとうございました〜んでは、今後もよろしくお願いします〜実は頻繁にアクセスしていたのは、メニューのアップデート処理でした。 3.x の方は頻繁にアクセスしないのはMFCが賢くなったからだと思われます。
0382	09/12/25 16:43	waken	仕事の方が立て込んできて確認遅れました。 2.10.066で頻繁にレジストにアクセスすることはなくなり、10分間隔でアクセスすることを確認しました。
0382	09/12/25 13:43	つだ	おかげさまで、頻繁にアクセスする問題そのものは、2.10.066 で対処できたと思います。（１回のセッション？で同じキーを何度もアクセスする件については別件とします）今ビルド中なので、１０分後にはDLできると思います。 >>6 かっちょいいツールの情報ありがとうございます。あとでチェックしてみます。んでは、今後もよろしくお願いします〜
0382	09/12/25 13:33	waken	対応の程、よろしくお願い致します。m(__)m ちなみに画像の影付きの赤・青枠は、「FastStone Capture(http://www.faststone.org/)」というキャプチャーソフトで、キャプチャ後に内蔵のFastStone Editorというエディタに出力することができて(キャプチャ後の動作は設定可能です)、画像上に色々書き込めたりします。以前はフリーソフトだったんですが、現在の最新バージョン6.5は有償になってるようですね。以下のサイトからフリー版の5.3がダウンロードできるようです。お試しあれ〜！ http://www.topfreeware.net/favprograms/screencapture/screencapture.htm
0382	09/12/25 13:12	つだ	あああ、すみません。認証関係は何も変更していないと思い込んでて、3.03 の方で追試してしまいました。今 2.10 でやってみたらすごい頻度でアクセスしていました。orz これから調査します〜
0382	09/12/25 12:39	つだ	>>3 お返事さんくすです。バッファオーバフローは頻度とは関係ない話です。 ↓に問題登録しておきました。 http://vivi.dyndns.org/SPR/75@ViVi304 んで、ViVi にも問題があって対処したのですが、やっぱりオーバフローエラーが表示されます。どうも Process Monitor にもバグがあるみたいです。ところで、画像の赤・青枠の影がかっちょいいですね。何で描いたのですか？
0382	09/12/25 10:24	waken	fileName = '/SPR/pict/14-102.png' 返信遅れて済みません。当方でもProcess Monitorで確認しましたが、やはり「引っ切り無し」のアクセスになってますね。画像添付しますが、"BUFFER OVERFLOW"って、今回の現象に起因するんでしょうか？？？
0382	09/12/25 09:48	つだ	わたしの方で、Process Monitor を使って、現象を確認しました。わたしの環境では 09:28:10 → 09:38:10 → 09:48:10 とちょうど10分おきにレジストリにアクセスしています。わたしは、これが頻度が高いとは考えないです。ただ、1回というか一連のレジストリチェックで、同じキーを複数回参照していたり、ちょっと怖い表示があるので調査してみます。
0382	09/12/25 09:26	つだ	RegMon(Registry Monitor) を試してみようと思いましたが、既にダウンロードできない状態のようです。 http://technet.microsoft.com/ja-jp/sysinternals/bb896652(en-us).aspx かわりに Process Monitor をダウンロードして試しています。 waken さんの環境では Process Monitor でも同様の現象が発生するのでしょうか？できれば、試してください。よろしくお願いします。
0381	09/12/17 14:07	sham	>>4 3.03に反映されているんですか。了解いたしました。ありがとうございます。
0381	09/12/17 14:03	つだ	>>3 納得ありがとうございます。 3.x への反映ですが、不都合が無い限り最新版には自動的に反映します。（現状は 3.03 にのみ反映しています）できるかぎりわたしの作業量を増やしたくないので、3.02 への反映はSPR登録があった場合のみとします。
0381	09/12/17 13:33	sham	>>2 >仕様は、「罫線の直前までを削除する場合は、罫線保護は効かない。ただし dw、dW だけは例外とする」そういうことだったんですね。納得しました。その動作であれば、統一取れてますし、問題ありませんのでCloseとさせていただきます。ありがとうございました。ちなみに、ViVi3.XX系への反映は、このSPRでしていただけるのでしょうか？それともViVi3.XX系のSPRに、別に上げないとダメでしょうか？
0381	09/12/17 13:16	つだ	>>1 早速のご確認、ありがとうございます。罫線モードの場合でも dw で空白が削除されるのは意図した変更です。（こっそり修正してしまい、すみません）仕様は、「罫線の直前までを削除する場合は、罫線保護は効かない。ただし dw、dW だけは例外とする」ということにします。 dlやx、[del]キーの動作もこの仕様に沿っていると思います。そうでなければ問題として対処します。
0381	09/12/16 15:18	sham	2.10.065への対処ありがとうございます。しかしながら、今度は罫線保護モードでdwしても、空白が削除されるようになってしまいました。これは意図的にそのように変更されたのでしょうか？確かに罫線保護モードで空白部分をわざわざdwするという操作は、意識的に空白を削除したいという操作であるとも言えるので、このほうが使い勝手が良いのかもしれませんが、そうすると、dlやx、[del]キーの動き(罫線保護モードでは空白削除しない)と矛盾してしまうので、統一感がなくなってしまうのが気になります。
0380	09/12/04 12:06	オニオン	仕様ということで了解しました。 \<START.*END\>を使うようにします。
0379	09/12/04 10:24	つだ	おかげさまで本件は 2.10.064 で対処できたと思います。すでにリリース済みですので、ご確認のほど、よろしくお願いします〜
0379	09/12/04 10:13	つだ	うーむ、どうも本件は SPR#0371 の副作用みたいです。^^;;;
0379	09/12/04 09:45	つだ	>>2 おーっ、再現できました。再現できればこっちのものなので、これらから調査・対処します。簡単で具体的な再現手順、どうもありがとうございました〜
0379	09/12/04 09:37	そと	メールを送れる環境にないので、レジストリを削除して再現させてみました。再現手順を更新しましたのでご確認ください。
0379	09/12/04 08:45	つだ	fileName = '/SPR/pict/14-100.png' 添付画像のように、私のところでは再現しませんでした。なんとなく MDITabs の設定に依存しているような気がするので、現在の（グローバル＆TXTタイプの）設定をメール送っていただけないでしょうか？よろしくお願いします。
0380	09/12/04 08:32	つだ	.* は最長一致なので、「START.END」は「START001END dummy START002END」全体とマッチします。 n を実行した場合最初の Sの次のTから検索し、「START002END」とマッチします。これは意図した動作です。本件の場合なら START\d+END とか START[^ ]END とか \<START.*END\> などで検索するようにしてください。
0375	09/12/01 13:29	つだ	了解しました。本件はクローズにしておきます。なにかありましたら、別SPRでお願いしますー
0375	09/12/01 13:21	hasi	すみません。今日は、問題なく使えています。。。つださんのおっしゃる通り、私の端末の問題だと思いますので、しばらく様子をみてみます。また再現しましたら、薦めてくださったキャプチャーツールを試したいとおもいます。お騒がせしました。

[ ▲ ページ表示 | ▼ ページ表示 ] 700件のコメントがあります。

[ 新規SPR | SPR一覧