SAKURA Development BBS (ANSI)

▼ 2008/5/31 (土) 23:51:25 ryoji

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SV1; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.21022)

[5315] Re3:作ってみました

> 「改行ぶら下げ」をマニュアルで確認してみましたが、文字通り改行マークを右にぶら下げると言う事のようですので1桁分の幅ですよね。

CRLFなどの改行マークは２桁幅でないと記号全体が見えないので、

句読点ぶら下げによる句読点（2桁）+ 改行ぶら下げによる改行マーク（2桁）
（このときは折り返し記号はつかない）

で最大は４桁かしら？

▼ 2008/6/2 (月) 04:26:08 なすこじ

Mozilla/4.8 (Macintosh; U; PPC)

[5316] Patchesにアップしました

Patches #1981460　テキスト折り返し方法の追加

色々修正しました。
ただし、タイプ別設定画面に「一時設定適用中」を表示するのは未実装です。
CShareDataにフラグを追加しそのON/OFFによって文字列を変更するくらいしか思い付かないのですが、セマフォみたいなことが必要でしょうかね？
もっと良い方法があったらお願いします m(_ _)m

▼ 2008/6/2 (月) 22:44:25 ryoji

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SV1; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.21022)

[5317] Re:Patchesにアップしました

▼ なすこじさん
> 色々修正しました。

設定画面で折り返し方法の変更が無ければ、自画面の一時設定は解除しないようにされたのですね。良い感じです。

> ただし、タイプ別設定画面に「一時設定適用中」を表示するのは未実装です。

これについては、設定無変更なら一時設定解除はしないで欲しいという、そのついでにふと思いついたことです。表示の無い現状でも十分かな？と思います。

その他：
「折り返さない」設定のときの動作でいくつか気になる点があります。
１．置換画面で置換実行した場合、最大幅の更新に水平スクロールバーが追随しないみたいです
２．１行が最大幅を超える場合、水平スクロールバーのつまみを最右端にすることができない
　例えば、折り返しで３行になるような場合は最右端にしようとしても半分以下までに引き戻される
３．変更のたびに全行走査、というのでは単独で動かしているときには問題にならないレベルでも、別アプリと同時動作の場合に応答が悪くならないか？あるいは別アプリのほうの性能を極端に下げたりしないか？
　例えば、プログラムのコンパイル中にサクラで文字入力した場合とか、（まだ試していないけど）ちょっと気がかりです。なんだか必要以上にＣＰＵを使ってしまう気がして。

▼ 2008/6/3 (火) 13:10:55 なすこじ

Mozilla/4.8 (Macintosh; U; PPC)

[5318] Re2:Patchesにアップしました

▼ ryojiさん

> 「折り返さない」設定のときの動作でいくつか気になる点があります。
> １．置換画面で置換実行した場合、最大幅の更新に水平スクロールバーが追随しないみたいです
> ２．１行が最大幅を超える場合、水平スクロールバーのつまみを最右端にすることができない
> 　例えば、折り返しで３行になるような場合は最右端にしようとしても半分以下までに引き戻される

ありがとうございます。確認・修正します。

> ３．変更のたびに全行走査、というのでは単独で動かしているときには問題にならないレベルでも、別アプリと同時動作の場合に応答が悪くならないか？あるいは別アプリのほうの性能を極端に下げたりしないか？
> 　例えば、プログラムのコンパイル中にサクラで文字入力した場合とか、（まだ試していないけど）ちょっと気がかりです。なんだか必要以上にＣＰＵを使ってしまう気がして。

負荷が高くなるのは間違いないので問題となるかもしれませんね。
数千行あるとカーソル行アンダーラインのちらつきも感じるようになりますし。

『負荷を上げずに「折り返しなし」を使う』オプションを追加して、オプションがチェックされている場合はメモ帳と同様に行長の拡大のみ監視するようにするというのはどうでしょう？（初期値はチェック入）
ryojiさんが>>dev:5303で上げられているように、編集した行だけをチェックすれば良いので相当負荷は軽くなると思います。

▼ 2008/6/3 (火) 22:27:08 ryoji

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.2)

[5319] Re3:Patchesにアップしました

▼ なすこじさん
> 『負荷を上げずに「折り返しなし」を使う』オプションを追加して、オプションがチェックされている場合はメモ帳と同様に行長の拡大のみ監視するようにするというのはどうでしょう？（初期値はチェック入）

僕としては、さほど大きな魅力を感じているわけでもない「折り返しなし」機能にそこまで細かい設定は要らないかな、と思いますけど．．．
特に欲しいと考えている人たちが機能・性能バランスを考慮して「こっちが妥当だ」と決めてくれるなら、そっちの意見に従いたいところです。

▼ 2008/6/4 (水) 09:46:24 ryoji

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 3.5.21022)

[5320] Re4:Patchesにアップしました

> 機能・性能バランス

機能／性能バランス、ということについて少し考えてみました。
現状のサクラでは、対括弧の強調表示は画面可視範囲内しかサーチしない、カラー表示の上塗りはしないなど、実用範囲でＯＫなら無理にハードに負担はかけないようにしているところが多々見られます。
個々の機能で見るともっと完全なものにするのが良いのでしょうが、他機能のために余力を残すという意味では妥当なことなのかな～、とも思います。
エディタ機能全体として、既存機能の強化、新機能の追加まで含めたハード的な余力って、どのくらいあるんでしょうかね？？

▼ 2008/6/4 (水) 12:57:28 なすこじ

Mozilla/4.8 (Macintosh; U; PPC)

[5321] Re5:Patchesにアップしました

▼ ryojiさん
> エディタ機能全体として、既存機能の強化、新機能の追加まで含めたハード的な余力って、どのくらいあるんでしょうかね？？

私自身は余力があり余っていると思うのですが、使用者のPCや使用方法で変わってくるので中々定量的に示すのは難しいですね。

ただ、常に全ライン走査というのはかなりパワーを必要とするので余り良い方法ではないとは思います。
現にカーソル行アンダーラインがちらつくなどの影響が出ています。
単純なコーディングで済まそうとしていたからなのですが、上記のような見た目の問題を軽減するために現在はもう少し複雑な判定を考えています。

逆に、見た目の性能劣化が少なければ少々要求パワーが上がっても良いかなという感じです。
気になる方はオプションを切って今まで通りの状態で使用してもらうということで……

複雑なコーディングをすると後々の不具合の元になるのでできるだけ単純にしたかったのですが、私のレベルではもう無理、どんどん汚くなっていく (^^;

あと>>dev:5317の、
> 「折り返さない」設定のときの動作でいくつか気になる点があります。
> １．置換画面で置換実行した場合、最大幅の更新に水平スクロールバーが追随しないみたいです

上記現象の発生条件がわかりません。
文書が編集されたときに下記の関数のどれかが呼ばれれば大丈夫なつもりなんですが、呼ばれないルートがあるのでしょうかね？
　CEditView::InsertData_CEditView()
　CEditView::DeleteData2()
　CEditView::ReplaceData_CEditView()

ではでは。

▼ 2008/6/4 (水) 19:15:13 ryoji

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 3.5.21022)

[5322] Re6:Patchesにアップしました

▼ なすこじさん
> 現在はもう少し複雑な判定を考えています。

if(変更行長＞最大長)
　最大長＝変更行長
else if(最大長だった行が短くなった)
　全行再スキャン

てな感じの細工でもかなり負荷緩和されそうですね。

> > １．置換画面で置換実行した場合、最大幅の更新に水平スクロールバーが追随しないみたいです
>
> 上記現象の発生条件がわかりません。

普通に「置換」ボタンで置換実行するだけです。
例えば、改行のみがいくつか存在するテキストに１行だけスクロールバーが表示されるような長い行を追加しておいて、その行データを空文字列に置換するとスクロールバーが追随しません。
その後、置換ダイアログを閉じてビューをクリックしたり、矢印キーでカーソル移動すると、そのときにスクロールバーが追随します。

> 　CEditView::InsertData_CEditView()
> 　CEditView::DeleteData2()
> 　CEditView::ReplaceData_CEditView()

「置換」ボタンでの置換動作は、検索でカーソル移動／選択したのち選択範囲の文字列を入れ替えるという連続動作になっています。
検索でのカーソル移動では画面がスクロールしますが、文字列入れ替えは描画OFFで行ってから全体再描画してます。
描画OFFでMoveCursor()が実行されるときはスクロールOFFになっているため現状のコードでは最大幅のスキャンが行われません。
最後の全体再描画では更新されていない昔の最大幅のままでスクロールバーが再描画されます。

MoveCursor()ではなく、MoveCursor()の中で呼び出しているAdjustScrollBars()のほうに最大幅計算の処理も入れてしまえば、最後の全体再描画（こちらでもAdjustScrollBars()を呼び出している）で正しく表示されるんじゃないでしょうか。

▼ 2008/6/4 (水) 21:17:01 なすこじ

Mozilla/4.8 (Macintosh; U; PPC)

[5324] Re7:Patchesにアップしました

▼ ryojiさん
どうもありがとうございます。現象確認できました。
相変わらずソースが読み切れてませんでした (^^;

修正の方なんですが、最大幅の算出の呼び出しを if( bScroll ){ の上に出してしまうというのではまずいですかね？

[▼次のスレッド]

INCM/CMT
Cyclamen v3.81

[ut:0.010][st:0.000]