まず、普通に起動直後や発言取得直後に開いた際には、一度も問題は起きていません。
問題が起きるのは、投稿直後に限られます。
この時は、CMNごと、不正終了します。
その時のメッセージは、

---------------------------
cmn.exe - アプリケーション エラー
---------------------------
"0x77fcaff8" の命令が "0x33452542" のメモリを参照しました。メモリが "written" になることはできませんでした。


プログラムを終了するには [OK] をクリックしてください
プログラムをデバッグするには [キャンセル] をクリックしてください
---------------------------
OK キャンセル
---------------------------
です。

ちなみに、プロパティを開く時の動作ですが、
■フォルダプロパティが開かれた時
*ICpx::QueryInterface
*ICpx::AddRef
*ICpx::cpxGetExtInfoBase
・ICpx::cpxGetExtInfoProp
*ICpx::Release

（*は、サンプルのまま）
cpxGetExtInfoPropでは、渡されてくるTExtInfoPropを設定しているだけ
と言う状態で、ほぼ、サンプルのままに近いです。

発言投稿SendMesは、バグバグで、ようやくリークが無くなったくらいです。
なので、SenMesを通過したら、cpxReceiveMesは、先頭でTrueを返し、何もしないようにしています。

で、SenMesが正常終了し、ちゃんと投稿され、リークも報告されず、ｈｔｔｐリクエストの様子も正常です。

で、プロパティを開く時に不正終了するのも、毎回ではありません。

当然、自業自得な訳で、色々探っていたのですが、この点だけでも、何かお気づきの点がありますでしょうか？

----
YOS

YOSさん、こんにちは。

投稿文字コードはUTF-8でしょうか。

DECO

#197 DECOさん、こんにちは。

＞投稿文字コードはUTF-8でしょうか。

はい。そうです。
投稿時に、UTF-8を指定しています。

----
YOS

YOSさん、こんにちは。

＞投稿時に、UTF-8を指定しています。

EUCのmixiでは大丈夫ということは、UTF-8への文字コード変換が一番怪しい感じですね。
ちょっと調べてみます。

DECO

#202 DECOさん、こんにちは。

＞EUCのmixiでは大丈夫ということは、UTF-8への文字コード変換が一番怪しい感じですね。
＞ちょっと調べてみます。

よろしくお願いします。
細かい違いは多々あれど、最大の違いは、これです。

folomy用は、ほとんどmixi用の移植でして、追加機能はほとんど無く、むしろ、不要な部分をカットしています。

投稿に関しても、キーコードを付加しないと、受け付けてくれませんので、何度かリクエストしています。

----
YOS

YOSさん、こんにちは。

ようやく原因がわかりましたぁー。

「投稿文字コードがUTF-8」で、かつ「MultiPartではない時」に、投稿内容によってはメモリが壊される場合があります。

うぇいくさんのケースもこれだと思います。


Folomy_x.cpx の場合には cmnMakePostData が２度コールされてまして、最初は MultiPart は true なのですが、二度目は false になっていて、その時に落ちます。

これについては次版で修正されますが、とりあえず二度目のcmnMakePostData がなければ問題ないと思うのですが、これって必要あるんでしたっけ？

DECO

＞「投稿文字コードがUTF-8」で、かつ「MultiPartではない時」に、投稿内容によってはメモリが壊される場合があります。
＞
＞うぇいくさんのケースもこれだと思います。
発生条件からすると、該当しますね。

やはり、

全角１文字
　SJIS-2bytes→UTF8-3bytes→URLencode-9bytes(通常の最大)

半角カナ
　SJIS-1bytes→UTF8-2bytes→URLencode-6bytes(通常の最大)

とゆーあたりが引っかかるポイントでしょうか・・・
# VistaやXPのUpdateでサロゲート文字を使っていると、さらにえらいことに・・

　ふと、CMNのUTF8以外では影響が無いと思うのですが、UTF8を使用した場合のサロゲート文字の対応はどのようになるのでしょうか？
# cpx側は除く。おそらくは、cpxごとに対応が異なるため。
-- CMN v0.50dβ --

うぇいくさん、こんにちは。

＞　ふと、CMNのUTF8以外では影響が無いと思うのですが、UTF8を使用した場合のサロゲート文字の対応はどのようになるのでしょうか？

SJIS→UTF8の過程でサロゲート文字が存在する可能性ってあります？

DECO

＞SJIS→UTF8の過程でサロゲート文字が存在する可能性ってあります？
・・・あれ？そうすると、サーバ側がUnicode(UTF-8)の場合であっても、ひょっとして、それらの文字を使うことはできない・・・？
# cmnMakePostParamするまでは、内部コードではSJISで保持しているんですよね？

取り込む際にもSJISにしないと（変換できないと）だめなんですよね？
-- CMN v0.50dβ --

うぇいくさん、こんにちは。

＞＞SJIS→UTF8の過程でサロゲート文字が存在する可能性ってあります？
＞・・・あれ？そうすると、サーバ側がUnicode(UTF-8)の場合であっても、ひょっとして、それらの文字を使うことはできない・・・？
＞# cmnMakePostParamするまでは、内部コードではSJISで保持しているんですよね？

内部はSJISです。
ので、unicodeのサロゲート文字に対応する文字は存在しないのかなと。

＞取り込む際にもSJISにしないと（変換できないと）だめなんですよね？

SJISに存在しない文字は化けることになりますね。
どのようになるかは試してみないとわからないです。

DECO

#204 DECOさん、こんにちは。

＞「投稿文字コードがUTF-8」で、かつ「MultiPartではない時」に、投稿内容によってはメモリが壊される場合があります。

なるほど。

＞Folomy_x.cpx の場合には cmnMakePostData が２度コールされてまして、最初は MultiPart は true なのですが、二度目は false になっていて、その時に落ちます。

その通りですが、これって、ツールによる解析ですか？
CMN本体をデバッガ上で実行して、返値を調べたわけですか？

すみません。
企業秘密かも知れませんね。
ただ、この前のようなエラーメッセージや、ワトソンログの解析などを送りつけられる機会が増え、この手の情報も、デバッグに使えるようになりたいと思っていた矢先だったんです。
(^^;ゞポリポリ

＞これについては次版で修正されますが、とりあえず二度目のcmnMakePostData がなければ問題ないと思うのですが、これって必要あるんでしたっけ？

はい、いります。
ブラウザでの投稿が、こうなっています。
最初のMultiPartの応答が、「これでよろしいですか？」の画面で、この中に、キーコードが、その都度生成されて、書き込まれています。
これを加えて、MultiPartがOFFで投稿して、初めて受理されます。
なので、避けて通れません。

ただ、どうせ、ブラウザでないと、画像ファイルは、アップできません。
画像のアップは、ブラウザで行うことになります。
そのため、ブラウザでの投稿をデフォにしています。

CPXでのファイル指定が複数可能になった暁には、ブラウザ投稿は不要になりますが、それまでの間は、必要な手順です。

結局、複数ファイル投稿の自力実装は、挫折したんです。
今から思うと、この問題で、エラーがでていたのかも知れませんが、どうしてもエラーが止まらないので、Nullな$Fを３回指定して、サーバーを騙しています。

非力故に、お手数をおかけしますが、よろしくお願いします。

----
YOS

YOSさん、こんにちは。

＞その通りですが、これって、ツールによる解析ですか？

VC++のデバッガです。
投稿予定発言が一つしかないのにcmnMakePostDataが二度コールされたもので。

＞ただ、この前のようなエラーメッセージや、ワトソンログの解析などを送りつけられる機会が増え、この手の情報も、デバッグに使えるようになりたいと思っていた矢先だったんです。

基本的にはIPレジスタ（実行ポインタ）の値で例外が発生した場所を特定するということになります。
それ以外のレジスタやスタックの内容は、IPで場所を特定してから参考にするという感じです。

＞最初のMultiPartの応答が、「これでよろしいですか？」の画面で、この中に、キーコードが、その都度生成されて、書き込まれています。
＞これを加えて、MultiPartがOFFで投稿して、初めて受理されます。

なるほど。

＞ただ、どうせ、ブラウザでないと、画像ファイルは、アップできません。
＞画像のアップは、ブラウザで行うことになります。
＞そのため、ブラウザでの投稿をデフォにしています。
＞
＞CPXでのファイル指定が複数可能になった暁には、ブラウザ投稿は不要になりますが、それまでの間は、必要な手順です。

CMNで投稿できる画像は1つだけでもいいような気もしますが・・・。
複数画像を投稿することって、頻度としてそれほど多くないと思うのですが。

DECO

#208 DECOさん、こんにちは。

＞VC++のデバッガです。

なるほど。

＞基本的にはIPレジスタ（実行ポインタ）の値で例外が発生した場所を特定するということになります。
＞それ以外のレジスタやスタックの内容は、IPで場所を特定してから参考にするという感じです。

(._.) φ メモメモ
レジスタ類は、Z80で止まってます。ヾ(^^;;
この頃は、ハンドアセンブルやら、アセンブラやら使ってました。

ニューモニックの知識が、欠かせないみたいですね。
統合環境が充実してきたせいか、Ｗｅｂにも、この手の情報は少ないので、望み薄ですが、一応当たってみます。

通常は、Delphi内で事足りますので、滅多に使わないテクかも知れませんね。

＞CMNで投稿できる画像は1つだけでもいいような気もしますが・・・。
＞複数画像を投稿することって、頻度としてそれほど多くないと思うのですが。

頻度で言えば、無茶苦茶少ないです。
必須になったのは、今回が初めてです。
mixiでは、２つ目以降は、登録しなければ、ファイルであるというヘッダは付加しないですむので、単純に&file2=&などと繋げれば、通してくれてます。

自前実装に関しては、実は、ほぼ完成してました。
ただ、どうしてもエラーが取れないので、CMNとのやりとりがうまくいかないためと判断して、コードを廃棄してしまいました。

画像投稿を行うことは、少なくないでしょうけど、それほどの頻度ではないと思っています。
大多数は、文字のみの投稿でしょう。
なので、とりあえず、巡回時の投稿は、文字のみに限定しようと思っています。

さしあたって、現状の仕組みを維持します。
その上で、要望が多ければ、まず自前を。
その上で不可なら、ヘルプ要請なり、実装依頼を再度お願いするなり致します。

----
YOS

YOSさん、こんにちは。

＞必須になったのは、今回が初めてです。
＞mixiでは、２つ目以降は、登録しなければ、ファイルであるというヘッダは付加しないですむので、単純に&file2=&などと繋げれば、通してくれてます。

folomyで画像を投稿するには３画像セットでなければならないということですか？

DECO

#212 DECOさん、こんにちは。

＞folomyで画像を投稿するには３画像セットでなければならないということですか？

文字のみの投稿に置いても必須です。
「Content-Type：application/octet-stream」が付いていないと、「画像は300KB以下にして下さい」とか言う、いみふめなエラーがでます。
ゼロKBだっちゅうに。

なので、現状では、このヘッダを付加すべく、$Fを、３回指定しています。
で、間違って指定されると、同じ画像を３つ上げてしまうので、フォームエディタ用の定義では、カットしてあります。

で、自前実装というのは、残りの二つのマルチパート部分にこのヘッダを挿入し、体裁を整えた後、投稿データのサイズを再設定していました。

----
YOS

＞で、自前実装というのは、残りの二つのマルチパート部分にこのヘッダを挿入し、体裁を整えた後、投稿データのサイズを再設定していました。
残り２つについては、画像のアップロード自体は対応しないということですよね？
# １画像は$Fを使用してアップロード可能。

であるなら・・・・

１．いつもどおりデータ生成。ただし、File2とFile3に関しては、（ダミー項目も）一切含めない。
２．いつもどおりMakePostParam。
３．出来上がってきたlpPost/cPostの後ろに、空のFile2とFile3をヘッダと中身をセットして付け加える。
# この際、MakePostParamで使用されたBoundalyを参照する必要あり。

という流れが１番簡単そうな気がします。
# おそらくは、途中にヘッダをはさむよりは。

３については・・・
１．追加する必要のある内容（のみ）を普通に文字列でごりごりと生成。
２．MemAllocで、cPost+生成した文字列の長さの領域を確保。
３．lpPostからの内容を確保したメモリにCopy(MemCopy?)。長さはcPost。
４．確保したメモリのアドレス+cPostに、生成した文字列をCopy(MemCopyでもStrCopyでも可能・・・なはず)
５．Requestの際には、「２」で使用した長さと、「２」で確保したアドレスを使用。
６．finalyで後始末。確保したメモリをりりーす。

という感じでしょうか。
# lpPostは、cmnMakePostParamで返される生成したPostパラメータの先頭アドレス（復帰値?)、cPostは、生成されたPostパラメータの長さ(TPostParamの項目にあったよーな？)
-- CMN v0.50dβ --

#214 うぇいくさん、こんにちは。

＞という流れが１番簡単そうな気がします。
＞# おそらくは、途中にヘッダをはさむよりは。

なるほど。
投稿実行までに、体裁を整えればいい訳ですからね。
この前作ったのは、いわゆる置換を行っていました。

＞５．Requestの際には、「２」で使用した長さと、「２」で確保したアドレスを使用。

これは、ＯＫでしょうか？
えっと、bufferは、どうせ解放するのだから、良いのかな？
CMN側のメモリにないといけないのかと思い、追加する分だけの余分なデータを追加しておき、置換してました。

＞# lpPostは、cmnMakePostParamで返される生成したPostパラメータの先頭アドレス（復帰値?)、cPostは、生成されたPostパラメータの長さ(TPostParamの項目にあったよーな？)

確かそうです。
格納されていたアドレス、バイト数を参照し、書き戻していました。
こちらの方は、DLL側のメモリで良いと思い、気軽に書き換えてました。

落ち着いたら、再度チャレンジしようと思っていますが、その際には、このやり方で作ってみます。

----
YOS

YOSさん、こんにちは。

＞CMN側のメモリにないといけないのかと思い、追加する分だけの余分なデータを追加しておき、置換してました。

投稿データはcpx側でアロケートした領域でもＯＫです。

DECO

#217 DECOさん、こんにちは。

＞投稿データはcpx側でアロケートした領域でもＯＫです。

分かりました。
作ったものは、冗長な処理はあったものの、それなりに動くものだったようですね。
全ては虚空に消え去りましたが。

発言に関しては、他にもお聞きしたいことがありますので、新規に書きます。
こちらは、単純な質問ですので、ご安心を。(^^)

----
YOS

YOSさん、こんにちは。

＞文字のみの投稿に置いても必須です。
＞「Content-Type：application/octet-stream」が付いていないと、「画像は300KB以下にして下さい」とか言う、いみふめなエラーがでます。

なるほどーーーーー。
これでこれまでの内容の全貌をようやく理解することができました。(^o^;)

＞なので、現状では、このヘッダを付加すべく、$Fを、３回指定しています。
＞で、間違って指定されると、同じ画像を３つ上げてしまうので、フォームエディタ用の定義では、カットしてあります。

この理由もようやくわかりましたー。

DECO

#216 DECOさん、こんにちは。

＞この理由もようやくわかりましたー。

よろしくお願いします。

mixiでは、「投稿は対応しません」の一言で、特に異論はないのですが、folomyは、Nifの色が濃いため、巡回時の投稿を希望する人が多いですね。

私としては、投稿に対応すると、爆発的に発言が増えてしまい、サーバー増強など、運営側に負担が増すので、躊躇しています。
ただ、とらさんなんかは、乗り気みたいですね。

画像投稿については、一部のコミュ以外では、ほとんど見られないので、さほど強烈な要望にはならないと考えています。
なので、「画像は１個だけ」と言うことで、収まって欲しいものです。

----
YOS

ひょっとすると、
・UTF-8
・投稿時の流れでcmnMakePostDataを使用
ということだとすると、似た現象かもしれませんね。

# そして、当方では原因の切り分けがよくわからないので、cmnMakePostDataを自前で実装しちゃったわけですが・・・
-- CMN v0.50dβ --

#198 うぇいくさん、こんにちは。

＞ひょっとすると、
＞・UTF-8
＞・投稿時の流れでcmnMakePostDataを使用
＞ということだとすると、似た現象かもしれませんね。

あう。
#157の件ですよね。
「うぇいくさんすげぇ」と、読み流してましたが。(^◇^;)

＞# そして、当方では原因の切り分けがよくわからないので、cmnMakePostDataを自前で実装しちゃったわけですが・・・

むむむ。
マルチパートでの投稿と、通常の＆で繋いだ投稿の二つがあるんですけどぉ。
って、これは、一種類で良いのか。

----
YOS

#196 YOSさん、こんにちは。

CMNの落とし方。

拙作folomy用エクステンションで、フォルダプロパティ→詳細と開いて、
げだうモードを有効（いみふめはOFF）をチェックすると、会議室のコメントに限り、直接投稿可能になります。

なお、返信のテンプレートのヘッダ欄に、
「＞＞$#. $nさん [$e]」（＞＞は、半角）
を記入しておくと、ブラウザでのコメントと同じ形式で投稿されます。

で、投稿すると、３０％位の確率で、お亡くなりになります。

ちなみに、mixiも、ほぼ同様な手順です。
見た目は違いますが、内部処理は同じです。
（mixiは、オフレコ希望）
こっちは、今のところ、ノーエラーが続いてます。

----
YOS