ダイアログ上のコントロールの初期背景処理について

Question

いつも大変お世話になっております、鏑木と申します。
今までにもこちらのフォーラムで再三サブダイアログ上のコントロールの表示処理について質問させて頂きましたが、今回も
同様にコントロールの表示処理についてお聞きしたく、新しくスレッドをたてさせて頂きました。

前回までは、メインダイアログからサブダイアログを呼び出した際に、コントロールの背景にサブダイアログの後ろの画面であるメインダイアログが一瞬表示されて
しまっていました。それではサブダイアログ表示時に見た目が悪く、なんとかしたいと思っておりました。
そこでOnPaint()の処理や、OnInitDialog()処理内での処理を軽くするといったことをしてきましたが、あまり良い方向には進みませんでした。

そこで、コントロールを表示させる際に、たとえばCButtonの派生クラスを作成し、そのCButtonクラスの変数をサブダイアログ上で呼び出す際にサブダイアログ化する
ときに呼び出されるPreSubclassWindow()内にメモリデバイスを作成し、そのメモリデバイスにたいして背景処理としてFillSolidBrushを用いることで、サブダイアログ
上でそのコントロールを呼び出すときに後ろ画面であるメインダイアログを表示せずに、そのコントロールのメモリデバイスに設定した背景色を表示させることが出来るように
なりました。

しかしこの方法ですと、ビットマップ、ボタンにたいしては有効なのですが、プログレスバーやエディットボックスといった周りに”囲い”のあるコントロールでは実現することが
できませんでした。(同様の処理をしても、背景は表示されずに後ろ画面が一瞬表示されました)

そこで質問なのですが、プログレスバーやエディットボックスでも、今回わたしがボタンクラスで実現できたメモリデバイスの背景色処理を実現できる方法をご存じの方は
いらっしゃいませんでしょうか？
参考となるご意見をおまちしております。

開発環境は
Windows CE 6.0
Visual Studio 2005
です。

よろしくお願いいたします。

Answer 1

　失礼ながら、今までの経過を読ませていただくと、「受信処理」「波形表示処理」「その他のDLG管理処理」の
それぞれ、及び、それらの連携処理に、様々な問題を抱えたままコーディングを進めてぃるのではないか
という危惧をいだいてしまいます。　一般にPreSubclassWindow()をオーバーライドするする必要はまったく
ありません。また、この中でDCを取得し、描画処理を行うの等は聞いたことがありません。間違いなく、誤った
方向に進路をとっていると考えられます。
　CEではありませんが、過去にUSBからリアルタイムに受信したデータ([µs]オーダー)をグラフ化した経験から
言うと、リアルタイムに表示更新中(100ms毎)のグラフ(波形)の前景に、のDLGを表示しても特に問題が
発生したことはありません。ただし、受信処理やUSBデバイスへの命令送信処理はスレッド化し、グラフ表示
コントロールはお手製です。
　思うに、コントロールの初期化や描画更新手順などに何らかの問題を抱えていると仮定し、「受信処理」
「波形表示処理」を一時的に停止、又はダミー化して、DLGの表示などが速やかに行われることを確認した
ほうが良いと考えられます。
　このテストによって問題の発生源(CPUパワーの主消費部分)を特定し、それを改善する方向を向いたほうが
健全であると考えられます。
　もし、上記切り離しが簡単に行えないという場合は、根本的な設計上の問題があるとも言えるわけです。

 

Answer 2

仲澤@失業者様、ご回答ありがとうございます。
PreSubclassWindow()をオーバーライドとしようと思ったきっかけは、コンストラクタないではDCを取得すること
が出来ない為、コントロール作成時にDC取得用の関数を作成しようと思っていたのですが、PreSubclassWindow()を
オーバーライドしたところ、DC取得することができたため使用していました。
このように使えるからといってむやみにオーバーライドするのはよくないのでしょうか？よくないのでしょうね。。
PreSubclassWindow()での描画処理は仲澤様からの返答からかなりの危機感を感じたため、修正しようとおもいます。

>CEではありませんが、過去にUSBからリアルタイムに受信したデータ([µs]オーダー)をグラフ化した経験から
>言うと、リアルタイムに表示更新中(100ms毎)のグラフ(波形)の前景に、のDLGを表示しても特に問題が
>発生したことはありません。ただし、受信処理やUSBデバイスへの命令送信処理はスレッド化し、グラフ表示
>コントロールはお手製です。
通常のPCであれば、今回直面しているような現象にあうことは全くありませんでした。やはりそこがCEとのパフォーマンスの差
というべきところなのかもしれません。。

現状では、メインダイアログからボタン操作にてサブダイアログをDoModal()で作成する際の描画が遅いので、多少処理が
重くなるかもしれませんが、メインダイアログ立ち上げ時に、モーダレスダイアログで全てのサブダイアログを一度作成させ、
非表示にし、メインダイアログ上のボタン操作によってサブダイアログを作成するのではなく、非表示から表示に切り替えるように
しています。

鏑木

Answer 3

要するに、何もしないコントロールをのせたダイアログを開いても、
「コントロールの背景にサブダイアログの後ろの画面であるメインダイアログが一瞬表示されて」
ということは発生しないわけですよね? そのCEの環境であっても。

であれば、まずはコントロールがちゃんと表示されるようにして、
そのあとで負荷のかかる処理を行えばいいだけだと思いますと言ってきたわけですけれども…。

Answer 4

Atsushi777さんも書かれていますが、単純に内部処理を全て殺した上で単なるダイアログ表示を行っただけでも
サブダイアログの表示で同様の事が発生するのでしたらそれはもはやそのCEのハードウエア性能の限界かもしれません。
逆にその程度なら大丈夫と言う話なら何処まで処理が重くなったらそういう現象が起こるのか実際のハードで
確認するしか無いのではないかと思います。

CEの場合、実装によってはPC並みの性能を持たせる事も出来ますし、その逆もまたしかりです。
なので、鏑木さんが扱っているハードウエアの性能が良く分からないので一般論的な話しかで来ません。
これは致し方ない話なので、自分が扱っているハードウエア環境に合わせて自分なりの解釈と判断が必要です。
これはCEの開発をやっている人間はみな同じなので仕方ない話だと思います。
市販のPDAやかつてのH/PCなどなら性能的にも似たり寄ったりなので想像もつくのですけれど、
オリジナルのハードウエアの場合は性能はその実装に依存しますから。

CEはプアな環境を想定して設計されているOSですから、できる限り処理負荷が抑えられる方向で
OSの動作もチューニングされていると思います。まあ、たいていの場合画面の描画処理は後回しにされる筆頭なので
性能がそれだけ低いマシンだと描画が一番最初に影響を受けるのではないかと思います。
プラットホームビルダーに関しては詳しく有りませんが、ハードウエアに合わせたチューニングもできるのではないかと
思うのですが、その辺はどうなんでしょう。

---

解決した時は、参考になったレスポンスの所にある［回答としてマーク］ボタンをクリックしてスレッドを締めましょう。

Answer 5

Atsushi777様、ご回答ありがとうございます。

＞要するに、何もしないコントロールをのせたダイアログを開いても、
＞「コントロールの背景にサブダイアログの後ろの画面であるメインダイアログが一瞬表示されて」
＞ということは発生しないわけですよね? そのCEの環境であっても。
いえ、違います。何もしないコントロールを置いても後ろ画面は表示されます。
ダイアログ上のコントロールを表示する際に、コントロールが表示される位置を「ダイアログの色に塗りつぶす」
という作業を明記しないと、やはり後ろ画面は表示されてしまいます。

これまでにおっしゃられたことを加味して、コントロール表示時に不可のかかる処理はせず、コントロールが表示されてから
タイマーを用いて不可のかかる処理をするように変更しましたが結果はあまり変わりませんでした。
そのため、これはハードウェアによるものではないかと考えております。

鏑木

Answer 6

PATIO様、いつもご回答ありがとうございます。

＞tsushi777さんも書かれていますが、単純に内部処理を全て殺した上で単なるダイアログ表示を行っただけでも
＞サブダイアログの表示で同様の事が発生するのでしたらそれはもはやそのCEのハードウエア性能の限界かもしれません。
＞逆にその程度なら大丈夫と言う話なら何処まで処理が重くなったらそういう現象が起こるのか実際のハードで
＞確認するしか無いのではないかと思います。
結局、なんの処理も含めていないただのボタンをダイアログ上においても後ろ画面が一瞬表示してしまうので、これはハードウェアによる
ものかなと今は割り切っています。

＞CEの場合、実装によってはPC並みの性能を持たせる事も出来ますし、その逆もまたしかりです。
＞なので、鏑木さんが扱っているハードウエアの性能が良く分からないので一般論的な話しかで来ません。
＞れは致し方ない話なので、自分が扱っているハードウエア環境に合わせて自分なりの解釈と判断が必要です。
＞これはCEの開発をやっている人間はみな同じなので仕方ない話だと思います。
＞市販のPDAやかつてのH/PCなどなら性能的にも似たり寄ったりなので想像もつくのですけれど、
＞オリジナルのハードウエアの場合は性能はその実装に依存しますから。
＞
＞CEはプアな環境を想定して設計されているOSですから、できる限り処理負荷が抑えられる方向で
＞OSの動作もチューニングされていると思います。まあ、たいていの場合画面の描画処理は後回しにされる筆頭なので
＞性能がそれだけ低いマシンだと描画が一番最初に影響を受けるのではないかと思います。
＞プラットホームビルダーに関しては詳しく有りませんが、ハードウエアに合わせたチューニングもできるのではないかと
＞思うのですが、その辺はどうなんでしょう。
OSの開発については本当にわからないので、なんとも答えようがありません。ただ、私の現在のWindows CE 6.0のOS開発に関する
知識ですと、アプリケーションの処理を向上させるような方法は思いつきません。

とりあえず、今は、仲澤様にお答した方法で開発を進めていこうと思います。
ご回答ありがとうございました。

鏑木

Answer 7

何もしていないダイアログでも、コントロールがのっていれば必ずそうなりますか?

そうではないということであれば、やはり何らかの処理の重さが描画に影響しているはずで、
いずれにしてもそれが影響しないようなやり方をすればいいわけですよね?

たとえば、ダイアログを作成することそのものの処理がどうしても重くなるなら、
非表示でダイアログを作成しておいて、全部重たい処理が終わってから
ダイアログを描画するとか、そういうのは?

Answer 8

Atsushi777様、ご回答ありがとうございます。

>何もしていないダイアログでも、コントロールがのっていれば必ずそうなりますか?
波形表示のためのメッセージ送受信をしていない場合はほとんど気にならない程度ですが、メッセージ送受信処理
を行うと、ただのダイアログ上のコントロール表示でも裏画面が一瞬見えます。

ですので現状は、表示させるサブダイアログを非表示で作成し、サブダイアログ呼び出し時にサブダイアログをその都度
作成するのではなく、非表示から表示へと切り替えています。

鏑木

Answer 9

ちょっと気になったので一言だけ。

予めダイアログを作成しておいて非表示にしておき、必要に応じて表示させると言う方法論はごく普通に使う方法ですし、
描画性能が犠牲になるCEだけではなく、PCのアプリでも良くやる話なのでその方法が一番良いと思います。
方法論的には間違っていないと思いますよ。

---

解決した時は、参考になったレスポンスの所にある［回答としてマーク］ボタンをクリックしてスレッドを締めましょう。