なでしこ１修正・追加２点をこみっと

[うぇいく]

プログラムコンテスト開催おめでとうございます(?)。

　だいぶ間があきましたが、なでしこ１のほうで、以下の２点の修正・改修をこみっとしておきました。
・Vista系の(警告・２択・情報)ダイアログのアイコンをたぶん正しいものに修正。
・全ファイル検索の際のウィンドウタイトルへの検索パスの表示をオプションでオフにできるよう修正。

いまは、要望掲示板を眺めてみて、グリッド系の要望がずいぶんとそのままになっているなぁ　ということで、その辺を見ています。
（幅の設定だけでもないと、ちょっと使い物にならないような・・・）
あと、正規表現系でアプリケーションが落ちる障害があるようなので、まとまった時間が取れた際に直せたらよいなぁ　という感じです。

この辺まで含めて、１度リリースしてコンテストで使うベースになればよいなぁ　と思っています。
他に、要望掲示板や質問掲示板で、対応した方がよさそうなものとかあれば指定してもらえれば、とりあえず、検討だけしてみます。
（目を通して手を出してなくて残っているということは、手が出せなかった(わからなかった)可能性が高いのでとりあえず検討。）

あと、コンテストではサードパーティのPluginの利用はありなんでしょうか？なぜ気になったのかというと、
自分で作成して公開してないPluginを使われると抜け道っぽいなぁ　と。
（応募と同時にこうかいするのもちょっと抜け道っぽい。）
以下、その時に思いついたネタ。
「こー、tetris_plugin.dllとか作って、
----
Aとは整数
Aはテトリス作成
Aに母艦ハンドルをテトリスハンドル設定
Aをテトリス開始
---
で、なでしこで作りましたと言い張る。」

、なでしこ２のWPF系を実装の際、あちらはGUI部品の作成をすると素のWPFのオブジェクトが返るようにしています。
そのため、他のPluginにて追加機能や追加の部品を作成することが可能になり、GUI系の部品の分散と第３社が便利な単独機能のGUI部品を
作る余地がある・・・といいなぁと思っています。
これがなんとかなでしこ１にも適用できるとよいのですが、.NETやJavaでないと別途SDKなどでクラス詳細を伝えないといけないので
難しいかなぁ　というとことで止まっています。
以下、この時に思いついたネタ。
「なでしこ２で応募しようとする場合、cnakoになるので機能は結構そろっているものの、コンソールになるなぁ・・・・そうだ、
wnako_wpff2そのものをコンテストに応募してしまえばいいのかっ」
（ただのネタです。念のため。）

[酒徳峰章]

うぇいくさん、ＭＬのみなさん

クジラ飛行机です。こんにちは。
なでしこ１の修正ありがとうございます！！
私の方でも、掲示板見て、問題点の修正を行いたいと思います。
とは言え、今日中に一度、たまっている分を修正してアップしてしまいますね。
難しいのは宿題で、残してしまうと思いますが。。。

コンテストですが、ある程度のプラグインは問題ないと思っています。
プログラムの内容も審査対象ですから。

楽しみにしています。

2014年12月4日木曜日 0時34分18秒 UTC+9 うぇいく:

[うぇいく]

　メモリ違反対策での謎の+1で、テストに失敗するようになっています。データを見ると、文字列終端の#0まで結果に
含めてしまっているためです（つまり、+1は誤対策の模様）
原因を調べているのですが、まだよくわかりません。
・データの発生元はdnakoの正規表現関連の結果の文字列で3bytes。
・エラーの発生はvnakoのsayの中でのSay用ダイアログでOK押して閉じた後のf.freeの中のFastMM中？
・本来、vnakoとdnakoの間ではいわゆるDelphiのStringはわたらない(ポイントかポインタと長さでやり取りする）という既定のはず。
・もし、わたってしまっていた場合、双方のプロジェクトにはShareMM.dllによるメモリ管理の共通化が必要。

というあたりで、何らかの経路でdnakoで確保したStringをvnakoが解放しようとしているのかなぁ　と推測しています。
時間が取れたらいろいろ検証してみる予定ですが、以下の補法が役に立つかもしれません。
・FastMMをフルデバッグモードにしてみる。
・ためしに、SharMMを有効にしてみる(今回のケースならdnakoとvnakoのみ入れたフォルダを準備すれば他は準備不要？）

いまだと、正規表現系の結果がほぼ全滅(正しくないうえに#0が悪さをする)なので、とりあえずアプリケーションエラーの
出る状態に戻すのも手かもしれません。

2014年12月4日木曜日 0時34分18秒 UTC+9 うぇいく:

[酒徳峰章]

うぇいくさん

クジラ飛行机です。検証作業、ありがとうございます。
確かに、正規表現の命令がうまく動いていませんでしたね。

私のテスト環境も、正しくなかったようですみません。

(@745)の２５６倍で正しく動かない問題も修正し、
正規表現のテストを強化して、再度アップしました。

前回(@744)のメモリエラーの問題は、メモリのコピー違反が問題で、
やはり、BRegExpのライブラリの実装ミスが問題でしょう。

うぇいくさん、基本的な問題に気づかせてくださり、
ありがとうございました！！

ただ、やはり12/4のアップデートはかなり問題の高いものでしたので、
修正版をすぐにアップしました。（メーリングリストでも、告知します。）

それでは、感謝まで。

2014年12月8日月曜日 21時52分08秒 UTC+9 うぇいく:

[うぇいく]

修正内容の意図が良くわかりませんでしたが、とりあえずFastMMをフルデバッグモードで試してました。
その結果、vnakoの「言う」の中から呼ばれている、CutLine(StrUnit.pas:249)にて、String書き込み時の
バッファオーバーランがあるようです。
今回のデータは、「ん#10」という3bytesのデータですが、変換後領域としても3bytes準備し、LFをCR+LFに
自動拡張した結果、+1byte書き込んでしまう上に、さらに、#0も書き込んで、計5bytes書き込んでいます。
(#0の書き込みは、本来なら最悪でも既存の#0の上書きになるので問題なかったはず？)

結果、String領域のMemFreeの際にフッター破壊として検出されました。
必要に応じて拡張するようにするか、確実に足りる容量を確保しないとダメそうです。
既存のバイト数は最大(最悪)のケースで1.5倍(A#10A#10A#10と続くケース)ほどになると
思います(文字数での追加改行を除く)
というあたりまではわかったのですが、どう直してよいかはわかりませんでした。
申し訳ないですが、修正の方はよろしくお願いします。
ところで、今回の置換にて「ん#13#10」ではなく、「ん#10」になるのは、良いんでしょうか・・・？
（C++から試しても「ん\n」なので、BRegExpの仕様ということになるとは思いますが）

2014年12月9日火曜日 0時02分51秒 UTC+9 酒徳峰章:

[うぇいく]

とりあえず、CutLineの障害対策として、結果の長さに(len div 2) +1を加えて確保するように

してみました。

また、BRegExpで無駄に+1してコピーしていた部分を、+1しないようにしました。これは、結果の長さが0の場合、

長さ=0、結果を指すポインタ=NULLで返ってくるため、アクセス違反を誘発していると判断したためです。

もし、そちらで修正ができているようでしたら、当方のはrivertしてしまって構いません。なにか、

論理上の最大値でバッファを確保するのはあまり好きではない方法なので・・・

なお、全テストの際、最初の１回だけsqlite.dllのロードに失敗しましたが、そのまま続けて２度目実行したら

成功しました。原因は不明です。もしかすると、テスト内容の動的な更新が入るとsqlite.dllの読み込みに

失敗しているのかもしれません(要望掲示板になにかあったような・・・？)

2014年12月10日水曜日 21時48分11秒 UTC+9 うぇいく:

[うぇいく]

蛇足。
今回の修正は、
正規表現部分が、dnako.dll
前回リリースのはずのファイル列挙関連が、nakofile.dll
vnakoの言う(strunitのCutLine)は、vnako.exe
です。
（文字列系dllや独立したdllではないんですね＜regexp系）

[うぇいく]

現在のバージョン(1.546)では、正規表現系で結果が空文字列(長さ0の文字列)になるだけで
エラー(メモリアクセス違反)となってしまうので、早めに更新した方がよさそうです。
このエラーの対策は、r332に含まれます。

2014年12月11日木曜日 23時15分19秒 UTC+9 うぇいく:

[酒徳峰章]

クジラ飛行机です。

うぇいくさん、お返事が遅くなってすみません。
修正作業ありがとうございました。
とにもかくにも、詳しい調査と的確な修正に感謝です！！

私の方では、SVNでソースコードのチェックと、実行テストしかしてないですが、
メモリ違反が修正されているとのことで、最新版をアップしますね。

今回の修正点です。

2014/12/22 version 1.547
- vnakoの言うに\rや\nのみの改行があるとメモリ違反となる障害に対応(@744)(r332)
-正規表現区切るで区切り文字が無い場合の結果を区切ると同じになるよう修正(@749)(r333)
-吹き出し表示が指定した座標にかかわらず母艦の中央に表示されてしまう現象に対応(r334)



2014年12月20日土曜日 15時29分11秒 UTC+9 うぇいく: