マクロでTimerと同じ動作をさせるには？
解決マクロでTimerコントロールと同じ動作をさせる方法はないでしょうか？
常時監視するシステムを作成したのですが、Timerコントロールを探したのですが、見つかりませんでした。
それと、CPUを100%にしたくないので、Do〜Loop文は使えない状況になっています。
VB.NETで外部操作のアプリを作らない理由はそのソフトがバージョンアップしたときにCOMが対応しなくなってしまうのでは？
という疑問があるため、使用できない状況になっています。
マクロで可能なら教えてください。
何のマクロですかぃ？
SolidWorksのマクロです。
言語はVB6の記述と似ています。
API(SetTimer等)は使えますか？
> SolidWorksのマクロです。
> 言語はVB6の記述と似ています。
確か、SolidWorks も VBA 搭載製品でしたっけか。
SolidWorks は触った事が無いので、具体的な回答はできませんが、
まずは、SetTimer API を試してみてください。
もし、非同期コールバックに対応していないようであれば、
外部コンポーネントに頼る必要があるかも知れません。
その場合は、Microsoft 純正だと ietimer.ocx とか。
高精度な物だとすれば、このあたりとか。
http://ccrp.mvps.org/index.html?controls/ccrptimer6.htm
>GODさん
APIのSetTime関数を使って見ましたが、ハンドルを渡す所で'Me.hWnd'のように記述しましたが、
エラーが発生しました。
hWnd関数自体、用意されていなかったみたいです。
それで、Excelでも試して見ましたが、同じところで同じ現象が発生しました。
>魔界の仮面弁士さん
TimerのDLLファイルで動き出しましたが、問題が発生しました。
現在、環境がないため、Excelの方で確認しましたが、
ファイル→ファイルのエクスポートでfrmファイルで保存した後に一回、閉じて、開いたら、先ほどの参照設定したDLLファイルが
抜けているのですが、なぜでしょうか？
SolidWorksの状態は後で報告します。
> ハンドルを渡す所で'Me.hWnd'のように記述しましたが、
その場合の Me が、何を表しているのかを理解されていますか?
そして、そのクラスには hWnd というメンバがあるか、確認されましたか?
何のウィンドウハンドルを得たいのかによって、その取得方法は異なります。
たとえば Access の場合、Form に hWnd プロパティがあるので、これを利用できます。
フォーム無しで運用する場合には、Application.hWndAccessApp メソッドを利用できます。
Excel の場合、Form に hWnd プロパティ相当の物が無いので、FindWindow API で
ウィンドウハンドルを取得する必要があります。もしくは、Excel 本体の
ウィンドウハンドルを得るために、Application.hWnd プロパティを使うことができます。
# Excel + FindWindow の例はこちら。
# http://www.h3.dion.ne.jp/~sakatsu/Excel_Tips15.htm
私には、SolidWorks の場合の手法についてはわかりませんが、自身の
ウィンドウハンドルを得るための手段は、何か用意されていないのでしょうか?
無いのであれば、FindWindow などで検索する必要があるかも知れません。
> ファイルのエクスポートでfrmファイルで保存した後に
フォームには、参照設定情報が含まれていないためです。
VBの場合はプロジェクトファイル、Excelの場合にはブック側に
参照設定情報が含まれています。
確認した所、魔界の仮面弁士さんが紹介したサイトのDLLファイルを使ってSolidWorksのマクロ上でTimerコントロールと同じ動作が出来ました。
>ファイル→ファイルのエクスポートでfrmファイルで保存した後に一回、閉じて、開いたら、先ほどの参照設定したDLLファイルが
抜けているのですが、なぜでしょうか？
これは解決しましたが、新たな問題が・・・・・・・・・・・
「参照の追加」で追加し、保存した後に閉じてそのマクロファイルとDLLファイル
を一緒に別のディレクトリーに移して、マクロファイルを開き、実行すると、
New(インスタンスの作成)をしている所でエラーが発生してきます。
そして、また、「参照の追加」でDLLを設定すると、エラーがでず、正常に動作します。
別のディレクトリーに移動する前は何度開いてもエラーが発生しないのに・・・・・・・・
原因不明です(T▽T)
ソースは下記のように記述しています。
Private WithEvents Timer1 As ccrpTimer
Dim Ticks As Long
Private Sub CommandButton1_Click()
Set Timer1 = New ccrpTimer
With Timer1
.EventType = TimerPeriodic
.Interval = 1000
.Stats.Frequency = 20
.Enabled = True
Ticks = 0
End With
End Sub
Private Sub CommandButton2_Click()
If Not Timer1 Is Nothing Then
Timer1.Enabled = False
Set Timer1 = Nothing
End If
End Sub
Private Sub Timer1_Timer(ByVal Milliseconds As Long)
Ticks = Ticks + 1
TextBox1.Text = Ticks
End Sub
これで問題がないのに(T▽T)・・・・・・・・
なぜ・・・・・・・・・
「Declareして使うタイプのDLL」と、ActiveX DLL を混同していませんか?
DLLを移動してはだめですよ。
side-by-side などで運用するのなら、アプリと同じフォルダに
DLLをコピーしておく手法もありますが、今回はそうではありませんよね。
> 「参照の追加」でDLLを設定すると、エラーがでず、正常に動作します。
参照設定時に、ActiveX DLLの新しいパスがレジストリに上書きされるためです。
DLLって2つのタイプがあったんですか・・・・・・・・・・・
混同以前にそういうこと知りませんでした。
ということは今回のDLLはActiveX DLLってことですよね。
もし、配布などをするなら、System32フォルダーに送る必要があるってことになるんですか。
Timerと同じ動きが出来たため、解決とします。
>参照設定時に、ActiveX DLLの新しいパスがレジストリに上書きされるためです。
そういうことだったんですね。
アプリ(マクロファイル)と参照しているDLLファイルを同じフォルダー内に移動しても、レジストリにパスが記述されているから、Newのところでエラー起きていたんですね。
勉強になりました。
ありがとうございました。
> DLLって2つのタイプがあったんですか・・・・・・・・・・・
実際には、2タイプどころでは無いですけれどね。(^^;)
参照設定ではなく、コンポーネントの追加画面から指定するタイプもあれば、
アイコン等のリソースが含まれているだけというのもありますし、他にも
.NET専用の DLL とか、Declare と 参照設定の両対応なんてのとか、いろいろと。
> もし、配布などをするなら、System32フォルダーに送る必要があるってことになるんですか。
配布先は、どこのフォルダでも構いませんよ。
Declare して使うタイプの DLL だと、使用時に DLL の位置を示さねば
ならないので、あらかじめ決まった位置に DLL をおいて置く必要が
ありますよね。一般的には、フルパスで指定するのは稀で、
ファイル名だけを指定しますが、その場合は、
1. App.Path
2. CurDir
3. System32
4. System
5. Windows
6. Environ("PATH")
のパスが検索され、最初に見つかった DLL が利用されます。
ですが、ActiveX DLL はそうではありません。あらかじめ定められたパスを
検索にいくのではなく、事前にレジストリに登録しておいたパスを参照しに
行く仕組みになっています。ですから、どこに配置してあっても OK です。
(だからこそ ActiveX DLL は、事前にレジストリ登録が必要になるわけで)
DLLってそんなにタイプがあったなんて知りませんでした。
ActiveX DLLの使い方が分かってきました。
ありがとうございました。
| ツイート |
|