ページ:[ ] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [ ]
5448
2008/10/23 (木) 13:44:04 syat  
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
[5448] 「名前を指定してマクロ実行」コマンド追加パッチ
おつかれさまです。syatです。

「名前を指定してマクロ実行」コマンドを追加するパッチを投稿しました。
https://sourceforge.net/tracker2/?func=detail&aid=2188437&group_id=12488&atid=312488

現在UNICODE版にもパッチとして出ています。特に問題がなければ一緒にコミットしたいと思っています。

ANSI版で「自動実行マクロ」というパッチがかなり前からあるのですが、いろいろかぶる部分が多いと思うので、そのあたりのコメントを頂けるとありがたいです。

2008/11/2 (日) 12:02:28 syat  
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
[5452] Commit報告:「名前を指定してマクロ実行」コマンド追加パッチ
rev1461でコミットしました

2008/11/2 (日) 19:08:48 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5453] Re:Commit報告:「名前を指定してマクロ実行」コマンド追加パッチ
▼ syatさん
> rev1461でコミットしました

ANSI版は安定性重視ということで一応ピアレビュー方式になっていますので、いきなりコミットはちょっと問題が……
まあ、慢性的なレビュア不足なので、それはそれで先に進めなくなってしまいますけどね (^^;

取りあえずソースコードおよび動作の確認を行ないました。
ただ、ソースが全て理解できたわけではないのがちょっと情けないのですが、動作上から1点。
タブ幅を変更する下記の1行マクロを実行してみましたが何も変化しませんでした。
S_ChangeWrapColm( S_ChangeWrapColm(0) + 2 );

S_Up();など引き数を伴わないものは実行されますので、引き数が無視されてしまうのでしょうか?

ではでは。

2008/11/2 (日) 21:14:16 syat  
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
[5454] Re2:Commit報告:「名前を指定してマクロ実行」コマンド追加パッチ
▼ なすこじさん
> ANSI版は安定性重視ということで一応ピアレビュー方式になっていますので、いきなりコミットはちょっと問題が……
> まあ、慢性的なレビュア不足なので、それはそれで先に進めなくなってしまいますけどね (^^;

すみません。皆さん忙しいのかなと思ってえぃやぁで入れてしまいました。
ちょっと辛抱足りなかったと反省してます。

> 取りあえずソースコードおよび動作の確認を行ないました。
ありがとうございます。

> タブ幅を変更する下記の1行マクロを実行してみましたが何も変化しませんでした。
> S_ChangeWrapColm( S_ChangeWrapColm(0) + 2 );

その関数は「折り返し桁変更」ですね。
この内容を〜〜.ppaという名前で保存し(PPA.DLLが必要)、実行してみたところ折り返し桁がちゃんと2桁増えます(地味にw)。

タブ幅変更でも動きました。
S_ChangeTabWidth( S_ChangeTabWidth(0) + 2 );

ただ、
拡張子を.macにしてキーマクロとして実行しようとしたら、「S_ChangeWrapColmは存在しない関数です」エラーになってしまいました。なぜ??

2008/11/2 (日) 21:34:44 syat  
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
[5455] 自己レス
> ただ、
> 拡張子を.macにしてキーマクロとして実行しようとしたら、「S_ChangeWrapColmは存在しない関数です」エラーになってしまいました。なぜ??

S_ChangeWrapColmはコマンドじゃない機能だからキーマクロの対象外、なんだろうか。
m_MacroFuncInfoArrではなくm_MacroFuncInfoNotCommandArrに登録されているため、関数名から関数情報を持ってくるところでエラーとして弾かれていました。
m_MacroFuncInfoNotCommandArrをサーチするだけで対応できるのでは?

2008/11/2 (日) 21:59:20 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5456] Re3:Commit報告:「名前を指定してマクロ実行」コマンド追加パッチ
▼ syatさん
> > タブ幅を変更する下記の1行マクロを実行してみましたが何も変化しませんでした。
> > S_ChangeWrapColm( S_ChangeWrapColm(0) + 2 );

> その関数は「折り返し桁変更」ですね。
> この内容を〜〜.ppaという名前で保存し(PPA.DLLが必要)、実行してみたところ折り返し桁がちゃんと2桁増えます(地味にw)。
>
> タブ幅変更でも動きました。
> S_ChangeTabWidth( S_ChangeTabWidth(0) + 2 );


すみません、動かすマクロを間違えていました m(_ _)m
おっしゃる通りppaだと動作しますね。

5441
2008/10/13 (月) 01:31:08 
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; Embedded Web Browser from: http://bsalsa.com/; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0)
[5441] 行番号の描画についてご教示頂けないでしょうか。
お世話になります。
いつも便利に使わせて頂いております。

時間を見つけて自分なりに修正を加えているのですが、
分からないことがあり、ご教示頂ければと思い
失礼ながら書き込みをさせて頂きます。


行番号の桁数が多くなると、見づらくく感じてしまうため
10行単位で表示、またはカーソル行の行番号を表示というように
ボーランドのIDEにあるようなモノにしようと思っております。
下記はイメージです。

2430|
  ・|
  ・|
  ・|
  ・|
  −|
  ・|
  ・|
  ・|
  ・|
2440|
  ・|
  ・|

10行単位での表示にすることは問題なくできたのですが、
カーソル行の位置への行番号を表示させる所でつまづいております。

やりたいこととしましては、
カーソルを動かしたときに行番号の再描画を行うことです。
前回位置を消して、今回の位置に行番号を描画するのかと思いますが、
処理を把握し切れていないため修正箇所がわからない状態です。

開発に参加しているわけでもなく、おこがましいかとは思いますが、
修正するに当たり、関連する箇所などをご教示しては頂けないでしょうか。


以上です。
宜しくお願い致します。

2008/10/14 (火) 13:43:54 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5443] Re:行番号の描画についてご教示頂けないでしょうか。
▼ ゆさん
CEditView.cppのMoveCursor()にて::InvalidateRect()を呼び出せばいけるような気がします。

2008/10/17 (金) 01:56:59 
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; Embedded Web Browser from: http://bsalsa.com/; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0)
[5447] Re2:行番号の描画についてご教示頂けないでしょうか。
▼ なすこじさん
ありがとうございます。
そのあたり、いろいろいじってみようと思います。

ふと思ったのですが、指定桁縦線って
描画順は一番最後なのでしょうか?
文字が縦線で上書きされていたりしたので…

ではでは。

5442
2008/10/14 (火) 02:56:42 syat  
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
[5442] 検索画面などのコンボボックスについてパッチ投稿
検索やGrep画面で、コンボボックスでリストを表示したまま文字列修正+エンターで文字列が消える問題の修正パッチです。

https://sourceforge.net/tracker2/?func=detail&aid=2164156&group_id=12488&atid=312488

UNICODE版リビジョン1453にコミットしたものと同じ修正です。

2008/10/14 (火) 13:50:39 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5444] Re:検索画面などのコンボボックスについてパッチ投稿
▼ syatさん
ソースコードおよび動作を確認しました。
コミットOKと思います。

不具合修正の場合、1つ上の階層にあるBugsInfo.txtにも記述をお願いします。
私も忘れることがあったり、2つある日付けの正確な意味を知らなかったりするわけですが…… (^^;

ではでは。

2008/10/15 (水) 00:53:29 syat  
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
[5445] Re2:検索画面などのコンボボックスについてパッチ投稿
▼ なすこじさん
確認ありがとうございます。
リビジョン1454でコミットしました。
BugsInfo.txtも書きました。

このテキストが開発者視点でのバグ一覧+修正履歴になる感じでしょうか。
日付が2個あるのは、なんとなくバグ報告日と対処日のような気がします.
自分の手に負えないバグを書いておくと、後の人が直してくれたりして…(他力本願ですが)

5437
2008/10/8 (水) 19:48:18 WinUnit  
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
[5437] WinUnit
「単体テストの自動化」メモ

UI以外なら以下の手順でできます(たぶん

・MSDN Magazin February 2008
WinUnit: ネイティブ C++ アプリケーション用の簡略化された単体テスト
http://msdn.microsoft.com/ja-jp/magazine/cc184842.aspx
からコードをダウンロードします。
・これに含まれるWinUnitをビルドします。
・WinUnit.exeとIncludeにあるヘッダを適切な場所にコピーします。
・ヘルプファイル(.chmまたはサンプルがあります)に従いテストコードを書きます。
・新しいプロジェクトを作り、サクラエディタソースとテストコードを合わせてdllを作成します。

 一部のサクラソースだけだとビルドできないと思うので全サクラソースを含めます。
 DLLへの切り替えはWinMain.cppをダミーに入れ替えればできるとおもいます。
 ビルドオプション等は、ヘルプファイルに書かれています。
・ヘルプファイルに従いWinUnitを実行します。

他のツールもありますが、これが一番簡単そうです

5429
2008/9/21 (日) 00:55:19 げんた  
INCM1.23c
[5429] 今後の開発について
ご存じの通り公式版(以下ANSI版)の他にUNICODE版の開発が行われています.
UNICODE版はソースが整理されており普通に使えるレベルには達しているそうなので,ANSI版とUNICODE版で機能的に分岐するのを避ける意味で,今後ANSI版「だけ」への機能拡張は入れない方針にしたいと思います.

改良を行いたい方はまずUNICODE版へ変更(あるいはパッチ)を入れ,その後ANSI版でも必要であればバックポートの形にしてください.

以上よろしくお願いします.

http://sakura-editor.wiki.sourceforge.net/MainStreamPolicy

2008/9/23 (火) 20:51:57 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5431] Re:今後の開発について
▼ げんたさん
UNICODE版をメインストリームにするのは頃合いだと思うのですが、ANSI版のテストバージョンのリリースも打止めですか?

まぁ今もそういう状態なんですが、不具合報告に対して不具合修正パッチを作ってもバイナリが出ないとビルド環境を持っている人しか使えないので、何らかの方法を考えて欲しいです。

2008/9/24 (水) 07:03:00 げんた  
INCM1.23c
[5432] Re2:今後の開発について
>ANSI版のテストバージョンのリリースも打止めですか?
テストバージョンのバイナリは,継続して作った方が良いですね.wikiの方はなすこじさんが作成されたバイナリがあればそれをupしていただければとりあえずはOKかな(^^;)と.リリース候補みたいな形で,Commit分のみのバイナリを作ってもらえるとありがたいです.
sourceforge.netの最新版については昨年末以来全然更新していないので,Commit完了分までは1.6.3.0として正式版を作成する必要があると考えています.Patchesを見ると,すぐにcommitできそうなパッチも残っていますね.
(最新が#1432なのにHistoryに全然書かれていないので,先にそちらの整理が必要ですが...)

最近のバージョンの動作確認とか全然していなかったので,明日すぐとはいきませんが,近いうちに

2008/9/25 (木) 01:05:12 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5433] Re3:今後の開発について
▼ げんたさん
> >ANSI版のテストバージョンのリリースも打止めですか?
> テストバージョンのバイナリは,継続して作った方が良いですね.wikiの方はなすこじさんが作成されたバイナリがあればそれをupしていただければとりあえずはOKかな(^^;)と.リリース候補みたいな形で,Commit分のみのバイナリを作ってもらえるとありがたいです.


了解です。
テストバージョンの必要性を感じた人などが発行すればOKということですね。
もっと堅苦しいことを考えていました (^^;

1ヶ月程後になるかも?ということでしたのでテスト版を発行しておきました。

5430
2008/9/23 (火) 20:08:48 なすこじ  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727)
[5430] ツールバーの更新不具合
>>data:6768 の件についてパッチを作成しました。

ツールバーを再作成したら更新するという方法なので一瞬ちらつきます。

Patches #2124374

UNICODE版はtrunk移行後に対応します。

5426
2008/9/11 (木) 09:25:21 ゆう  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.21022)
[5426] デフォルトUTF-8で開く方法
サクラエディタを、新規で開くとShift_JISで開かれると思いますが、
デフォルトでUTF-8で開かれるような方法はないのでしょうか?

5406
2008/8/18 (月) 17:21:56 漢方特大優惠活動  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
[5406] 管理人削除
-

5401
2008/8/7 (木) 20:10:46 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)
[5401] 右矢印キーで折り返し桁を超えてカーソル移動してしまう
・フリーカーソル
・改行ぶら下げや句読点ぶら下げの設定がオン

になっていると、右矢印キーを押してカーソル移動させたとき、折り返し桁を超えてもずっと右方向にカーソル移動できてしまいます。

修正パッチを作成しました。
Patches#2041524

2008/8/7 (木) 22:06:55 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5402] Re:右矢印キーで折り返し桁を超えてカーソル移動してしまう
ソースコードおよび動作を確認しました。

5397
2008/7/28 (月) 13:05:40 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5397] フリーカーソルかつ上書きモードの時改行より右側へ文字が追加できない
>>data:6704 の件のパッチを作成しました。

Patches #2029982

5363
2008/6/23 (月) 04:07:51 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5363] 長過ぎるパス名で落ちる
>>data:6689も同様と思われる、長過ぎるパスのファイルを開くと落ちる既知の不具合についてです。

下記4箇所で_MAX_PATHを .nMaxFile に設定しますが、_MAX_PATH以上のファイルパスとなるとバッファに'\0'が無い状態となって突き抜けています。

CDlgOpenFile.cpp
 DoModal_GetOpenFileName()
 DoModal_GetSaveFileName()
 DoModalOpenDlg()
 DoModalSaveDlg()

下記のようにすることで取りあえず落ちるのは回避できるんですが、真っ当な方法じゃないような気もします。
 m_ofn.nMaxFile = _MAX_PATH - 1;
 memset( m_ofn.lpstrFile, 0, _MAX_PATH );  // 最後2文字を0にするだけでもOK

どうすべきでしょうか?

2008/6/23 (月) 11:02:28 じゅうじ  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
[5364] Re:長過ぎるパス名で落ちる
▼ なすこじさん
>  DoModal_GetOpenFileName()
>  DoModal_GetSaveFileName()
>  DoModalOpenDlg()
>  DoModalSaveDlg()

この、4個のメソッドを呼び出している所だけでしたら、28ヶ所のみでした。
呼び出すすべての前の所で0クリアしてはどうでしょう。
char szPath[_MAX_PATH + 1];
szPath[sizeof(szPath)-1] = '\0';

私ちなみに、よく分かっていないのですが、
なぜ最後1バイトでなく、2バイトクリアするのでしょうか?

2008/6/23 (月) 21:17:43 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5365] Re2:長過ぎるパス名で落ちる
▼ じゅうじさん
> なぜ最後1バイトでなく、2バイトクリアするのでしょうか?

2バイト文字で切れた場合もう1つ前もゴミとなることがあるためだったのですが、>>data:6694にて要望されたようにメッセージを表示してあげないとまずいということで、前回のものは撤回して下記のようにしようかと思います。

下記関数において、GetOpenFileNameRecover()またはGetSaveFileNameRecover()の戻り値がTRUEの時、バッファ内に'\0'が存在しなければエラーを表示してFALSEを返す。
 DoModal_GetOpenFileName()
  DoModal_GetSaveFileName()
  DoModalOpenDlg()
  DoModalSaveDlg()

上記の4箇所で.nMaxFileに_MAX_PATHを設定しているので、ここでチェックするのが良いと思ったのですが、さらに上位でチェックすべきでしょうか?

2008/6/23 (月) 23:31:13 kobake  
Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
[5366] Re:長過ぎるパス名で落ちる
▼ なすこじさん
> 下記のようにすることで取りあえず落ちるのは回避できるんですが、真っ当な方法じゃないような気もします。
>  m_ofn.nMaxFile = _MAX_PATH - 1;
>  memset( m_ofn.lpstrFile, 0, _MAX_PATH );  // 最後2文字を0にするだけでもOK
>
> どうすべきでしょうか?


MSDNを見ましょう。
GetOpenFileName が FALSE を返したときは lpstrFile を見るのが真っ当な作法ではないでしょうか。確保すべき容量がわかるので、バッファを動的に確保して再試行すれば良いです。たぶん。

MSDN引用
> lpstrFile
> …(略)…
> If the buffer is too small, the function returns FALSE. In this case, the first two bytes of the lpstrFile buffer contain the required size, in bytes or characters.


2008/6/24 (火) 12:25:16 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5367] Re2:長過ぎるパス名で落ちる
▼ kobakeさん
いえ、FALSEは返ってきません。
エラー処理は元々実装されているので、FALSEが来れば最初から問題無いです。
APIがおかしいのか .nMaxFile をよほど小さくしないとtoo smallは返ってこないので別の対応が必要です。まぁ使い方がおかしいだけかもしれませんが……

ANSIなので絶対パスは260バイト以下なわけですが、260バイト目まで文字を詰め込んできます。切れ目が2バイト文字の途中の場合、259バイト目まで詰め込んで260バイト目に0を書かずに返ってきます。

仮に今回too smallが来たとしても、ANSIで260バイトを超える絶対パスはMSの取り決めに反します。
260バイトを超えた絶対パスでいくとどうなるかは私は知りません。

2008/6/24 (火) 23:33:31 kobake  
Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
[5368] Re3:長過ぎるパス名で落ちる
▼ なすこじさん
> ▼ kobakeさん
> いえ、FALSEは返ってきません。
> エラー処理は元々実装されているので、FALSEが来れば最初から問題無いです。
> APIがおかしいのか .nMaxFile をよほど小さくしないとtoo smallは返ってこないので別の対応が必要です。まぁ使い方がおかしいだけかもしれませんが……
>
> ANSIなので絶対パスは260バイト以下なわけですが、260バイト目まで文字を詰め込んできます。切れ目が2バイト文字の途中の場合、259バイト目まで詰め込んで260バイト目に0を書かずに返ってきます。
>
> 仮に今回too smallが来たとしても、ANSIで260バイトを超える絶対パスはMSの取り決めに反します。
> 260バイトを超えた絶対パスでいくとどうなるかは私は知りません。


なるほど、失礼しました。確かに試すとTRUEが返りますね。
がっつりエラーチェックをするならこんな↓感じですかね (ここまでやるか、っつー極端な例かもしれませんが)。

OPENFILENAME ofn;

BOOL bRet = GetOpenFileName(&ofn);
DWORD dwErr = GetLastError();
if(dwErr==ERROR_INVALID_PARAMETER){
        //想定外。プログラム側の問題 (だと思う)。
}
else if(dwErr==ERROR_OUTOFMEMORY){
        //メモリ不足。
}
else if(dwErr==ERROR_INSUFFICIENT_BUFFER){
        //バッファが足りない。バッファをもうちょい確保して再試行する or 失敗メッセージを出す?
}
else if(bRet){
        //成功。ユーザの入力したパスが正常に取得できた。
}
else{
        //ユーザキャンセル。
}


ちなみに環境依存かもしれないですけど(?)、Windows Vista Home Edition の環境では、
バッファを最初から _MAX_PATH*2 確保しておくと、んまぁ一応正常動作しました。結果論ですが。

2008/6/25 (水) 12:43:47 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5369] Re4:長過ぎるパス名で落ちる
▼ kobakeさん
API側がANSIなのに文字カウントをunicodeで行なっている様な変な動作をしているので、おっしゃる様な処理をしないと厳密にはできないですね。

> ちなみに環境依存かもしれないですけど(?)、Windows Vista Home Edition の環境では、
> バッファを最初から _MAX_PATH*2 確保しておくと、んまぁ一応正常動作しました。結果論ですが。


確認ありがとうございます。98,NT以降で大丈夫なのかもしれませんが、
・undocumentedな動作である
・沢山の所で_MAX_PATHが使われているので拡張すると確認が大変
・unicode版なら長いパスを正しく扱えるのでANSI版が対応してなくても大丈夫


ということで、バッファの拡張は行なわずにオーバーフローチェック&エラー表示するだけのパッチを作りました。

2008/6/25 (水) 12:52:09 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5370] Re:長過ぎるパス名で落ちる
長過ぎるパスが指定されたらエラーを表示して処理をキャンセルするパッチを作成しました。

Patches #2002211

2008/6/26 (木) 23:20:03 もか  
INCM1.23c
[5376] Re2:長過ぎるパス名で落ちる
>Patches #2002211
コマンドラインから_MAX_PATH以上のファイル名を送ると落ちるので、
その対策パッチを追加しておきました。
なすこじさんのパッチを確認したかったのですがXP SP3しか環境が無いのでパスします。。

ダイアログの方は、「DBCSのファイル名でMAX_PATH以上」でないと変にならないんですね。
ASCIIだけでMAX_PATH越えにしたら、エクスプローラの右クリックがおかしいし、
ダイアログで「ファイル名が無効」とでてそもそも開けなくなりました。

2008/6/27 (金) 22:14:54 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5377] Re3:長過ぎるパス名で落ちる
▼ もかさん
> >Patches #2002211
> コマンドラインから_MAX_PATH以上のファイル名を送ると落ちるので、
> その対策パッチを追加しておきました。


どうもありがとうございます。
ソースコードおよび動作を確認しました。

あと、私の修正の方で260バイト目がSJISの1バイト目だった時にエラーとならないことがあったので修正しました。

Windows98はちょっと動作が違うようで本修正が有効に働きませんでした。
異常終了しないような感じなので、取りあえずはそのままです (^^;

2008/7/16 (水) 19:10:42 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5388] そろそろコミットしたい
まだ対応に抜けがあるかもしれませんが、ターゲットにした操作へのコードに変な所が無ければコミットしたいです。

その後、落ちる操作が見つかる度にしらみつぶしにしていけば良いのでは?と思います。

というわけで、どなたか構って下さい (^^;

2008/7/28 (月) 02:09:25 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5396] Re:そろそろコミットしたい
編集ウィンドウへのドロップでも落ちていたので対策を施しました。

Patchesの方でも書きましたが、Win98では'\0'を含めて261バイトのパスの時に落ちてしまう事があります。
WinAPIの中で落ちるため本対策では救えません。

それ以外では多分大丈夫です。
一応Win2k SP4, WinXP SP2, Vistaで確認しました。

落ちるという致命的な不具合なので、速やかにコミットまで行きたいのですが……

5392
2008/7/23 (水) 23:34:27 なすこじ  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727)
[5392] 英大文字小文字を同一視すると補完候補が篩い落とされ過ぎる
>>data:6720 での件についてパッチを作成しました。
と言っても候補の篩い落としを「英大文字小文字を同一視」しないときと同様としただけです。

Patches #2025814

2008/7/24 (木) 23:10:03 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)
[5393] Re:英大文字小文字を同一視すると補完候補が篩い落とされ過ぎる
> Patches #2025814

近辺にメモリリーク個所があったので、その修正もパッチに追加しました。

2008/7/25 (金) 18:50:27 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5394] Re2:英大文字小文字を同一視すると補完候補が篩い落とされ過ぎる
▼ ryojiさん
> > Patches #2025814
>
> 近辺にメモリリーク個所があったので、その修正もパッチに追加しました。


どうもありがとうございます m(_ _)m
確認・コミットしました。

5390
2008/7/23 (水) 02:48:56 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)
[5390] タブバー関連パッチのコミット報告
Patches#1844808 「タブバーツールチップ表示処理の簡素化」
Patches#1842668 「最大化画面からのタブ切り離しを可能に」
の2件についてコミットしておきました。

個別のレビューは実施されていないのですが、

・セルフテストながら全サポートOSでのテストを実施済み
・テスト版公開後半年以上経過しても何も問題報告なし
・Unicode版ではコミット済(簡易レビュー済)、こちらも2か月以上経過して問題報告なし


ということで、これ以上はもうレビューを待つ意味も無さそうなので…

本コミットに関して問題があるようでしたら、ご指摘ください。

2008/7/23 (水) 04:36:44 なすこじ  
Mozilla/4.0 (compatible; MSIE 6.0; KDDI-MA33) Opera 8.60 [ja]
[5391] Re:タブバー関連パッチのコミット報告
▼ ryojiさん
> Patches#1844808 「タブバーツールチップ表示処理の簡素化」
 
動作は確認したのですがソースが良く分からなかった orz
 
> Patches#1842668 「最大化画面からのタブ切り離しを可能に」
 
ソースは確認したのですが、デュアルモニタで立ち上がらなくて動作が確認できなかった orz
 
というわけで実は中途半端にレビューしてました (^^;
問題無いと思います。

5378
2008/7/3 (木) 03:46:45 なすこじ  
Mozilla/4.0 (compatible; MSIE 6.0; KDDI-MA33) Opera 8.60 [ja]
[5378] 正規表現での複数行対応
簡易的ではありますが、鬼車使用のまま複数行への対応を考えています。
 
取りあえず検索とgrepは確認できましたが、マッチする箇所に問題があります。
 
aaaaaaというテキストに対してaaaで検索した場合に何ヶ所にマッチするかという問題で、私としては4箇所にマッチして欲しかったのですが必死の過去ログ検索により2箇所が仕様という事が分かりました。
 
これに引っかかっていまして、例えば、
a
a
a
a
a
a
に対してa\r\na\r\naで検索すると、上からの検索は2箇所、下からは4箇所マッチします。
これは、下からの複数行検索は「次の検索開始位置はマッチした文字列の終了位置から」という仕様の影響を受けないためですが、それを加味する様な修正も難しい感じです。
 
で、いっそのこと正規表現での検索時は「次の検索開始位置はマッチした文字列の開始位置の次から」に変更してはどうだろうかと思うのですがまずいでしょうか?

2008/7/3 (木) 10:09:26 なすこじ  
Mozilla/4.0 (compatible; MSIE 6.0; KDDI-MA33) Opera 8.60 [ja]
[5379] Re:正規表現での複数行対応
前言撤回。
やはり既存動作を変更するのは面白くないので、
“正規表現での検索時は「次の検索開始位置はマッチした文字列の開始位置の次から」”
ではなく、
“上からの検索且つマッチした文字列が複数行の場合「次の検索開始位置はマッチした文字列の開始位置の次行の行頭から」”
にしようと思います。
 
こうすれば横方向の動作を変更せずに縦方向の動作を統一できます。
ただ、横方向の動作と縦方向の動作が違って分かりにくく感じるかもしれませんが……

2008/7/4 (金) 08:32:29 神楽  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
[5380] Re:正規表現での複数行対応
▼ なすこじさん
> 簡易的ではありますが、鬼車使用のまま複数行への対応を考えています。
>
> 取りあえず検索とgrepは確認できましたが、マッチする箇所に問題があります。


Grepで改行をまたいでマッチした場合は、出力表示はどのようになるのでしょうか?

2008/7/4 (金) 19:39:50 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5381] Re2:正規表現での複数行対応
▼ 神楽さん
> Grepで改行をまたいでマッチした場合は、出力表示はどのようになるのでしょうか?

現在は最初の行だけが出力されます。
まだ骨組みを作っているような状態なので (^^;

2008/7/7 (月) 03:24:59 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5382] 中途半端ですがパッチ作りました
「正規表現での複数行検索/Grep/置換対応(簡易版)」のパッチを作りました。

ただし、まだ中途半端なので自サイトにアップしています。
ダウンロードページの12
 http://www.geocities.jp/nasukoji_7/download/download_sakuraeditor.html

サクラエディタに対応した正規表現ライブラリの鬼車を用いたまま複数行の検索/Grep/置換に対応します。
複数行つなぎ合わせたバッファを正規表現ライブラリに渡す事で複数行に対応します。
検索/Grep/置換ダイアログにて行数を指定して下さい。
指定可能な行数は1〜9999です。1を指定すると、ほぼ今までどおりの動作となります。
(巨大な数字を指定しても遅くなるだけで意味は殆どありません)

現状できること
・検索
・Grep
・置換(複数行時のすべて置換を除く)


中途半端にできること(動作するが行数指定の方法を提供していないので前回値で動作する)
・正規表現インクリメンタルサーチ
・マクロによる正規表現検索/Grep


できないこと(未設計)
・複数行時のすべて置換
・複数行時の検索文字列のカラーリング


ご意見いただけると幸いです。

2008/7/12 (土) 00:10:13 なすこじ  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727)
[5383] Patchesにアップしました
すべて置換に対応したところまででPatchsにアップしました。
(ログインするのを忘れてしまったが……)

Patches #2016120

現状できること
・検索
・Grep
・置換


中途半端にできること(動作するが行数指定の方法を
提供していないので前回値で動作する)
・正規表現インクリメンタルサーチ
・マクロによる正規表現検索/Grep/置換


できないこと(未設計)
・複数行時の検索文字列のカラーリング

2008/7/16 (水) 18:48:42 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5386] PatchesにAssignをお願いします
CShareData.cppのバージョン番号の変更を忘れていたのでアップし直そうと思ったのですが、Submitteed Byがnobodyなためアップできなくなってしまったようです (^^;

申し訳ありませんが、どなたか管理者権限で私にAssigned Toをしておいて頂けないでしょうか?

宜しくお願いいたします m(_ _)m

5384
2008/7/14 (月) 11:22:27 名無し  
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9) Gecko/2008052906 Firefox/3.0
[5384] 開いているファイルを閉じてもロックされている。
開いているファイルを閉じてもロックされている。
◆現象
サクラエディタでテキストファイルを開き、閉じてもサクラエディタがファイルをロックして削除やらの操作ができない。サクラエディタ常駐を閉じるとできるようになる。
◆原因
タイトルどおり。
◆兆候

このバグは既知のものですか?バグではなく仕様ですか?

5281
2008/3/30 (日) 22:30:45 miau  
Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
[5281] WSH マクロの Ruby、PHP、Phython 対応
>>macro:412 で Ruby マクロの話が出ていたので、Ruby、PHP、Python で作成した WSH
マクロを実行できるようにしてみました。

Patches#1929358

Patch の説明ページにも書いたんですが、AddNamedItem で SCRIPTITEM_GLOBALMEMBERS を指定すると Ruby が落ちてしまうようなので、このフラグを外しています。
そのためこのパッチを適用すると今まで InsText("hoge"); と書けていたところを Editor.InsText("hoge"); のように書く必要が出てくるんですが・・・このフラグは意図的につけていたものでしょうか?
Ruby の需要はそれなりにありそうですので、もし問題ないのであれば外してしまいたいのですが・・・。

2008/4/18 (金) 05:31:43 じゅうじ  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
[5284] Re:WSH マクロの Ruby、PHP、Phython 対応
>>macro:421 anonymousさん
旧のコードに対応という意味で、
[v]「$Editor->」が省略されたWSHマクロ
を、デフォルトに。

2008/4/18 (金) 18:03:02 wakura  
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)
[5285] Re2:WSH マクロの Ruby、PHP、Phython 対応
▼ じゅうじさん
アプリケーションエラーで落ちるので反対します。

2008/4/18 (金) 18:08:02 wakura  
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)
[5286] Re3:WSH マクロの Ruby、PHP、Phython 対応
> アプリケーションエラーで落ちるので反対します。
言葉足らずだったので補足。
アプリケーションエラーで落ちるような動作をデフォルト設定にするのはおかしいという意味です。

2008/6/19 (木) 10:32:07 とおりすがり  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
[5350] Re:WSH マクロの Ruby、PHP、Phython 対応
それでいつ頃対応されるのですか?
デフォルト設定はどうでもいいので、早く使えるようになってほしいです。

2008/6/20 (金) 06:11:40 miau  
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Sleipnir/2.7.2
[5354] Re2:WSH マクロの Ruby、PHP、Phython 対応
▼ とおりすがりさん
> それでいつ頃対応されるのですか?
> デフォルト設定はどうでもいいので、早く使えるようになってほしいです。


>>macro:422 にも書いたんですが、できれば現行の仕様(Editor を省略可)
のまま Ruby に対応したいと考えています。参考書籍の入手が遅れているので、
私のほうで調査を開始するのは 7 月以降になりそうです。
(Python マクロが環境によって動かなかったりするのも併せて調査予定です。)

・・・と書いてて気づいたのですが、オプションを設ける方法以外に
「Ruby マクロであれば SCRIPTITEM_GLOBALMEMBERS しない」
というような分岐処理をする方法もありますね。
調査に時間がかかる可能性もありますし、一旦この状態で取り込んでいただく、
というのもいいかもしれません。

2008/6/23 (月) 02:08:53 なすこじ  
Mozilla/4.8 (Macintosh; U; PPC)
[5362] Re3:WSH マクロの Ruby、PHP、Phython 対応
▼ miauさん
この状態でコミットするのもちょっと変な感じですが、調査が進展・解決するまでストップというのも何だかもったいない感じですね。

Ruby、PHP、Phythonを使いたい人には制限があっても有用でしょうから、派生版・改造版としてJunkなりmiauさんのサイトなりにビルドしたファイルをアップするというのはどうでしょうか?
Wikiの方に派生版のリンクが何個か存在するようですし……
ただ、バージョン表記やタイトルバーの文字列をいじる必要はあるかも?

ページ:[ ] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [ ]
INCM/CMT
Cyclamen v3.81
[ut:0.040][st:0.020]