[スレッド全体]

2008/5/31 (土) 14:52:44 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)
[5311] Re:作ってみました
分割ビューの場合なんですが、「右端で折り返す」はアクティブなビューの画面幅が変化するとそれに合わせて変化してますね。左右どちらかに固定した方が扱いやすいような気がします。左上のビュー(インデックス0番)のサイズ変更に合わせるのがソースコード記述上でも楽なんじゃないでしょうか?

2008/5/31 (土) 17:49:25 なすこじ 返信 削除
Mozilla/4.8 (Macintosh; U; PPC)
[5313] Re2:作ってみました
▼ ryojiさん

沢山のご助言ありがとうございます m(_ _)m

> 明示的に折り返しを変更しなくても、OKボタンで閉じただけで強制的に変更されてしまうのがちょっと悲しいかなぁ?
> Windows画面プロパティの[テーマ]欄で「変更されたテーマ」が表示されるように、自画面が一時設定中のときは、折り返し方法に「一時設定適用中」とでも表示しておいて、そこが変更されなければ他画面も一切変更しない、という具合にすることは可能でしょうか?


現在の状態が一時設定なのかどうかが分からないのはあまり良くないですね。
メニューの「テキストの折り返し方法変更」を、一時設定適用中は「折り返し方法(一時設定適用中)」にしてみます。
タイプ別設定の適用の動作については検討してみます。

> 「右端で折り返し」のときに1桁分だけ右余白がつくようになった?
> 「改行ぶら下げ」や「句読点ぶら下げ」を設定しているときは各々で2桁づつ、折り返し記号の1桁をあわせると、おそらく最大5桁は桁オーバーで表示されることになると思います。
> 設定に合わせて余白も自動調整されるといいのですが…


あうっ、全く分かっていませんでした (^^;
1桁分余裕を入れれば良いと思ってた……、修正し直します。

> メニューアイコンの左右上端にゴミが残っていますね。(アイコン追加する際のガイド用に予備部分に点々をつけているのだと思いますが、これは消しておかないと)

こっちは悩んだ挙げ句に残したのですが、上の点はガイドだったんですね。
それと「右端で折り返し」は「現在のウィンドウ幅で折り返し」のアイコンをコピーして使っているので、両方ツールバーに置くと区別できなくなります。
なので「右端で折り返し」のアイコンをほんの少しですが変更します。

> 分割ビューの場合なんですが、「右端で折り返す」はアクティブなビューの画面幅が変化するとそれに合わせて変化してますね。左右どちらかに固定した方が扱いやすいような気がします。左上のビュー(インデックス0番)のサイズ変更に合わせるのがソースコード記述上でも楽なんじゃないでしょうか?

右側で統一されている予定でしたが間違いでした。おっしゃる通り左上が最も楽なので左上のビューに合わせることにします。

ではでは。

2008/5/31 (土) 21:07:30 なすこじ 返信 削除
Mozilla/4.8 (Macintosh; U; PPC)
[5314] Re2:作ってみました
▼ ryojiさん
「改行ぶら下げ」をマニュアルで確認してみましたが、文字通り改行マークを右にぶら下げると言う事のようですので1桁分の幅ですよね。

従って、折り返し位置より右側に出るのは、
 句読点ぶら下げによる句読点(2桁)+ 折り返し記号(1桁)
 または
 句読点ぶら下げによる句読点(2桁)+ 改行ぶら下げによる改行マーク(1桁)
の3桁になると思います。

折り返し記号はオプションの選択状態によらず発生しますので、結局右側に必要なマージンはデフォルト1桁、「句読点ぶら下がり」選択時3桁で良さそうな感じですがどうでしょう?

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桁)+ 改行ぶら下げによる改行マーク(2桁)
(このときは折り返し記号はつかない)

で最大は4桁かしら?

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にアップしました
▼ なすこじさん
> 色々修正しました。

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

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

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

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

2008/6/3 (火) 13:10:55 なすこじ 返信 削除
Mozilla/4.8 (Macintosh; U; PPC)
[5318] Re2:Patchesにアップしました
▼ ryojiさん

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


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

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


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

『負荷を上げずに「折り返しなし」を使う』オプションを追加して、オプションがチェックされている場合はメモ帳と同様に行長の拡大のみ監視するようにするというのはどうでしょう?(初期値はチェック入)
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にアップしました
> 機能・性能バランス

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

2008/6/4 (水) 12:57:28 なすこじ 返信 削除
Mozilla/4.8 (Macintosh; U; PPC)
[5321] Re5:Patchesにアップしました
▼ ryojiさん
> エディタ機能全体として、既存機能の強化、新機能の追加まで含めたハード的な余力って、どのくらいあるんでしょうかね??

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

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

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

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

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


上記現象の発生条件がわかりません。
文書が編集されたときに下記の関数のどれかが呼ばれれば大丈夫なつもりなんですが、呼ばれないルートがあるのでしょうかね?
 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(最大長だった行が短くなった)
 全行再スキャン

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

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


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

>  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]