- ベストアンサー
エクセルVBAでNumLockキーの状態を確認する
- エクセルVBAでNumLockキーの状態を確認できる方法
- 64ビットのWindowsでのエクセルVBAでNumLockキーの状態を確認する際の問題点と解決策について
- エクセルVBAでNumLockキーの状態を確認し、必要に応じてオン・オフを切り替える方法
- みんなの回答 （6）
- 専門家の回答
質問者が選んだベストアンサー
こんにちは、＃２＃４です。 迷ったのですけれど、 このスレ読んで誤解する人いると悲しいので 指摘しておきますね。 > Windows7には対応していないようなので これは間違いです。 ＃３さんは、【64ビット版 Windows7 & ３２ビット版 Office】環境で"問題なく動く"と仰っています。 ＃１さんも同様のことを仰っているのだと思います。 ＃２＃４で私は【64ビット版 Windows7 & ６４ビット版 Office】環境で Win32APIを使えるようにするにはどうしたらいいか書いています。 今回３つのサンプルコードが紹介されていますが （順に） ↓最初のご質問 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1352157463 ↓＃３さんご紹介のもの http://www.accessclub.jp/samplefile/samplefile_214.htm ↓＃４へのレスでkichi4182さんがあらたにご提示なさったもの http://okwave.jp/qa/q5156553.html （＃３と＃４は、Functionで書くかSubで書くかの違いだけで まったく同じものですから、実際には２種類なのですけれど） 今回のこのスレッド全体としては 【64ビット版 Windows7 & ３２ビット版 Office】環境 【64ビット版 Windows7 & ６４ビット版 Office】環境 どのサンプルコードも、 "問題なく機能することを確認した" という話になっているのです。 【Windows7】 はこの際関係なくて（問題ではなくて）、 【６４ビット版 Office】 では、 そのままの記述ではAPIが通らないから 実際に動く様にするために どうしたらいいか、という話を書いているのです。 今回紹介された３つのサンプルコード、のいすれも、ちゃんと動きます。 Excel でも Access でも ユーザーフォームモジュール でも 勿論 標準モジュールでも 何度やっても動きます。 いくつかのイベントトリガーで NUMLOCK がかかることを実際に試してもいます。 今回紹介された３つのサンプルコードの場合、 【６４ビット版 Office】 で動くようにするには 単純に １■ リンク先のサンプルコードを丸ごとそのままコピペして（コンパイルエラーは[OK]で無視して） ２■ Ctrl + H で置換ダイアログを表示して "Declare" を "Declare PtrSafe" に モジュールごと、すべて置換する これだけで、最低限(*)の動作確認はできます。 （例えば、プロシージャにカーソルを当てて F5 キーを押すだけ） 今回紹介された３つのサンプルコード、のいすれも、ちゃんと動きます。 動作を確認出来ないということのようなので、あらためて単純化して書いてみました。 (*)推奨された手順としては、続いて、Long型の置換が必要だということは＃４で触れています。 要は 【Office 2010 ６４ビット版】だけは、API の書き方が他のバージョンとは違うってだけの話 ですので、ご理解いただきたいです。
その他の回答 (5)
- nicotinism
- ベストアンサー率70% (1019/1452)
さすがにOfficeの64bitバージョンをインストールして 検証する元気はありません。 MS社自身、32bit バージョンの使用を推奨しています。 開発目的ならともかく、実務に使うのなら周囲の環境が整っている32bit かと。 64 ビット版の Office 2010 http://technet.microsoft.com/ja-jp/library/ee681792.aspx
- cj_mover
- ベストアンサー率76% (292/381)
＃２です。 Office 2010 バージョン：14.0.6123.5001 (64ビット) （Win7・64ビット） ↑この環境では、 PtrSafe 抜きで正しいDeclare文をタイプし終えてキャレットを動か（Enter）した瞬間にコンパイルエラーでした。 回答No.3 nicotinism さんご紹介の「強制的にNumLockキーをオンにするプロシージャ」 も、Declaration 宣言部に修正（というより対策？）を加えた上で、動作を確認しましたので、 せっかくなので、対策後の記述を載せておきます。 ' ' =========================以下、筆者加筆によるもの 'API declarations: Private Declare PtrSafe Function GetVersionEx Lib "kernel32" _ Alias "GetVersionExA" (lpVersionInformation As OSVERSIONINFO) As LongPtr Private Declare PtrSafe Sub keybd_event Lib "user32" (ByVal bVk As Byte, ByVal bScan As Byte, _ ByVal dwFlags As LongPtr, ByVal dwExtraInfo As LongPtr) Private Declare PtrSafe Function GetKeyboardState Lib "user32" (pbKeyState As Byte) As LongPtr Private Declare PtrSafe Function SetKeyboardState Lib "user32" (lppbKeyState As Byte) As LongPtr ' ' 以上============================================= （１） Declare → Declare PtrSafe ４カ所置換 （２） Long → LongPtr ５か所置換 手元の環境では（１）は必須のようですが、（２）はそのままでも動くようです。一応ヘルプに従ったつもりです。 ヘルプを読んだ私の解釈では、2010/VBA7 環境では 32ビット/64ビット 共通で動く記述のようですが 32ビット環境での動作はこちらで確認していません。 大事な話が後になりましたが、 > どうやら私のWindows が64ビットだからのようです。 というのを勝手に拡大解釈して、Office も2010、64ビット、、、 だとすると、話が理解しやすい、、、という憶測を前提にレスをしています。 違っていたら（他勘違いなどあれば）ただのお騒がせ、その時はすみません。 でも、なんかの役に立つかも知れませんので、ヘルプの引用も、最後に載せておきます。 ==============以下引用 LongPtr - VBA に可変の型エイリアス LongPtr が追加されました。LongPtr が解決された後の実際のデータ型は、コードが実行される Office のバージョンによって異なります。LongPtr は 32 ビット版 Office の場合は Long、64 ビット版 Office の場合は LongLong に解決されます。ポインターおよびハンドルには LongPtr 型を使用してください。 LongLong - LongLong データ型は 64 ビットの符号付き整数型で、64 ビット版の Office でのみ使用できます。64 ビットの整数には LongLong 型を使用してください。LongLong (64 ビット プラットフォーム上の LongPtr も含む) をより小さいサイズの整数型に明示的に割り当てるには、変換関数を使用する必要があります。LongLong をより小さいサイズの整数型に暗黙的に変換することはできません。 PtrSafe - PtrSafe は、Declare ステートメントを 64 ビット版の Office で実行しても安全であることを示すキーワードです。 コードを 64 ビット版 Office で実行する場合は、すべての Declare ステートメントに PtrSafe キーワードを含めることが必須となりました。PtrSafe キーワードを単に Declare ステートメントに追加しただけでは、その Declare ステートメントの実行対象が 64 ビット環境であると指定したにすぎません。そのうえで、ステートメント内のデータ型 (戻り値やパラメーターなど) のうち 64 ビット値を格納する必要があるものをすべて、64 ビット値を格納できるように修正する必要があります。 以上引用============== それでは失礼します。
お礼
ありがとうございます。 とりあえず、対象セルを選んだ時にMsgBoxで注意を促すようにして時間稼ぎをすることにしました。 http://okwave.jp/qa/q5156553.html 上記を参考にして組んでみましたが、Windows7には対応していないようなので、７に対応させることを考えてみたいと思います。 しかし、よく分かっていないので、あきらめようかとも思っています。 もうしばらく粘ってみますが。。。。
補足
すみません。書き忘れておりましたが、EXCEL(Office 2010)も64ビット版です。 あと、ユーザーフォームは作っていないので、すべて標準モジュールでの話です。
- nicotinism
- ベストアンサー率70% (1019/1452)
質問者さんが見つけられたページのコードで問題なく動きましたけどね？ 当方 Windows7 64bit & Office 2010 32bit です。 NumLock をOn にするのは少し面倒です。 下記サイトのコードは標準モジュール上で 丸コピペで機能するのをExcel上で確認しています。 http://www.accessclub.jp/samplefile/samplefile_214.htm ※ Option Compare Database はAccessでの話なので削除 Option Explicit は重複して宣言しないように
補足
すみません。書き忘れておりましたが、EXCEL(Office 2010)も64ビット版です。 あと、ユーザーフォームは作っていないので、すべて標準モジュールでの話です。
- cj_mover
- ベストアンサー率76% (292/381)
Private Declare PtrSafe Sub GetKeyboardState Lib "user32" (pbKeyState As Byte) ですね。 PtrSafe をＶＢＡのヘルプで検索して、６４Bit版での32APIの扱い方、一度調べておいた方がよいかと。
お礼
ありがとうございます。勉強します。
- foomufoomu
- ベストアンサー率36% (1018/2761)
64ビットOSであることは、関係ありません。EXCEが32ビットソフトなので、EXCEL内のマクロも32ビット互換モードで動いています。むしろ64ビットのAPI呼び出しなどを使うと動かなくなるはずです。 どんなエラーが出ているのですか？ その内容によって、それ相応の対応が必要です。 API呼び出しは、Declare文が必要なのですが、書いてありますか？ フォームモジュールでなく、標準モジュールに書いてみるとどうなりますか？ （参考） http://www.excellenceweb.net/vba/api/what_windows_api.html
補足
すみません、エラー内容です。 『このプロジェクトのコードは、64ビットシステムで使用するために更新する必要があります。Declareステートメントの確認および更新を行い、次にDeclareステートメントにPtrSafe属性を設定してください。』 よろしくお願いします。
お礼
何度もありがとうございます。 私が > Windows7には対応していないようなので と書いたのは、 http://support.microsoft.com/kb/177674/ja の詳細にWindows７が書かれていないのを見て、そう思ってしまいました。誤解させてしまったようで、大変申し訳ありません。 今回は 取りあえず注意喚起のＭｓｇｂｏｘを使い、少しずつでも勉強しながら対応していこうと思います。 ありがとうございました。