C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[12]: ForegroundLockTimeoutの取得

(過去ログ 107 を表示中)

[トピック内 28 記事 (1 - 20 表示)]　 << 0 | 1 >>

■63230 / inTopicNo.1)

　ForegroundLockTimeoutの取得

▼■

□投稿者/ 魔界の仮面弁士 (14回)-(2012/08/07(Tue) 23:32:29)

分類:[.NET 全般]　

久しぶりに質問側に回ります。


Windows 7 環境において、起動したアプリが画面手前に表示されずに
別アプリの後ろで起動されてしまう(ことがある)という現象が発生したため、
KB886217 ( http://support.microsoft.com/kb/886217/ja ) 等で解説されている、
アプリフォーカスの切り替えタイムアウト設定を変更しようとしています。

【HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout】


上記レジストリ修正を行う事で、問題を回避できることを確認できたのですが、
レジストリを事前修正する方式だと、他のアプリに与える影響も大きいとの判断から、
今回は、アプリからの「一時的な設定変更」にて対処することを検討しています。


具体的には下記の手順です。

  // 現在の設定を保持しておく
  SystemParametersInfo(SPI_GETFOREGROUNDLOCKTIMEOUT, 0, &oldValue, 0);
  // 同設定を 0ミリ秒に書き換える
  SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, 0, 0);
  //
  // …アプリの切り替え処理を実施…
  //
  // 元の状態に復元する
  SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, oldValue, 0);

しかし何故か、SPI_GETFOREGROUNDLOCKTIMEOUT から値を得られない状況です。

# 実際の運用では、これに AttachThreadInput / AllowSetForegroundWindow 等を
# 加えたうえで、BringWindowToTop か SetForegroundWindow を呼ぶ予定です。



検証に使ったコードは下記のとおりです。旧VB、VB.NET、C# の 3 実装で検証しています。
(3 つも掲載すると読みにくいので、別サイトにコードをアップしています)


[VB6 / VBA7]　…　このコードは期待動作しています。
http://www.vb-user.net/junk/replySamples/2012.08.07.22.27/VBA.txt

[VB2010 on .NET 2.0]　…　NG。動作しません。
http://www.vb-user.net/junk/replySamples/2012.08.07.22.27/VB10.txt

[C#2010 on .NET 2.0]　…　NG。動作しません。
http://www.vb-user.net/junk/replySamples/2012.08.07.22.27/CSharp4.txt


VB6 では、SPI_GETFOREGROUNDLOCKTIMEOUT から値を得ることができるのですが、
何故か .NET で再実装してみると、値を得られないという状況に陥っています。

これはコードに問題があるのでしょうか、それとも権限等の不足でしょうか?


------------

・掲載したコード中、☆印の行が GET 操作、★印の行は SET 操作です。
・想定する動作環境は 32bit OS ですが、念のため 64bit 環境でも検証しています。


【VB6 / VBA 版】
・VB6 や Excel 2010 等からは、このコードにて、期待する値が拾えているようです。
・☆0 を実行すると、初回は実行環境ごとの初期値を返します。(20000ミリ秒あるいは0ミリ秒など)
・★1 を実行すると、☆0が「20001」を返すようになります。レジストリの値も「20001」となります。
・★2 を実行すると、☆0が「&H13579」を返すようになります。(レジストリは変化せず)


【VB.NET 版】
・値が拾えません。SPI_GETFOREGROUNDLOCKTIMEOUT が、常にゼロを返してきます。
・☆A を実行した場合、常に値 0 が返されます。
・☆B の手法でも、やはり結果は 0 となります。p の値は変化せず、p が指す先が 0 となります。
・★C を実行すると、レジストリが「20002」に書き換わりますが、☆A、☆B は 0 のままです。
・★D を実行しても、レジストリに影響は与えません。☆A、☆B も 0 のままです。


【C# 版】
・VB 版と同様、GET 操作が期待動作しません。
・☆ア は、VB 版の ☆A と同じです。やはり結果は 0 固定です。
・☆イ は、VB 版の ☆B と同じです。先頭32bit分が 0x00000000 で上書きされてきます。
・☆ウ は、unsafe コードを用いた実装です。これも 0 しか返しません。
・★エ は、VB 版の★Cと同じです。☆ア、☆イ、☆ウ は 0 のままですが、
　少なくともレジストリは「20003」に書き換わります。
・★オ を実行してもレジストリは不変、☆ア～☆ウ の結果も変わりませんでした。

引用返信 編集キー/

■63231 / inTopicNo.2)

　Re[1]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ シリウス (1回)-(2012/08/08(Wed) 01:23:22)

2012/08/08(Wed) 01:28:19 編集(投稿者)

適当にググっただけですけど、

SystemParametersInfoGet() とか SystemParametersInfoSet() ?

すみません、上記は違うっぽいですね。

どっちかって言うとUACの関係っぽい？Windows7だと。
EXEを管理者権限で実行して値が取得できるならマニフェストファイルの作成で対応できそうな？

引用返信 編集キー/

■63232 / inTopicNo.3)

　Re[1]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ shu (18回)-(2012/08/08(Wed) 08:10:15)

■No63230 (魔界の仮面弁士さん) に返信

ぱっと見で予想ですが、Byval IntPtr定義で☆Bとかどうですか？

引用返信 編集キー/

■63238 / inTopicNo.4)

　Re[2]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ オショウ (3回)-(2012/08/08(Wed) 09:53:23)

全てのケースを動作確認してみました。

確かに.NET系では、取得できず『0』が返ってきます。
摩訶不思議です。

まだ確認していない方法として、C++ CLIでAPIを直に呼び出すラッパーDLL
を作って.NET側から呼び出すとどうなるか・・・

※　因みに、IntPtrでもダメでした。
　　VB6的に言うと、ANYで宣言される引数の部分が、何故正しく動作しない
　　のか？と言うことですネ！

以上。ご報告まで

引用返信 編集キー/

■63241 / inTopicNo.5)

　Re[3]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ shu (21回)-(2012/08/08(Wed) 10:41:27)

> ByRef pvParam As UInteger
ByVal pvParam As UInteger
にして

        SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0UI, 100I, 0UI)
        Dim value32 As Integer = 3456I
        Dim p1 As IntPtr = Marshal.AllocHGlobal(Marshal.SizeOf(0))
        Marshal.WriteInt32(p1, value32)
        SystemParametersInfo(SPI_GETFOREGROUNDLOCKTIMEOUT, 0UI, p1, 0UI)
        value32 = Marshal.ReadInt32(p1)
        Marshal.FreeHGlobal(p1)
        Console.WriteLine(value32)

これだと最後のvalue32には100が設定されますが、駄目でしょうか？

引用返信 編集キー/

■63242 / inTopicNo.6)

　Re[2]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ 魔界の仮面弁士 (15回)-(2012/08/08(Wed) 10:47:27)

■No63231 (シリウスさん) に返信
> SystemParametersInfoGet() とか SystemParametersInfoSet() ?
> すみません、上記は違うっぽいですね。
API が無理なら、マネージコードとして用意されていないかと探してみたのですが見つからず。

SystemInformation クラスには、SystemParametersInfo API や GetSystemMetrics API で
得られる値が集約されているのですが、ForegroundLockTimeout は無いみたいなんですよね…。

> どっちかって言うとUACの関係っぽい？Windows7だと。
> EXEを管理者権限で実行して値が取得できるならマニフェストファイルの作成で対応できそうな？

UAC 関連かも疑ったのですが、それだと、VB6 や Excel2010 VBA7 で
設定値を取得できる点が説明できないのです。

念のため、管理者モードを強制させるために、VB.NET アプに
　<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
な manifest も適用してみたのですが、結果は変わりませんでした。

また、今回予定している運用の場合、管理者モードを強制するのは少々都合が悪いので、
requestedExecutionLevel の変更は行わないものとして検討しています。

■No63232 (shu さん) に返信
> ぱっと見で予想ですが、Byval IntPtr定義で☆Bとかどうですか？
☆B は確かに ByVal IntPtr 定義にしていますが、先に書いた通り
>> ・☆B の手法でも、やはり結果は 0 となります。p の値は変化せず、p が指す先が 0 となります。
という結果になってしまいます。32bit分のゼロ ( &H00000000 ) が書き込まれるのみです。

本当に ForegroundLockTimeout が 0ミリ秒にセットされているなら、
0 が返されるというのも分かるのですが、SPI_SETFOREGROUNDLOCKTIMEOUT で
セットした結果が得られないので、首を傾げています。

ForegroundLockTimeout の SET 操作が失敗して、0 固定になっているのか、
それとも GET 操作が失敗しているのか…。

一応、VBA版★1 を実行するとレジストリに「20001」と書き込まれ、さらには
VB.NET 版★C を実行すると、レジストリに「20002」が書き込まれることから、
値のセット作業自体は正しく行われているように思います。
(試しに、値の代わりに参照を渡してみたところ、値では無くアドレス値が書き込まれました)

SET 操作については、稀に、SystemParametersInfo が FALSE を返すことがありましたが、
ほとんどの場合において、GET/SET いずれも戻り値 TRUE を返しますし、実際、
Excel VBA7 でセットした値を VB6 から取得するといったこともできているようです。

しかし、.NET から SET した値を VBA から GET することは出来ていませんし、その逆の
.NET での GET に関しては、相変わらず常に値 0 しか得られないという状況です。

書き込み時に、fWinIni := SPIF_UPDATEINIFILE Or SPIF_SENDWININICHANGE を指定すれば
.NET で書き込んだ値を VBA 側でも受け取れるかと予想しましたが、残念ながら
☆0 には通知されません(VBA側で前回セットした値が得られるだけです)。

引用返信 編集キー/

■63244 / inTopicNo.7)

　Re[4]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ 魔界の仮面弁士 (16回)-(2012/08/08(Wed) 10:55:40)

■No63241 (shu さん) に返信
> ByVal pvParam As UInteger
> SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0UI, 100I, 0UI)
> SystemParametersInfo(SPI_GETFOREGROUNDLOCKTIMEOUT, 0UI, p1, 0UI)
> これだと最後のvalue32には100が設定されますが、駄目でしょうか？

残念ながら当方環境では、そのコードでも 0 が返されてしまいました。

GET/SET いずれも、SystemParametersInfo の戻り値は TRUE です。

引用返信 編集キー/

■63246 / inTopicNo.8)

　Re[5]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ shu (22回)-(2012/08/08(Wed) 11:37:20)

■No63244 (魔界の仮面弁士さん) に返信
> ■No63241 (shu さん) に返信
>> ByVal pvParam As UInteger
>>SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0UI, 100I, 0UI)
>>SystemParametersInfo(SPI_GETFOREGROUNDLOCKTIMEOUT, 0UI, p1, 0UI)
>>これだと最後のvalue32には100が設定されますが、駄目でしょうか？
>
> 残念ながら当方環境では、そのコードでも 0 が返されてしまいました。
>
> GET/SET いずれも、SystemParametersInfo の戻り値は TRUE です。
ステップ実行をしてみたところこちらでも0になりました。
Console.WriteLineまで流した場合はうまくいきます。
統合環境がActiveなためでしょうか。はずしていたらすみません。

引用返信 編集キー/

■63247 / inTopicNo.9)

　Re[3]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ 魔界の仮面弁士 (17回)-(2012/08/08(Wed) 11:47:16)

■No63238 (オショウさん) に返信
> 全てのケースを動作確認してみました。
ありがとうございます。

> まだ確認していない方法として、C++ CLIでAPIを直に呼び出すラッパーDLL
> を作って.NET側から呼び出すとどうなるか・・・
済みません…C++/CLI で DLL を書けるだけの知識がなかったりします。

最悪、VB6 で実装することも検討しますが、さすがにレガシーVBは卒業したいところ。
(一応、Win8RP にも MSVBVM60.DLL が入っているようでしたが)

> 　　VB6的に言うと、ANYで宣言される引数の部分が、何故正しく動作しない
> 　　のか？と言うことですネ！
そんなところです。

同じ引数で、LPDWORD 受け取りだったり、DWORD 渡しだったりするので、面倒なのですよね。
API 宣言では LPVOID なので、理論的には ByVal IntPtr で GET/SET 共に対処できそうなのですが。

よく分からないのが、Win64 環境での動作。

HKCU\Control Panel\Desktop\ForegroundLockTimeout が DWORD(32bit) であることから、
64bit 環境でも、SETするべき値は 32bit だと思うのですが、この場合の SET 時は
ByVal pvParam As IntPtr あるいは ByVal pvParam As Int64 となるのか、それとも
No63241 の shu さん案のように、ByVal pvParam As UInt32/Int32 とすべきなのか…。

個人的には、pvParam の宣言は
　OK　:　ByVal IntPtr
　OK　:　ByRef Int32/UInt32
　OK　:　ByRef Int64/UInt64
　NG　:　ByVal Int32/UInt32
になるのだと予想していますけれどね。

> ※　因みに、IntPtrでもダメでした。
先日、C# のイミディエイトウィンドウにて IntPtr のおかしな動作(※)を
発見したので、VB と C# を含め、ref/out/void* 等、いろいろな書き方を試しています。

(※) C# のイミディエイトにて、下記がエラーになるという問題。
「? IntPtr.Zero.ToInt32()」
「? IntPtr.Zero.ToInt64()」
「? IntPtr.Zero.ToString("X8")」

引用返信 編集キー/

■63250 / inTopicNo.10)

　Re[3]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ shu (24回)-(2012/08/08(Wed) 13:47:14)

■No63242 (魔界の仮面弁士さん) に返信

http://d.hatena.ne.jp/HowHigh/20060913/p
のコードによるとAttachThreadInputでウィンドウを作成したスレッドへの
アタッチを行っているので関係ありそうな感じです。

引用返信 編集キー/

■63253 / inTopicNo.11)

　Re[4]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ ?V???E?X (1回)-(2012/08/08(Wed) 14:54:21)

■No63250 (shu さん) に返信
> ■No63242 (魔界の仮面弁士さん) に返信
>
> http://d.hatena.ne.jp/HowHigh/20060913/p
> のコードによるとAttachThreadInputでウィンドウを作成したスレッドへの
> アタッチを行っているので関係ありそうな感じです。
>

http://hpcgi1.nifty.com/MADIA/VBBBS2/wwwlng.cgi?print+200402/04020031.txt

魔界の仮面弁士さんご本人の以前のレスですが、上記の手順が必要そうです？

今回の現象と関係あるかはわかりませんが、

http://d.hatena.ne.jp/NyaRuRu/20080303/p1
http://d.hatena.ne.jp/firewood/mobile?date=20080304

こんな話もあるようです。

引用返信 編集キー/

■63257 / inTopicNo.12)

　Re[4]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ 渋木宏明 (5回)-(2012/08/08(Wed) 15:52:23)

> 同じ引数で、LPDWORD 受け取りだったり、DWORD 渡しだったりするので、面倒なのですよね。
> API 宣言では LPVOID なので、理論的には ByVal IntPtr で GET/SET 共に対処できそうなのですが。
>
>
> よく分からないのが、Win64 環境での動作。
>
> HKCU\Control Panel\Desktop\ForegroundLockTimeout が DWORD(32bit) であることから、
> 64bit 環境でも、SETするべき値は 32bit だと思うのですが、この場合の SET 時は
> ByVal pvParam As IntPtr あるいは ByVal pvParam As Int64 となるのか、それとも
> No63241 の shu さん案のように、ByVal pvParam As UInt32/Int32 とすべきなのか…。

ネイティブの API 宣言が尊重されるべきです。

pvParam の型である LPVOID は、32bit 実行環境では 32bit 長のアドレス値、64bit 実行環境では 64bit 長のアドレス値を表します。

例) Hoge(IntPtr pvParam);

uiAction 引数の値による読み替えで 32bit 整数値を渡す場合は、32bit 実行環境では 32bit 整数値をそのまま、64bit 実行環境では 64bit 整数値を与えるべきです。(32bit/64bit 実行環境で P/Invoke の宣言が異なります）

例) Hoge(uint pvParam), Hoge(ulong pvParam);

また、32bit 整数値を受け取る場合、32bit 実行環境では 32bit 整数値が配置されたメモリアドレスを表す 32bit のアドレス値を、64bit 実行環境では 32bit 整数値が配置されたメモリアドレスを表す 64bit 値を指定するべきです。

unsafe コンテキストを使わずに、uint 型の変数を ref や out で修飾する場合、32bit/64bit 実行環境で P/Invoke の宣言を書き分ける必要はありません。

例) Hoge(ref uint pvParam), Hoge(out uint pvParam);

引用返信 編集キー/

■63258 / inTopicNo.13)

　Re[5]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ 魔界の仮面弁士 (18回)-(2012/08/08(Wed) 15:56:52)

■No63253 (?V???E?X さん) に返信
…Cookie 腐敗?

> 魔界の仮面弁士さんご本人の以前のレスですが、上記の手順が必要そうです？
実の所、当初のコードではそれに近い手順で記述されていたりします。
一番最初に書いたコードは、下記のコンソールアプリです。(変数宣言等は省きます)

activeWindow = GetForegroundWindow();
dwForegroundThread = GetWindowThreadProcessId(activeWindow, out dwProcessId);
// dwTargetThread = GetWindowThreadProcessId(handle, out dwProcessId);
dwTargetThread = GetCurrentThreadId();

if (dwTargetThread == dwCurrentThread) {
ret = SetForegroundWindow(handle);
} else {
ret = AttachThreadInput(dwCurrentThread, dwForegroundThread, true);
//ret = AllowSetForegroundWindow(ASFW_ANY);
ret = AllowSetForegroundWindow(dwTargetThread);
ret = SystemParametersInfo(SPI_GETFOREGROUNDLOCKTIMEOUT, 0, out sp_timeout, 0); // ★
ret = SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, IntPtr.Zero, 0);
//ret = SetForegroundWindow(handle);
ret = BringWindowToTop(handle);
ret = SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, (IntPtr)sp_timeout, 0);
ret = AttachThreadInput(dwCurrentThread, dwForegroundThread, false);
}

IntPtr 変数『handle』が、手前に表示させたいアプリのHWNDです。
この HWND は、コマンドライン引数経由で C# に渡されています。

そしてこの C# アプリの呼び出し元は wsf 上の VBScript。
WshShell.Run 経由で C# アプリを呼び出し、コマンドライン引数に
Excel.Application オブジェクトの Hwnd プロパティの値を渡しています。

また、上記は Visual Studio 上でのステップ実行等では無く、
Releaseビルドの exe を、直接 VBScript から起動させることで
動作検証を行っています。

…ところが動作ログを確認すると、何故か ★ の部分が固定値 0x00000000 で
返されている事がわかりました(そのため、設定が復元できずに 0 のままになってしまう)。

そこで、SystemParametersInfo API の呼び出し部分のみを切り出し、
さらに他言語(VB6/VB.NET)も担ぎ出して検証調査を行っている状況です。

> http://d.hatena.ne.jp/NyaRuRu/20080303/p1
> http://d.hatena.ne.jp/firewood/mobile?date=20080304
> こんな話もあるようです。
おぉ、これは読んだことがなかったです。ありがとうございます。

しかし ForegroundLockTimeout の場合、単純な (LP)DWORD のやりとりなので
構造体のサイズ問題は起きない気がするのですよね…。

引用返信 編集キー/

■63260 / inTopicNo.14)

　Re[5]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ 魔界の仮面弁士 (19回)-(2012/08/08(Wed) 16:08:59)

■No63257 (渋木宏明さん) に返信
> ネイティブの API 宣言が尊重されるべきです。
私の認識と同じなのでほっとしました。

> また、32bit 整数値を受け取る場合、32bit 実行環境では 32bit 整数値が配置されたメモリアドレスを表す
> 32bit のアドレス値を、64bit 実行環境では 32bit 整数値が配置されたメモリアドレスを表す 64bit 値を指定するべきです。
この場合、64bit 環境で受け取った 64bit整数値が、UInt32 の範囲内(0x00000000u ～ 0xffffffffu)に収まっているのか、
それとも、ゴミが含まれるのでマスクあるいはシフトして 64bit 変数から 32bit 部分を切り出す必要があるのかは
分かりませんが、いずれにせよ API 宣言については ByVal IntPtr (あるいは ByRef 整数型)になるということですね。

> unsafe コンテキストを使わずに、uint 型の変数を ref や out で修飾する場合、
> 32bit/64bit 実行環境で P/Invoke の宣言を書き分ける必要はありません。
> 例) Hoge(ref uint pvParam), Hoge(out uint pvParam);
逆に言うと、unsafe コンテキストの場合は ref/out の際に書き分ける必要があるということでしょうか?

引用返信 編集キー/

■63261 / inTopicNo.15)

　Re[6]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ 渋木宏明 (6回)-(2012/08/08(Wed) 16:09:00)

> ret = SystemParametersInfo(SPI_GETFOREGROUNDLOCKTIMEOUT, 0, out sp_timeout, 0); // ★

> …ところが動作ログを確認すると、何故か ★ の部分が固定値 0x00000000 で
> 返されている事がわかりました(そのため、設定が復元できずに 0 のままになってしまう)。

C# で検証コード書いてみましたが、0 しか取れないですね。
pvParam に Marshall.AllocCoTaskMem() で取得したメモリアドレスを渡しても、値がセットされませんでした。

> しかし ForegroundLockTimeout の場合、単純な (LP)DWORD のやりとりなので
> 構造体のサイズ問題は起きない気がするのですよね…。

同感。

引用返信 編集キー/

■63262 / inTopicNo.16)

　Re[7]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ 渋木宏明 (7回)-(2012/08/08(Wed) 16:36:43)

> C# で検証コード書いてみましたが、0 しか取れないですね。

C++/CLI でも同じ挙動。
CLR がなんかやってるのかな？

引用返信 編集キー/

■63263 / inTopicNo.17)

　Re[6]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ シリウス (2回)-(2012/08/08(Wed) 17:10:57)

■No63258 (魔界の仮面弁士さん) に返信
> ■No63253 (?V???E?X さん) に返信
> …Cookie 腐敗?
>
すみません、名前入れなおさないとダメだったっぽいです。

これかなぁ？

http://go4answers.webhost4life.com/Example/issue-foregroundlocktimeout-175029.aspx

手元に確認できる環境がなくて的外れだったらごめんなさい。

引用返信 編集キー/

■63268 / inTopicNo.18)

　Re[6]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ shu (27回)-(2012/08/08(Wed) 23:03:14)

■No63260 (魔界の仮面弁士さん) に返信

一応妥協案。
Getだけレジストリアクセスにするとか。

引用返信 編集キー/

■63275 / inTopicNo.19)

　Re[7]: ForegroundLockTimeoutの取得

▲▼■

□投稿者/ 渋木宏明 (9回)-(2012/08/09(Thu) 16:36:37)

2012/08/09(Thu) 16:37:57 編集(投稿者)

ここまで https://gist.github.com/3301996 やっても０が返ってきます。

value を０以外で初期化すると 0 になって返ってくるので、API が指定したアドレスに値を書いているのは確かなようなんですが。。。

引用返信 編集キー/

■63337 / inTopicNo.20)

　Re[8]: ForegroundLockTimeoutの取得

▲　■

□投稿者/ 魔界の仮面弁士 (25回)-(2012/08/15(Wed) 17:52:53)

2012/08/16(Thu) 13:24:25 編集(投稿者)

■No63275 (渋木宏明さん) に返信
> ここまで https://gist.github.com/3301996 やっても０が返ってきます。
> value を０以外で初期化すると 0 になって返ってくるので、API が指定したアドレスに値を書いているのは確かなようなんですが。。。

みなさん、ありがとうございます。

LoadLibrary はおろか、Native C++ でも駄目という状況になっており、
むしろ VBA で動作しているのが、逆に不思議に思えてきました。

呼び出し方に問題があるのか、環境依存の問題が何かあるのか――
引き続き調査を続けてはいますが、未だ手がかりがつかめなていない状態なので
こちらへの質問と併せて、マイクロソフトテクニカルサポートへの
問い合わせをかけました。調査ターゲットは、Win7 + C#2010 on .NET 2.0 です。

なお、アプリを最前面にアクティブ化するために、今回のように
SPI_{GET|SET}FOREGROUNDLOCKTIMEOUT を使うというのは、
過去(Win98 以降)の事例でも実績があるとのことです。

--- 追記:8/16 ---
Microsoft サポートでは現象を再現できず、とのことでした。
本格的に手詰まりです…。

引用返信 編集キー/

次の20件＞
トピック内ページ移動 / << 0 | 1 >>

- Child Tree -