仮に、CSample1Viewを単一のHWND SampleWindowに置換するとしたら、
コメントアウトしたところは全部不要。(これらはMFCのためのもの)

// CDocTemplate* pTemplate;
// POSITION posView;
// POSITION pos;
// pos =::AfxGetApp()->GetFirstDocTemplatePosition();
// if(pos != NULL)
// {
// pTemplate = ::AfxGetApp()->GetNextDocTemplate(pos);
// if(pTemplate)
// {

for(UINT n = 0; n < m_pCaptures->GetCaptureCount(); n++)
{
// //ドキュメントをクリエイト
// CDocument* pDoc = pTemplate->OpenDocumentFile(NULL);
//
// //ビューを取得
// posView = pDoc->GetFirstViewPosition();
// CView* pView = pDoc->GetNextView(posView);
//

//キャプチャーオブジェクトのセット
　　　((CSample1View*)pView)->SetRdCapture(m_pCaptures->GetCapture(n));

}

// }
// }

つまり、
あらかじめm_pCapturesというものができているのであれば、
やっていることの根幹はこれだけ。

for(UINT n = 0; n < m_pCaptures->GetCaptureCount(); n++)
{
//キャプチャーオブジェクトのセット
xxxxxxSetRdCapture(m_pCaptures->GetCapture(n));
}

xxxxxxSetRdCaptureの部分は、
おそらくCSample1View::SetRdCapture()という関数があるはずなので、
そいつの処理内容を *うまく* 移植すればよいはず。
# どうすればよいかは、全体像が見えないと分からない。

> CSample1View以下にプレビューウインドウに対する操作(マウスクリックなど)への
> 反応を示すプログラムが書かれています。
> こちらはなんとか再利用したいと考えています（労力的に）

CSampleView相当になるHWND SampleWindowを作って、
中身を改造して使うということは多分、*知識があれば*可能ですが、
その関数のまんま使うということは多分、難しいと思っていてください。

かりに、このHWNDに登録するWndProcがSampleWindowProcならば、
そこのなかには、例えばこんな感じの代物が必要だったり。

LRESULT CALLBACK
SampleWindowProc(.....) // エラーチェックや引数などは省略
{
static XXXXXXXXX* m_pCaptures; // 例えば

switch(....) // メッセージなどは省略
{
case WM_CREATE:
// 例えばこのあたりで何かを生成？
break;
case WM_PAINT: // OnDrawなんてMFCにしかないので *うまく* 置換する
BeginPaint(...); // エラーチェックや引数などは省略

if(m_pCapture) m_pCapture->OnDraw(FALSE);

EndPaint(...); // エラーチェックや引数などは省略
break;

// 他にも終了処理とか含め、いろいろと書く…

default:
return ::DefWindowProc(); // エラーチェックや引数などは省略
}
return 0;
}

みなさまたくさんのレスありがとうございます

>>wclrp ( 'o')さん
>>#include <afxwin.h>
>>を宣言しているのでほかのMFCコードは動いている（？）と思います。
>あなたのプログラムのメッセージループが動いていて
>MFCのメッセージループは機能していないはず。

afxwin.hをインクルードしたらコンパイルが通ったのでよし、だと思っていました。

> for(UINT n = 0; n < m_pCaptures->GetCaptureCount(); n++)

の部分はなくしてGetCaputureCount(1)とする予定なので大丈夫です
提案してくださったプログラムを明日試してみます。

>>maruさん
>いずれにせよサンプルプログラムの内容を理解せずに再利用なんか無理。

まったくその通りなんですがなにぶん時間がないもので・・・。
Win32の勉強は少しずつ進めているのですが、MFCはほとんど手をつけられていません。。

>>Banさん
>で、あと大前提としてそのSDKがMFCに依存してないかの確認は大事。

SDKがMFCに依存していると言うことがあり得るのですか・・・。
SDKの説明書にはまったく記述されていませんが一つ気になることがあります。
それは

>SDKの提供元に、非MFCでのサンプルがもらえないか交渉する

についてなんですが以前Win32のサンプルプログラムをもらえないかどうか聞いたところ
MFCしか用意していないと言われました。
これはもしかするともしかするんでしょうか(T_T)

またそのサポートというのがサポートのメールに対して返信すらしないというすごい会社
でして・・・
というのはトピックとは関係ないので詳しくは書きませんが
サポートはまったく当てにならないところでした・・・

それとわかりやすい説明ありがとうございます。
明日試してみます。

-------------------------------------------------------------------------
もしBanさんのおっしゃるとおりMFC依存のSDKだったとしたら
Win32でやること自体無理ということになるでしょう。

wclrp ( 'o')さんとBanさんに教えていただいたコードでも埒があかないようであれば
MFCのサンプルプログラムに既存のWin32のコードを移植することにしようと思います。

MFCはWin32の機能を扱いやすくしたものということなので
Win32からMFCへの移植というのはたいがい楽にいったりするものなのでしょうか？

> SDKがMFCに依存していると言うことがあり得るのですか・・・。

SDKメインで販売してるならあえて幅をMFCに狭める必要はないと思いますが、
とりあえず、(仕事で)Windows用コード書いてる人は、たいていMFC使ってる(or使える)と
思いますので、実はそんなに商売の幅も狭まらないのかもしれません。
# それこそ.NET frameworkからでも呼びようはあるわけで。

で、ハードとかメインで販売しててそのおまけSDK的なものだと、ありえるのかなぁと…。
# 実例を確認したわけではなく、単にSDK(Software Development Kit)であって、
# それが非MFCで動くとか動かないとかは、これだけでは分からないというだけの話ですが。

一般的には、非MFCでも動くものが多いのではないかと思いますので、
「MFCへの切り替え」も慎重に判断ください。
「ありもの」が既にある以上、それが決して近道とは限りませんので。

-------------------------------------------------------------------------
> MFCはWin32の機能を扱いやすくしたものということなので
> Win32からMFCへの移植というのはたいがい楽にいったりするものなのでしょうか？

「MFCの作法」を覚えるという、Win32とはまた別の知識習得が必要です。
Win32とMFCの作法が中途半端に混ざると混沌とする可能性もありますので、お気をつけて。

最終的にどこまでMFC化するかにもよりますが、必ずしも全てをMFC化(リライト)する必要はなく、
枠組みをMFCにしてあげた上で、非MFCなWin32APIを使うということは可能ですので、
(逆は、MFCがまっとうに動かない可能性大)、
ベースさえMFCにしてあげたら後は現状のまま、という選択肢もありえるかもしれません。

いずれにせよ、MFCについて知らないことには、どこが必要とか、
どこがぶつかるとか判断はできないと思いますので勉強は必要だと思いますが、
この点で書き換えは多少手を抜きうるのかなと思います。
(まぁ、どこかで統一した方が以後のメンテはやりやすいと思いますが)

>MFCを追加する理由ですが・・・
>大学で今ある実験システムにカメラシステムを追加しようとしています。
>そしてそのカメラシステムを購入したのですが、
>カメラを制御するプログラムを作ろうしてつまずいています。
>カメラシステムに付属していたソフトのSDKを使って
>今まであった実験システムの制御プログラムにカメラを制御する機能を追加しようとし
>て
>いるわけです。

画像はＪＰＥＧですか　それでしたら　ＣＰictureというＭＦＣクラスがネットに公開
されている
実際それでつくりコンパイルして動かしたら簡単にプレビューできた
当該クラスを使うのも一方法かと

自分で書いた文だけど、

> いずれにせよサンプルプログラムの内容を理解せずに再利用なんか無理。
> まずは各々の関数が何をやっているのか理解すること。再利用はそれから。
サンプルプログラムの内容を「完全に」理解する必要はないが、少なくとも
MFCの関数とSDKの関数の区別が分かっている必要がある。
それが分かれば、SDKの使い方（呼び出し順、引数、等）が分かり、自分で
使うことができるようになる。
そもそもSDKのリファレンスマニュアルはないの？

> まったくその通りなんですがなにぶん時間がないもので・・・。
前にどこかで書いたような気がするけど、試行錯誤してその時動作しても、
ほんのちょっと変更を加えただけで、動作しなくなって泥沼化することは
良くある。何事も「急がば回れ」。

「当該のSDKがMFCに依存していない」という条件なら、
サンプルは参考にするのみに留めて、
当該SDKの(関数)仕様書のみを頼りにして、
簡単な実証プログラムを書くのが近道でしょう。

MFCの部分はビューウインドウの開け閉めと、
そのビューに一対一に対応するドキュメントの
割り当てやメニューとの対応を自動化しているだけです。
しかし、わりと隠蔽度合いが強いので、コード間
の関連を推測しづらいのが特徴。つまり知識が無いと
サンプルからMFCだけを取り外すのはほぼ不可能で、
不毛な作業となります。

おそらく、MFCを取り除いた後の残りは、
SDKの関数だけとなるでしょう。
それなら最初からSDKの説明だけを採用したほうが
ましだと考えられます。

MFCを使うと楽と言う話は、MFCの中の隠蔽された部分で
どのアプリでも行なうような汎用的な部分の処理をやってくれるからです。
但し、この隠蔽された部分を使う為にはMFCをベースにしてアプリを構築
しないと表に見えない部分でいろいろな事をやっている可能性があるので
何もかも理解していないとWin32APIベースのプログラムの中に
MFCのウインドウ管理の機能やドキュメント－ビューのアーキテクチャを
撞球するのは多分無理です。
逆にMFCでベースを作成してそのベースの中で必要な部分にWin32APIを
使うと言うのが正解でしょうね。

あと、もう一つ言うならそのSDKがMFC無しで動くのであれば、
SDKの関数の説明書から使い方はある程度わかるのではないかと思います。
特にMFCに依存していないなら引数を見れば、何を渡せば良いかも分かりそうです。
そういう意味ではMFCを使ったサンプルに関しては参考程度にして
実際には使わないと言うのもありえる選択だと思います。
Win32APIでのプログラミングの知識があるのであれば、
そっちの方が早いような気がしますね。
Win32APIでのプログラミングの知識が怪しいなら
いっその事、MFCの勉強をするのもありかもしれませんけれど。

あうあう。誤字

> MFCのウインドウ管理の機能やドキュメント－ビューのアーキテクチャを
> 撞球するのは多分無理です。

MFCのウインドウ管理の機能やドキュメント－ビューのアーキテクチャを
導入するのは多分無理です。

撞球って一体なんだ。(^^;

>>Banさん
結局みなさんに教えてもらったプログラムでも動作しませんでしたので
カメラのサンプルプログラム(MFC)をベースに作ることにしました。
Win32→MFCへの移植に際してはDAボード等の制御をするのですが
この部分に関しましては研究室のほかの人たちのほうがよく知っていて
いろいろ知恵を借りることができると思います。(Borlandを使っているのですが)
ありがとうございました。

>>半可通さん
SDK内部でどう処理されているかはわかりませんが保存をするときはbmpで保存されます。
ギガビットイーサネットを使った変態カメラ（？）なので
そういう汎用のもので動くのかどうかわかりませんね・・・。（完全に想像ですが）

>>maruさん
そのマニュアルというのが・・・
各関数の簡単な説明が載っていたりはするのですが
具体的にどのような処理手順なのかといったことはまったく書いてありません・・・
ダメダメです

>>仲澤＠失業者さん
書いてあるプログラム自体はほとんどC++のように見えるんですよね・・・
でもMFCもC++であったりするわけで。お手上げでした。。

>>ＰＡＴＩＯさん
結局MFCをベースに作成することにしました。
スムーズに進むことを祈ってます。

みなさまありがとうございました。
また質問することがあるかもしれませんがそのときはまたよろしくお願いします。