一括表示

WM_COPYDATAについて 投稿者:JG1MOU浜田 

ドキュメントに間違いがあったみたいです。
文字列を送る場合、C言語では最後の0x00が必要なので、文字列の長さ
+1が正解みたいです。
HAMLOG本体では+1してましたが、道の駅Get'sでは+1してませんでした。
たぶん、PASCALやBASICでは大丈夫なのでしょう。
C++でも+1しなくても動くのかもしれませんが、ネット上のコードを
見ていると、strlen("文字列") + 1が多いみたいです。参考まで。

cds.dwData = 1;
lstrcpy(buffs, "JG1MOU"); // コールサイン文字列
cds.cbData = strlen(buffs) + 1; // ※文字列の長さ+1※
cds.lpData = &buffs[0]; // 文字列のポインタ
Hwnd2 = SendMessage(Hwnd1, WM_COPYDATA, (WPARAM)Form1->Handle, (LPARAM)&cds);

2014/12/15(Mon) 19:01:14  [No.640]


Re: WM_COPYDATAについて 投稿者:JA2BQX 太田 

こんばんは。
コマンド30の追加ありがとうございました。順調に動作しています。

> 文字列を送る場合、C言語では最後の0x00が必要なので、文字列の長さ
> +1が正解みたいです。
> たぶん、PASCALやBASICでは大丈夫なのでしょう。

はい、VB6もVB2010の時も単に文字列の長さを指定しています。 勿論全角は半角換算の2ですが。

2014/12/15(Mon) 21:17:15  [No.641]


Re: WM_COPYDATAについて 投稿者:JG1MOU浜田 

> はい、VB6もVB2010の時も単に文字列の長さを指定しています。 勿論全角は半角換算の2ですが。

やはり文字列の長さ+1が正解なのかもしれません。
文字列の長さ+1=バッファの長さ ですから。

構造体の内容を送る場合を考えると、納得です。
cds.cbData = sizeof(STRUCT);

別件ですけど、ちょっと修正しました。
http://hamlog.no.coocan.jp/mou/index.html

2014/12/15(Mon) 21:58:39  [No.642]


Re: WM_COPYDATAについて 投稿者:JA2BQX 太田 

こんにちは。

> 別件ですけど、ちょっと修正しました。
> http://hamlog.no.coocan.jp/mou/index.html

> ・WM_COPYDATA コマンド15で、チェックボックスの状況をRemarks2の次の行で取得。

上記の件、テストし確認しました。
ただ 15 は 115 の単なるタイプミスですね。(済みません、あげあしとりのつもりではありません)

送る時に桁数+1をしてみましたが特に変化は無いようですが今後は桁数+1にします。

2014/12/16(Tue) 10:31:50  [No.643]


Re: WM_COPYDATAについて 投稿者:JG1MOU浜田 

「取得」ではなく「送る」でした。
http://hamlog.no.coocan.jp/mou/index.html

2014/12/16(Tue) 22:08:07  [No.644]


Re: WM_COPYDATAについて 投稿者:JP7CZE 川辺 

> cds.dwData = 1;
> lstrcpy(buffs, "JG1MOU"); // コールサイン文字列
> cds.cbData = strlen(buffs) + 1; // ※文字列の長さ+1※
> cds.lpData = &buffs[0]; // 文字列のポインタ
> Hwnd2 = SendMessage(Hwnd1, WM_COPYDATA, (WPARAM)Form1->Handle, (LPARAM)&cds);

VB6です.戻り値の取得ですが,ちょっと困っています.

Type COPYDATASTRUCT
dwData As Long
cbData As Long
lpData As String * 3927 ' void * のつもり
End Type

(lpData の3927は,やけくその値です...)

Public Function WindowProc(ByVal hwnd As Long, ByVal uMsg As Long, ByVal wParam As
Long, ByVal lParam As Long) As Long
Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (hpvDest As Any,
hpvSource As Any, ByVal cbCopy As Long)

で,

WindowProc 関数の中で,WM_COPYDATAの時に,
  Dim cds As COPYDATASTRUCT
  Dim buf(1 To 255) As Byte
  Call CopyMemory(cds, ByVal lParam, Len(cds))

で受けているのですが,
  cds.dwData と cds.cbData の値は,正しいのですが,なぜか
  cds.lpDataの中身に,先頭に14byteほどのゴミが付いてきます.

なので,cds.cbData の値で cds.lpData の値を取り出しても,
正しい文字列が取れません.
仕方がないので,とりあえず,先頭の14byteを切り取って,
その後で,1byteずつゴミかどうかをチェックしながら,
正しい文字列の次のnull文字までの文字列の切り出しをしているのですが.

CopyMemory の使い方が間違っているのか,
MoveMemory に変えても同じで...ご教示いただければ幸いです.

2014/12/17(Wed) 11:12:07  [No.645]


Re: WM_COPYDATAについて 投稿者:JA2BQX 太田  《URL》  

こんにちは。
最近はVB6は殆ど使わなくなっていますが
状況を再現出来るソースを送っていただければこちらでもテストして見ますが....。
メルアドは私のHPのTopにあります。

2014/12/17(Wed) 11:30:06  [No.646]


Re: WM_COPYDATAについて 投稿者:JP7CZE 川辺 

> こんにちは。
> 最近はVB6は殆ど使わなくなっていますが
> 状況を再現出来るソースを送っていただければこちらでもテストして見ますが....。

太田さん,ありがとうございます.

たくさんあるウィンドウ・ソースの一部分なので,
切り出して新規のウィンドウで作りますので,しばらくお時間下さい.

よろしくお願いします.

2014/12/17(Wed) 18:24:56  [No.647]


Re: WM_COPYDATAについて 投稿者:JA2BQX 太田 

こんばんは。


> たくさんあるウィンドウ・ソースの一部分なので,
> 切り出して新規のウィンドウで作りますので,しばらくお時間下さい.

はい、cmmd = 115 などのTHWからの受け取りの件だと思います。
WindowProc() で取得出来る状態のソースをお願いします。
こちらで動かして受け取ったデータを見てみます。

2014/12/17(Wed) 20:04:37  [No.648]


Re: WM_COPYDATAについて 投稿者:JP7CZE 川辺 

> はい、cmmd = 115 などのTHWからの受け取りの件だと思います。
> WindowProc() で取得出来る状態のソースをお願いします。
> こちらで動かして受け取ったデータを見てみます。

今さっき,検証用のVBソース等を送らさせていただきました.
よろしくご検討いただければ幸いです.

いくつかlpDataの結果を表示させていますが,
一番上はバイナリーダンプデータ
2番目は,&H00 を除くlpData
3番目は,私が強引に取得している本来の(?)テキストデータです.

*他の人には何のことやらわからずに,すみませんm(__)m

2014/12/17(Wed) 20:58:19  [No.649]


Re: WM_COPYDATAについて 投稿者:JP7CZE 川辺 

JA2BQX 太田さん,
さっそくのメールの返答ありがとうございました.

プログラムを拝見させて頂きまして,私の理解不足の点がわかりました.
COPYDATASTRUCT構造体の定義自体が違ってたのですね.
単なる文字列でいいのかと思っていましたが,
アドレスでの受け渡しなのですね.

Type COPYDATASTRUCT_02
dwData As Long
cbData As Long
lpData As Long
End Type

CopyMemory bytReceiveDataBuffer(0), ByVal .lpData, .cbData

で,受け取りをbyte配列にして,bytReceiveDataBuffer(0)で受け取りアドレスの先頭を指定できるというのは,
知りませんでした.
また,Byte配列をVisualBasicの文字列の内部形式であるunicodeに変換する StrConv関数 も知りませんでした.

ということで,ありがとうございました.

2014/12/18(Thu) 20:55:52  [No.650]


Re: WM_COPYDATAについて 投稿者:JA2BQX 太田 

こんばんは。
ソースを送っていただいたので試して見ました。
結論としては修正出来たようです。

> Type COPYDATASTRUCT
> dwData As Long
> cbData As Long
> lpData As String * 3927 ' void * のつもり
> End Type

lpData As String で良く、以下が余分だったかと。
[ * 3927 ' void * のつもり ] <== この部分は余分。

下記で切り出しをしていたのですが lpData As String にすれば
cds.lpData に THW からの情報が普通に取れていました。

For i = 1 To 3927
a = Mid(cds.lpData, i, 1)
      ...以下省略

2014/12/18(Thu) 21:12:09  [No.651]


Re: WM_COPYDATAについて 投稿者:JG1MOU浜田 

VBの場合の lpData は、Stringでいいのでしょうか。
Longがいいのでしょうか。

私が書いたドキュメントでは、
 lpData As String ' void * のつもり
としましたが、本家では Long になってました。

http://support.microsoft.com/kb/176058/ja

ポインタが素直に使えない言語体系だと考えると、Longでアドレスを
直接渡した方がいいのかな、と考えました。

BASICはよくわからない・・・

2014/12/18(Thu) 21:51:03  [No.652]


Re: WM_COPYDATAについて 投稿者:JA2BQX 太田 

浜田さん、こんばんは。
私はWindowProcは理解して使っているでは無くて、他からのコピーで
動かしている状態。


> VBの場合の lpData は、Stringでいいのでしょうか。
> Longがいいのでしょうか。

私のVB6のソースでは Long を使っています。
今回の川辺さんのソースでは lpData As String * 3927 となっていた
lpData As String に変えたらTHWから取れましたので。

VB2010では lpData As String で使っています。

.....動作などを理解しての使用では無いので動けば良い...と言うレベルです、Hi。

2014/12/18(Thu) 22:14:05  [No.653]


Re: WM_COPYDATAについて 投稿者:JP7CZE 川辺 

> 今回の川辺さんのソースでは lpData As String * 3927 となっていた
> lpData As String に変えたらTHWから取れましたので。

私が定義していたのが,

Type COPYDATASTRUCT
dwData As Long
cbData As Long
lpData As String * 3927 ' void * のつもり
End Type

です(コメントは悪銭苦闘の残骸ですね...Hamadaさんのオリジナルの消し忘れ).

あちこちのページを参考に,色々弄くってみて,
期待する結果が出るように,力ずくで弄くり倒した結果,
なんとかちゃんと結果は得られたか,と思っていたのですが,
Hamadaさんからダメだしをくらいまして(^^;

Dim cds As COPYDATASTRUCT

Call CopyMemory(cds, ByVal lParam, Len(cds))

で取得していたのですが,問題は cds.lpDataの中身.

THWからはcbDataの長さの文字列が帰ってきて最後はOx00が入ってくることはわかっていたのですが,うまく取れないので,戻り値をダンプしてみたら,14バイトの最後が0で終わるデータが本来のlpDataの前にくっついていることがわかりました.

その後は,VBの場合,文字列がunicode で2byteですが,(cbData-1)+1 で切り出してもなぜかうまく取り出せませんでした???

なので強引に先頭の14byteを除去して,0x00までを取得するようにしたわけです.

変数等の内部構造も何も知らずに,Web上の先人たちの情報と結果だけを頼りに弄くっているだけなので....

それでも,みなさんのおかげで,正しくWM_COPYDATA の結果が取れるようになりました.

ほんとにありがとうございました.

2014/12/19(Fri) 00:27:43  [No.654]