OTN-Japan掲示板では以下のような感じなのですが・・・

・発言番号は、必ずしも昇順とは限らない。
　（１つのツリー内で親発言のほうが発言番号が大きい場合がある）
・コメントが付くまでは、本人が編集可能。
　（コメントが付くと、編集不可能になる）
　編集すると、最終更新時刻が更新される。
・削除も同様（コメントが付くまでは本人も可能。）
　削除すると跡形も無く消える・・・かどうかは不明。

そこで、以下のようにしました。
・発言番号は、昇順ではないケースに対応するため、文字列にする。
・編集による時間の更新があるため、発言の管理方法はNMID_DATEにする。
　また、発言番号が昇順であるという保証も無いので、NMID_DATEは必須。
　（そうしないと、再読み込みとかの管理ができない・・・）

そうすると、当たり前のように、REPLACE指定で取り込んだ発言が、同じ発言番号（文字列）に対しての上書きとしては動作しません。
# ExtInfoProp.idNewMes = NMID_DATE; だからですよね？

もし、NMID_DATEによる動作であるとすると、MesNumberもしくはKeyが同一のものを、REPLACEするような指定はできないものでしょうか？
# NMID_DATEの場合は、何を持ってREPLACEされるのだろう・・・
-- CMN v0.50dβ --

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

＞　OTN-Japan掲示板では以下のような感じなのですが・・・
＞
＞・発言番号は、必ずしも昇順とは限らない。
＞　（１つのツリー内で親発言のほうが発言番号が大きい場合がある）
＞・コメントが付くまでは、本人が編集可能。
＞　（コメントが付くと、編集不可能になる）
＞　編集すると、最終更新時刻が更新される。
＞・削除も同様（コメントが付くまでは本人も可能。）
＞　削除すると跡形も無く消える・・・かどうかは不明。

この場合、更新された発言の元発言を何をもって識別することができるのでしょうか。
同じ人が二つレスを書いていたとして、その片方を消して、残った方を更新した場合、どっちの発言が更新されたか人間が見てもわからないような気が・・・。

＞そうすると、当たり前のように、REPLACE指定で取り込んだ発言が、同じ発言番号（文字列）に対しての上書きとしては動作しません。
＞# ExtInfoProp.idNewMes = NMID_DATE; だからですよね？

その通りです。

＞もし、NMID_DATEによる動作であるとすると、MesNumberもしくはKeyが同一のものを、REPLACEするような指定はできないものでしょうか？
＞# NMID_DATEの場合は、何を持ってREPLACEされるのだろう・・・

NMID_DATEは、基本的に発言番号がない（発言を特定するキーがない）場合を想定しているものなので、REPLACEに対応していません。
NMID_NUMにして番号を発言を特定できるような文字列（本当の発言番号ではないもの）にするしかないような気がします。

DECO

＞この場合、更新された発言の元発言を何をもって識別することができるのでしょうか。
＞同じ人が二つレスを書いていたとして、その片方を消して、残った方を更新した場合、どっちの発言が更新されたか人間が見てもわからないような気が・・・。
発言番号に当たる物は、単に、昇順/降順が保障されないだけで、一意です。なので、削除であるのか、更新であるのかの区別は尽きますし、そのままの値を、stKeyに設定して使用しています（もちろん、数値→十進数文字列変換して。）
・・・が、この発言場号に当たるもの、ブラウザからは見えません。そのため、ふつうにブラウザから参照しているユーザからすると、削除して再投稿しても、既存の発言を編集しても区別が付きません・・・・うーむ（笑）
# 本文を含まない形式で表示される画面の場合、最終更新日時がでるため、これで日付をチェックし、さらに、本文を含む形式の画面では、投稿日時が表示されるため、これで区別がつきます・・・が、そこまで区別してもあまり意味はありません（笑）

＞NMID_DATEは、基本的に発言番号がない（発言を特定するキーがない）場合を想定しているものなので、REPLACEに対応していません。
＞NMID_NUMにして番号を発言を特定できるような文字列（本当の発言番号ではないもの）にするしかないような気がします。
この場合、掲示板プロパティの、既読番号の部分が利用できませんよね・・・？あの部分の日時入力も楽ですし、また、１つのフォルダに３０個近い掲示板を登録する可能性が高い都合上、フォルダプロパティで一覧で参照できる形式のほうが何かと便利かなぁと。

NMID_DATEにおいて、REPLACEを指定しても、上書きが起こらないという仕様に、大きく依存した部分が無いのであれば、REPLACEが有効となるようにしていただけると助かります。おそらくは、発言を編集できる掲示板では、ほぼ同様の形になると思われます（日時で取り込みを判定し、発言の一意性は番号(かKey)で管理し、上書きする）
# 現状の場合、既読位置（日時）を、掲示板プロパティで独自に持てばよいんですが・・・これをすると、既読番号欄がゴミになりますし。

# そもそも、REPLACEしなくても、大きな問題ではない気がしなくも無い・・・（ちまちま削除するのが手間だけど）
-- CMN v0.50dβ --

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

＞発言番号に当たる物は、単に、昇順/降順が保障されないだけで、一意です。

あ、なるほど。
更新すると番号も変わってしまうのかと思ってました。

＞NMID_DATEにおいて、REPLACEを指定しても、上書きが起こらないという仕様に、大きく依存した部分が無いのであれば、REPLACEが有効となるようにしていただけると助かります。おそらくは、発言を編集できる掲示板では、ほぼ同様の形になると思われます（日時で取り込みを判定し、発言の一意性は番号(かKey)で管理し、上書きする）

検討項目に追加しておきます。

DECO

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

＞REPLACE指定で取り込んだ発言が、同じ発言番号（文字列）に対しての上書きとしては動作しません。

あれれ?

私の作ったZOB-Station BBSとTDiaryはどちらもNMID_DATEで新着を識別してまして、ZOBが文字列形式発言番号、TDiaryが数字形式発言番号ですけど…

MES_ATTR_REPLACE + MES_ATTR_NOCHANGEでcmnWriteMessageをかけて、上手く既読のまま上書きできてますよ。

MES_ATTR_REPLACE単体での動作も「上書きされ、なおかつ未読になる」でばっちりです。

Web上の仕様と異なることはわかってましたが、うかつに報告してバグとして修正されると大変たいへん困るので今まで黙っていました(^^ゞ

営々さん、こんにちは。

＞私の作ったZOB-Station BBSとTDiaryはどちらもNMID_DATEで新着を識別してまして、ZOBが文字列形式発言番号、TDiaryが数字形式発言番号ですけど…
＞
＞MES_ATTR_REPLACE + MES_ATTR_NOCHANGEでcmnWriteMessageをかけて、上手く既読のまま上書きできてますよ。
＞
＞MES_ATTR_REPLACE単体での動作も「上書きされ、なおかつ未読になる」でばっちりです。

おろ・・・・ってことは、うぇいくさんの方も本来(?)ならうまくいく筈！？(^o^;)

＞Web上の仕様と異なることはわかってましたが、うかつに報告してバグとして修正されると大変たいへん困るので今まで黙っていました(^^ゞ

ぶひゃ！

DECO

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

遅くなりましたが MES_ATTR_REPLACE の動作を確認しました。
結論としましては、NMID_DATE でも dwMesNumber が MES_ID_NONE 以外であれば動作します。
この場合、「日時＋番号」がキーとなります。

うぇいくさんの場合には「日時」が更新前と更新後で違うということかと思いますが、その場合はキーが違うのでREPLACEできないということになります。

DECO