VIsta 環境以降での SendKey 代替案
DataGridView や DataRepeater にこだわりつつ 時代は Workflow Foundation などと言い続けていたら これからは LogicFlow だろ！ と思い始めてきた 色々浅く広くやっていく古い技術者の Blog VB6 製な AP で Vista 環境以降に限定して起きる問題として、MS-IME の挙動がおかしくなるというのがあるんだよね。勤務先では IME 2007 をやめて ATOK を購入させることで対応させていたけど、根本的な問題は恐らく Sendkey Win32 API を利用しているからという気がする。 自分のPJではSendkeyを利用せずにKeybdEvent API を利用してEnterキーとかの制御をしているんだけど、こっちでは同様の問題は発生していないんだよね。定義はこんなの。 Private Declare Sub KeybdE
Office TANAKA - Excel 2010レビュー「64ビット版VBAでのAPI宣言」
64ビット版のExcel VBAは、Win32のAPI宣言でエラーになります。従来の32ビットアーキテクチャと、64ビットアーキテクチャの違いについては、専門の書籍などを見てもらうとして、要するに、今まで問題のなかったマクロがエラーになるということです。 勘違いしないでくださいね。 新しいExcel 2010すべての話ではありません。 64ビット版Excelに限った現象です。 32ビット版のExcelでは、何も問題ありません。 ちょっと正確な情報ではないのでナニですが、エラーになるAPIもある、と聞きました。てことは、エラーにならないAPIもあるのでしょうか。まさか、すべてのAPIをテストするわけにはいきませんが、私がよく使うAPIでは、ことごとくエラーになりました。 キリがないので、このへんにしておきます。 さて、では64ビット版VBAでWin32APIをコールするには、どうしたらいいの
WindowsフォームでWindowsメッセージを直接処理するには？
連載目次 Windows OSでは、ユーザーからの入力や操作はすべてメッセージ（以下、Windowsメッセージ）として処理される。例えばマウス・カーソルが移動された場合には「WM_MOUSEMOVE」というIDのWindowsメッセージがウィンドウに送られるため、プログラムではユーザーによるマウス・カーソルの移動を知ることができる。 しかし.NETのWindowsフォームでは、たいていの場合、直接Windowsメッセージをプログラムで処理する必要はなく、フォームのメンバであるWndProcメソッドが、受け取ったWindowsメッセージを.NETのイベントに置き換えてくれる*。WM_MOUSEMOVEメッセージがフォームに送られてきたら、フォームでMouseMoveイベントが発生するといった具合だ。実際この場合には、MouseMoveイベントのイベント・ハンドラを記述すれば、マウス移動時の処
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
