一般論で書くなら、子ウインドウ上に描画するなら
子ウインドウのクラスに描画処理を書くのが普通じゃないかなぁと。
親ウインドウは子ウインドウに描画に必要な情報を引き渡し、
描いてねと指示をするだけで良いような気がします。

親ウインドウ側で何でもしようとすると子ウインドウ側は
何もかも外から見える状態にする事になってしまい、
カプセル化の概念が崩れしまいます。

各ウインドウ内の制御は各ウインドウに任せ、
親ウインドウはそれらを統括するような作りにした方が理に適っていると思います。

まぁやっぱりそうですよねぇ…

子ウィンドウクラスということはform3に書くべきってことですよね？
１～６のウィンドウには別々の描画をしたいのですがどう処理したらよいのでしょうか

描画内容はcsvファイルから座標を呼び出して、その座標点を表示させるという感じです。
csvファイルは１つで、たとえば(-100,-100)という値が仕切りになっていて、その値から
次のその値までを１つの子ウィンドウに描くといった具合です。

form3に全ての形状を描画できるコードを書きます。
その上でform3のそれぞれのインスタンスに描画して欲しい情報を引き渡します。
後は各ウインドウに描画を依頼するだけです。

そういう作りにする為にはどういう仕掛けを用意する必要があるのかを
考える必要があります。form3は引き渡された情報からどう描画するのかが
わかるようになっている必要があります。
例えばですが、円、直線、矩形の描画が必要だったとして、
form3の各インスタンスは、引き渡された情報がどの形状なのかを
判断できる必要がありますよね。
判断できれば、form3に実装しているその形状の描画を行えば良いかわかるはずです。
この辺はあまりいっぺんに実装しないで一つ一つ形状を追加しながら
動作を確認して行った方が良いと思います。

あと念のために確認しますが、
どうもC++/CLIを使ったプログラムを勉強しようとされているようですが、
間違いありませんか？
もし、C++言語のプログラミングを勉強しようとされているなら方向が間違っている事に
なるので、確認しています。
C++言語とC++/CLI言語は名称が似ていますが、言語としては別物になります。
C++/CLI言語はC++言語を参考にしてはいますが、同じ言語ではありません。
また、C++/CLIに関しては情報があまり多く無いのでC++/CLIを学ぶ必要が無いのなら独学
で学ぶのは結構大変な事になると思います。
C++言語に関しては情報がかなり出回っていますから情報収集も楽です。
C++言語でウインドウ周りのプログラムをする為にはMFCというライブラリを使うのが一般
的ですが、このライブラリは有償の開発環境でないと使えません。
この辺はよくよく確認されて間違いが内容にされると良いと思います。
勿論、C++/CLI言語を学びたいという話なら話は別です。

うがっ、上の書き込みは私です。
ブラウザ上が記憶している名前が化けてしまっているので
修正するのを忘れると名前がおかしくなるのです。

form3の処理については理解しました。ありがとうございました。

実は、いま卒業研究としましてそういうプログラムを作っているわけなんですが、指導教
員が白内障を患ってしまい、教えを乞うことができない状態で研究を進めています。（ま
ぁ研究と言ってもパターン認識なんですが）
指導教員は今年で最後（定年退職）なので変えることもできず、他の指導員に教えてもら
うには専門分野が違うのでなんともできないといった状況です。まぁつまりほぼ独学で
す。幸い研究室には大量の参考書が置いてあるのでそれを見ながら付け焼刃でやってるっ
てことですね。。。

C++とC++/CLIが別物という知識もなく、ただ授業で少しかじった「Windowsアプリケーシ
ョンでパターン認識の途中結果を表示させたい」と思い、学校で配布されたvisual
studio2010を使用しました。お恥ずかしいです。
従来、パターン認識は「認識させて結果を出す」というだけだったので、処理過程（例え
ば拡大や座標点の間引きなど）をあえて表示させたいというだけです。

調べているうちにMFCのほうが圧倒的に多いことやMDIが容易であることもわかりました
が、今更あとに引けず…。。。

あくまで「表示」にこだわった結果こうなってしまったのですが、いまからC++に変更す
るのであれば「表示」は諦めたほうがいいのでしょうか。（力量不足・知識不足がわかっ
たことですし。）
（蛇足ですが、私の研究は「切り出し」が最も大きな課題であり、その部分は既に完成し
ているので現段階で提出したとしても「成果物あり」となるので表示はあまりこだわらな
くてもいいかなと。）

知識量があまりに少なく、本当にお恥ずかしいです。

>調べているうちにMFCのほうが圧倒的に多いことやMDIが容易であることもわかりました
>が、今更あとに引けず…。。。

　MFCでのMDI環境作成が簡単なのは、雛形（プロトタイプ）の作成までです。
　その後、とんでもなく急激にハードル（難易度）が上がります。

　学生の方のようですので、今の社会状況をざっと説明すると、もはやC++はかなりの少
数派です。
　MFCなど化石扱いされることも多々ありますし、現在ではC#やVB(.NET)の方がサンプル
の提供も多くなってきていると思いますし、勉強する環境も整えられています。

　最高性能を目指すようなソフトを作るならC++が最適ですが、生産性、とっつきやす
さ、エンジニアの数、メンテナンスのしやすさなど、今入手できる開発資料などは足元
にも及びません。
　そもそも、新しい言語の方が既存の言語の欠点を潰して作られている事もあると思い
ますしね。

　質問する場所は不適のようでしたが、あせらずC#やVB(.NET)も検討してみると良いと
思います。

#プログラミング技術は、独学が当然と思っている人も少なくありません。
#がんばってください。

そういうことでしたか…
もうすぐ中間発表なので焦って作っていましたが、もう一度指導教員と話し合って考えよ
うと思います。

PATIOさん、ARさん、ありがとうございました。

既に解決されているようですが，
アプリケーションの見た目にこだわらないのであれば
OpenCVを使われてはどうでしょうか？
C言語(C++ならなお良い)の知識があれば
三十分程度のコーディングで
簡単な表示を行うソフトができますよ．

私がC++言語でやりたいのか、C++/CLI言語でやりたいのかを
確認したかったのはC++/CLIで実装するのが大変そうだと考えたからです。
C++言語+MFCの組合せであれば、少なくとも情報が豊富にあるので
C++/CLIよりは遥かにマシだと考えました。

あと、C++とMFCの組合せが化石扱いと言うのは言い過ぎじゃないかと思います。
確かにMS自身も.NET Frameworkに舵を取っているのは事実ですが。
C++にこだわっていないのであれば、C#という選択肢もあります。
特に言語にこだわりが無いのであれば、一考の余地はあると思います。

実際には方法論は色々あると思います。
特定のライブラリを使いたい場合はそのライブラリを利用しやすい言語を
選んだ方が良いケースは勿論ありますけれど。
その辺の土台の部分を固めてから進めた方が手戻りも少なくて良いと思いますよ。

>　MFCでのMDI環境作成が簡単なのは、雛形（プロトタイプ）の作成までです。
>　その後、とんでもなく急激にハードル（難易度）が上がります。
MDIで、子ウインドウ複数に別々の内容を表示したいって
内容でMFCだからってそんなにハードルあがりますかね？
C#やVBと大差ないと思うのですが…