ab.com コミュニティ

AB4.1リリースおめでとうございます。
#strictが導入されたので、私も自分のプログラムの不備(変なデータ型に代入していないかとか)をチェックしていました。
そのときに気付いたのが…

#strict
Dim a As Integer,b As Byte
a=&H1234
b=HIBYTE(a)

このとき、警告が発生してしまうということです。

コード: 全て選択

#strict
Dim a As Long,b As Integer
a=&H12345678
b=HIWORD(a)

こちらも然り。
マクロ定義を見れば、ビットシフト＆論理演算のみで行われているので当然といえば当然なのですが、何とかしていただけたら嬉しいです。

これらのマクロはByte/Word/DWordを対象にしていると考えるのが自然だと思います。
だからLong/Integerで警告になる現状で良いのではないでしょうか。

肝心の定数関数の定義のほうがキャストに対応できていませんでしたね…。

コード: 全て選択

Const HIBYTE(w) = (w >> 8) and &HFF
Const LOBYTE(w) = w and &HFF
Const HIWORD(dw) = (dw >> 16) and &HFFFF
Const LOWORD(dw) = dw and &HFFFF

Const MAKEWORD(a,b) = (a and &HFF) or ((b and &HFF)<<8)
Const MAKELONG(a,b) = (a and &HFFFF) or ((b and &HFFFF)<<16)

今までは上記のような定義（function.sbp）でしたが、次回のバージョンアップで下記のものに差し替えようと思います。こうすると、型違いによる警告はでなくなります。

コード: 全て選択

Const HIBYTE(w) = ((w >> 8) and &HFF) As Byte
Const LOBYTE(w) = (w and &HFF) As Byte
Const HIWORD(dw) = ((dw >> 16) and &HFFFF) As Word
Const LOWORD(dw) = (dw and &HFFFF) As Word

Const MAKEWORD(a,b) = ((a and &HFF) or ((b and &HFF)<<8)) As Word
Const MAKELONG(a,b) = ((a and &HFFFF) or ((b and &HFFFF)<<16)) As Long

ありがとうございます。
ついでなので、その他の気になった点を…

1. 下のようなコードでも警告されます(^^;

コード: 全て選択

#strict
Dim a As Integer
a=1

わざわざ 1 As Integer と書くのが本来の書き方なんでしょうか？

2. (RADツール)WM_NOTIFYを処理するとき、lParamからnmHdrにメモリ内容がコピーされますが、memcpyの第2パラメータが型の強制変換とみなされてしまいます(LPARAM→VoidPtrのため)

3. CREATESTRUCTのhInstanceがLong型扱いになっているようで、インスタンスを利用する時に警告されます(^^;; [例: LoadIcon関数など]

4. CreateStatusWindow関数ですが、戻り値はHWND型にしたほうがいいのではないでしょうか… CreateFile関数の戻り値もHANDLE型、CreateDialogの戻り値もHWND型でお願いします(^^;

5. (RADツール)DialogBox関数(プロシージャ？)の内部処理でサブクラス化されるときにAddressOf関数の部分が警告の対象になります。

6. Val関数の内部、TempPtr=i3 (2箇所)が警告になります。

7. Left$関数などの内部処理で、memcpyの第1引数が警告されます。

8. NMLISTVIEW構造体で、.hdr.hwndFromがDWord型になっているために警告が出ます。

9. SendDlgItemMessage関数の第1引数もHWND型にしてください。

以上、AucMonを#strict付きでコンパイルしたときに出てくる内部処理関連の警告です。
自分で定義ファイルをいじって何とかなる部分もありますが、特に2. と 4.のCreateDialog、それに5. については自分ではどうしようもない部分があるもので…。
※ヘタにいじってバグを作っても嫌なので(^^;;;

＞イグトランスさん

コード: 全て選択

#strict
Dim a As DWord,b As Word
a=&H12345678
b=HIWORD(a)

これでも警告になりました。
結局のところ、私がこの件で言いたいのはResizeイベントやMouseMoveイベントを発生させる内部の過程で強制変換が起こるということです(爆

> ＞イグトランスさん
>

コード: 全て選択

#strict
> Dim a As DWord,b As Word
> a=&H12345678
> b=HIWORD(a)

> これでも警告になりました。
> 結局のところ、私がこの件で言いたいのはResizeイベントやMouseMoveイベントを発生させる内部の過程で強制変換が起こるということです(爆

そういうことですか。よく確かめもせず書いてしまい失礼しました。

hira さんが書きました:1. 下のようなコードでも警告されます(^^;
コード: 全て選択
#strict
Dim a As Integer
a=1
わざわざ 1 As Integer と書くのが本来の書き方なんでしょうか？

すみません、AB側のバグです。コンパイラは演算結果がリテラル値であると認識したとき、そのリテラル値の範囲と左辺のデータ型をチェックし、警告するかどうかを判断していますが、その部分のコードに手違いがありました。次回のバージョンアップで修正しますので、今しばらくお待ちください。

hira さんが書きました:2. (RADツール)WM_NOTIFYを処理するとき、lParamからnmHdrにメモリ内容がコピーされますが、memcpyの第2パラメータが型の強制変換とみなされてしまいます(LPARAM→VoidPtrのため)

3. CREATESTRUCTのhInstanceがLong型扱いになっているようで、インスタンスを利用する時に警告されます(^^;; [例: LoadIcon関数など]

4. CreateStatusWindow関数ですが、戻り値はHWND型にしたほうがいいのではないでしょうか… CreateFile関数の戻り値もHANDLE型、CreateDialogの戻り値もHWND型でお願いします(^^;

5. (RADツール)DialogBox関数(プロシージャ？)の内部処理でサブクラス化されるときにAddressOf関数の部分が警告の対象になります。

6. Val関数の内部、TempPtr=i3 (2箇所)が警告になります。

7. Left$関数などの内部処理で、memcpyの第1引数が警告されます。

8. NMLISTVIEW構造体で、.hdr.hwndFromがDWord型になっているために警告が出ます。

9. SendDlgItemMessage関数の第1引数もHWND型にしてください。

詳細なご指摘、ありがとうございます。すべて次回のバージョンアップで修正します。この他にも、ライブラリまで手が回らなかった部分があるかと思いますので、発見次第、ご連絡いただけると助かります。

>この他にも、ライブラリまで手が回らなかった部分があるかと思いますので、発見次第、ご連絡いただけると助かります。

と書いてありましたので、
api_system.sbp内の
Declare Function MultiByteToWideChar Lib "kernel32" (CodePage As DWord, dwFlags As DWord, lpMultiByteStr As BytePtr, cchMultiByte As Long, lpWideCharStr As WordPtr, cchWideChar As Long) As Long
で第5引数(と言う言い方であってるかな・・・)のlpWideCharStr As WordPtrで、ソースによってはWordPtrをStringに書き換えないと動作しないプログラムがあったりします。
検索エンジンで調べてみましたが、ほとんどがStringと書かれていました。
一応報告しておきます。

> で第5引数(と言う言い方であってるかな・・・)のlpWideCharStr As WordPtrで、ソースによってはWordPtrをStringに書き換えないと動作しないプログラムがあったりします。
> 検索エンジンで調べてみましたが、ほとんどがStringと書かれていました。
それはVBではないですか？VBのStringはUnicodeなのでそうするのが逆に正しくなります。

> それはVBではないですか？VBのStringはUnicodeなのでそうするのが逆に正しくなります。
そうなのですか？
それは失礼しました。

ab.com コミュニティ

HIWORD、LOWORD関係

HIWORD、LOWORD関係

Re: HIWORD、LOWORD関係

Re: HIWORD、LOWORD関係