オーナー設定したウィンドウの作成個数には限界がある!

こんにちは、Platform SDK (Windows SDK) サポートチームです。 ウィンドウの Z オーダーを制御したい場合等、ウィンドウ作成時に、オーナー ウィンドウを設定することがあると思います。 今回は、このオーナー設定したウィンドウを作成する場合に、作成したウィンドウの数によっては、予期せぬ動作となる現象について、お知らせします。 現象 ウィンドウに対してオーナーの設定を行うと、所有される側のウィンドウ (オウンド ウィンドウ) が、所有する側のウィンドウ (オーナー ウィンドウ) の前面に必ず表示されるようにすることができます。たとえば、Windows フォーム アプリケーションの場合は、Owner プロパティや、AddOwnedForm メソッド、RemoveOwnedForm メソッドによって、設定可能です。 しかしながら、オーナー設定したウィンドウ数が 50 個以上になると、ウィンドウ間の Z オーダーが不正な状態になります。具体的には、オウンド ウィンドウの前面にオーナー ウィンドウが出たり、予期せぬウィンドウが前面に表示されたりします。 原因 本現象は、Windows XP 以降の OS における制限に起因します。 OS 側では、オーナー ウィンドウ数の最大値として、50 個の制限値を定義しています。そして OS 内部では、オーナー ウィンドウの深度をカウントしており、50 個に達した場合には、オーナー ウィンドウの設定に失敗します。なお、オーナー ウィンドウの設定に失敗した場合も、OS 内部では SetLastError 関数で拡張エラー コードを設定していないため、アプリケーション側ではエラーは発生しません。 これは OS 側で定義している制限であるため、MFC アプリケーションや Windows…


日本語版以外の Windows 10 を利用した場合、アプリケーションの日本語表記が正しく表示されない場合があります

こんにちは、Platform SDK (Windows SDK) サポートチームです。 今回は、Windows 10 における、オフライン状態でのフォント インストール時の注意点についてお知らせします。 日本語版以外の Windows 10 (Windows 10 英語版等) を利用した場合、日本語の言語パックをインストールしたにも関わらず、各種アプリケーションにて日本語が正しく表示されないという現象が発生することがあります。 もし、日本語の言語パックをインストールしたにも関わらず、日本語が正しく表示されない場合は、以下をご確認ください。 概要 Windows 10 では、日本語補助フォント (Japanese Supplemental Fonts) はインターネット上の Windows Update サイトよりダウンロードして取得する形式に変更されました。 このため、Windows 10 では、オフライン状態での日本語補助フォントのインストールをサポートしていません。日本語補助フォントをインストールする場合は、旧来の Windows OS とは異なり、インターネット上の Windows Update サイトに接続可能な環境が必要となります。 もしも、オフライン状態の日本語版以外の Windows 10 に対して、日本語の言語パックをインストールした場合には、日本語補助フォントがインストールされないため、日本語補助フォントを利用するアプリケーションに関しては、日本語が正しく表示されないという現象が発生する恐れがあります。 日本語補助フォントについては、メイリオ、MS ゴシック、等が該当します。 フォントの詳細については、以下にて確認可能です。 コントロール パネル内、[フォント] を選択します。 左メニュー項目の [オプション機能の管理] を選択します。 表示の中から [日本語補助フォント] を選択します。   詳細 上記のとおり、英語版の…

3

Windows 10 ではトースト通知とバルーンチップが同じ領域で表示されます

こんにちは、Platform SDK (Windows SDK) サポートチームです。 今回は Windows 10 で変更のあった、トースト通知とバルーンチップについてお知らせします。 概要 タスクトレイにアイコンを表示して常駐するアプリケーションから、ユーザーへ通知を行う手段の一つとして、バルーンチップがあります。 Windows 10 からは、バルーンチップの外観がトースト通知の外観に大変近くなりました。 以下は、バルーンチップを表示する同じプログラムを Windows 8.1 と Windows 10 でそれぞれ実行した場合のスクリーン ショットです。 Windows 8.1 と Windows 10 では、バルーンチップの外観が異なっていることがわかるかと思います。     < Windows 8.1 のバルーンチップの外観 >         < Windows 10 のバルーンチップの外観 >   また Windows 10 では、Windows 8.1 まで常にディスプレイ右上から表示されていたトースト通知が、ディスプレイ右下から表示されるようになりました。     < Windows 10 のトースト通知の外観 >  …


ショートカット アイコン削除時にデスクトップの再描画処理が行われない場合がある

こんにちは、Platform SDK (Windows SDK) サポートチームです。 今回はショートカット アイコン削除時にデスクトップの再描画が遅い場合がある現象についてお知らせします。 概要 ショートカット アイコンの作成、削除を連続して行うと、 DeleteFile 関数にてショートカットアイコンを削除後、デスクトップ画面から削除したアイコンが、すぐに消えずに表示されたままになることがあります。 F5 キー を押すと、デスクトップ画面の再描画処理が実施されるため、表示されたままのアイコンを消すことができます。 詳細 ショートカット アイコンの削除処理は、下記二つの段階に分かれて行われます。 1. DeleteFile 関数による .lnk ファイル本体の削除 2. Explorer によるデスクトップ画面の再描画処理 ショートカット アイコンの作成、削除を連続して行うと、「2. Explorer によるデスクトップ画面の再描画処理」が行われない場合があります。 このため、アイコンがデスクトップから消えずに、表示されたまま残ってしまいます。 ただし、本現象が発生した際も、以下の処理は成功しています。 ・ DeleteFile 関数の呼び出し ・ ファイルシステム上の .lnk ファイルの削除 また、ファイル システム上の .lnk ファイルの管理情報は壊れていないため、アイコンの再作成や削除は継続可能です。 回避方法 本現象を回避するには、F5 キーを押して画面のリフレッシュを行うか、アイコンの削除 (DeleteFile 関数) のあとに、以下の処理を追加します。 1. SHGetSpecialFolderLocation 関数の第二パラメータに CSIDL_DESKTOP を指定し、デスクトップの ITEMIDLIST…


PDH、Registry 関数でパフォーマンス情報を取得できない場合がある

こんにちは、Platform SDK (Windows SDK) サポートチームです。今回はパフォーマンス情報がシステム起動時のタイミングで取得できない場合がある現象についてお知らせします。 現象システム起動時にアプリケーション上で以下の何れかの方法でパフォーマンス情報の取得を試みると、期待される情報が取得できない場合があります。 – PDH (Performance Data Helper) 関数を使用する- Registry 関数 (RegQueryValueEx 関数で HKEY_PERFORMANCE_DATA を指定) を使用する 原因Windows OS はシステム起動タイミングでパフォーマンス情報に関する初期化処理を実施します。その際、パフォーマンス情報を管理するための情報がレジストリに一旦作成されますが、本タイミングでパフォーマンス情報の取得を行った場合に情報が取得できません。具体的には、初期化処理開始時に以下のエントリーが作成されてから初期化処理終了時に当該エントリーが削除されるまでの期間となります。 キー  : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib名前  : Updating種類  : REG_SZデータ: WmiApRpl 確認方法1)下記 MSDN ドキュメントのサンプル (Example の項) をビルドします。 Title: RegQueryValueEx functionURL: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724911(v=vs.85).aspx 2) ビルドしたサンプルを実行してコンソールに結果として表示されるバッファ サイズを確認します。3) 上記 Updating エントリーを追加します。4)再度サンプルを実行し、バッファ サイズを確認します。5) 2) と比較してバッファ サイズが小さくなることを確認します。 対処方法システム起動時にパフォーマンス情報に対する初期化処理が実行されることは OS の想定された動作になります。このため、システム起動時にパフォーマンス情報を取得する場合は上記 Updating…


System.Windows.Forms.TextBox 上で、Alt キー + テンキーの 3 を入力すると例外が発生することがある

こんにちは、Platform SDK (Windows SDK) サポートチームです。 System.Windows.Forms.TextBox コントロールは、文字の入力や表示が可能なため、Windows フォームアプリケーションを開発すると、広く利用されるコントロールかと思います。 今回は、この System.Windows.Forms.TextBox 上で発生する不具合について、お知らせします。   現象 System.Windows.Forms.TextBox コントロール上で、Alt キーとテンキーの 3 を同時に入力すると、例外 (System.OverflowException) が発生し、アプリケーションがクラッシュします。 数字キーの 3 との組み合わせでは発生しません。 Windows 7 で実行した場合は、以下のとおりです。     原因 本現象は、.NET Framework 2.0 における不具合に起因します。 Alt キーとテンキーの 3 を押下した場合、.NET Framework 内部でメッセージ処理に不正が発生し、OverflowException エラーが発生します。 上記メッセージ処理の問題は、アプリケーションが、x86 で最適化されている場合は発生しません。 なお、本現象は、.NET Framework 4 以降のバージョンにて修正されています。   回避方法 1. NET Framework のバージョンを変更する。 ターゲット フレームワークを、.NET Framework…


Windows 10 上で、MFC の CFileDialog で作成したダイアログを小さくリサイズできない

こんにちは、Platform SDK (Windows SDK) サポートチームです。 今回は、Windows 10 上で、MFC の CFileDialog クラスを利用した場合に、ダイアログのサイズを、小さくリサイズできない現象についてご紹介します。   概要 MFC では、「ファイルの保存」、「印刷」等の一般的なダイアログ ボックスをカプセル化したコモンダイアログ クラスが利用可能です。 コモン ダイアログ クラスは、Windows が提供しており、OS の動作に依存します。このコモン ダイアログ クラスにある、CFileDialog クラスでは、「ファイルを開く」と「名前を付けて保存」ダイアログの二種類のファイルダイアログを表示できます。 CFileDialog クラスを Windows 10 上で利用した場合、ダイアログのサイズを大きくリサイズすることはできますが、小さくすることができません。 また、サイズを大きくした後にアプリケーションを再起動した場合、大きいサイズのまま表示されます。 – 参考情報 各クラスの詳細については、以下の技術資料をご参照ください。   コモン ダイアログ クラス   <https://msdn.microsoft.com/ja-jp/library/5fcd0hw9.aspx>   CFileDialog クラス   <https://msdn.microsoft.com/ja-jp/library/dk77e5e7.aspx>   状況 本現象については、Windows 10 November Update にて修正されていますので、Windows Update を実施ください。  …


影を付けたウィンドウの表示結果が Windows 10 上でおかしくなる

  こんにちは Platform SDK (Windows SDK) サポートチームです。Windows 10  が RTM されました!Windows 10 関連のお問い合わせも日に日に多くなっていることを実感しています。Windows SDK サポートチームは開発者およびWindowsユーザーの皆様をこれからも全力で支援させていただきます! 今回はWindows 10関連の既知の問題についてお知らせします。Windows アプリケーション開発において、ウィンドウに影を付けることができますが、Windows 10 上ではこちらの表示に問題があります。影を付ける方法の一つとしてウィンドウ クラス スタイルの CS_DROPSHADOW の設定がありますが、Windows 10 上でこちらをセットしたウィンドウを表示した場合、これまでのOSと異なる表示結果になります。 例えば Windows 8.1 上で CS_DROPSHADOW を設定したウィンドウを表示した場合、以下のような結果になります。画像では少々分かりにくいかもしいれませんが、影はウィンドウのすぐ後ろに表示されるようになっています。 一方 Windows 10 では影がウィンドウから離れて表示されます。 皆様には大変ご迷惑をおかけしますが、Windows 10 上でこの現象を回避する方法は現状用意されていません。マイクロソフトはこれをWindows 10上の問題であり、本来であればWindows 8.1 と同じような表示になるべきと認識しています。将来的には修正が行われる見込みですが、残念ながら現時点では修正時期については未定となっています。 – 参考資料 ・Window Class Styles https://msdn.microsoft.com/en-us/library/windows/desktop/ff729176(v=vs.85).aspx


WNetAddConnection2 API 、WNetAddConnection3 API の lpUsername パラメータの指定方法について

Platform SDK (Windows SDK) サポートの小泉です。WNetAddConnection2 API に「サーバー側にログイン可能なユーザー ID とパスワード」といった有効な資格情報を指定しているのに、不定期に ERROR_LOGON_FAILURE (1326) や ERROR_NO_SUCH_LOGON_SESSION (1312)、ERROR_SESSION_CREDENTIAL_CONFLICT (1219)  エラーが発生するという事象を良くお伺いする事があります。 この際に良く目にするのは、lpUsername パラメータに指定するユーザー名に不足があるケースです。例えば、”testuser” のようにユーザー名だけを指定してはいないでしょうか。もし、上記のように指定している場合は、”a-domain\testuser”、”server1\testuser”、”169.254.10.10\testuser” のように接続を確立する際のユーザーの所属を明示的に設定して、現象が回避できるかをお試しください。 本API の lpUsername パラメータに ”testuser” のようにユーザー名だけを指定した場合、API は内部で可能な限り接続を成功させるため、実行アカウントの所属ドメインやマシン名等でアカウントの情報を「○○\ユーザー名」のように補完します。この結果、アプリケーションの実行アカウントや、直前の接続状態、ドメイン所属の有無により補完する情報が替わり、サーバー側で有効な資格情報ではないと判断する場合があります。この結果、その際の状況により、上記でお伝えしたエラーの何れかが返却されます。通常、lpUsername パラメータには OS へのログイン等と同様に、ユーザーの所属を明示的に「○○\ユーザー名」のように指定いただく必要があります。上記の問題を回避するためにも、是非ご検討ください。  <補足情報>上記でご案内したエラーの概要は以下のとおりです。—————————————————————————————1326 エラー(ERROR_LOGON_FAILURE)API に指定したユーザー、パスワードがサーバー側で有効な資格情報ではないと判断した場合に発生いたします。 —————————————————————————————1312  エラー(ERROR_NO_SUCH_LOGON_SESSION)API に指定したユーザー、パスワードを元にした資格情報を元にしたセッションが、サーバー側で見つからない場合に発生いたします。 —————————————————————————————1219 エラー(ERROR_SESSION_CREDENTIAL_CONFLICT)接続しようとしている資格情報が、既に接続している資格情報と一致しない場合に発生いたします。このエラーは、既に目的のサーバー宛の SMB セッションが存在する状態で、当該 SMB セッションで使用しているユーザーと異なるユーザーを用いて接続を試行しようとした場合に発生します。クライアント OS は複数のユーザーで同一のSMB セッションを作成する事は許されておりません。 ————————————————————————————— <参考技術情報>上記でご案内した WNetAddConnection2 API 、WNetAddConnection3 API の詳細は以下の技術資料をご参照ください。 WNetAddConnection2 function (原文版)https://msdn.microsoft.com/en-us/library/windows/desktop/aa385413(v=vs.85).aspx…


Critical Section のデバッグ情報

本日は、Critical Section についてご紹介をさせていただきます。Critical Section を用いることにより、アプリケーションが使用する各種リソース(ヒープ メモリ、変数等)をスレッド間で排他制御を行うことができるようになります。以下の図では、黒い実線がそのスレッドでの動作が可能な状態を示し、赤実線が排他を行いたい処理になります。また、Thread 2 の赤点線は、排他待ちとなります。この図からもわかるとおり、Thread 1 の LeaveCriticalSection により、Thread 2 の処理が行うことが可能になります。 しかしながら、この便利な機能も、実装を誤るとデッドロックを起こしてしまうことがあります。その結果、アプリケーションがハング (停止) 状態となってしまう要因の一つとなります。そのため、Windows は、デバッグを行う際に有効となる情報を CRITICAL_SECTION 構造体に格納します。 具体的には、Windows SDK に同梱されている “WinNT.h” ファイル には、CRITICAL_SECTION 構造体が定義が行われており、DebugInfo メンバー変数に情報が格納されることとなります。 typedef struct _RTL_CRITICAL_SECTION {     PRTL_CRITICAL_SECTION_DEBUG DebugInfo;     //     //  The following three fields control entering and exiting the critical     //  section for the resource…