「普通か」という疑問に答えるためには母数のでっかいアンケートが必要。
俺の意見はあくまで俺の意見であって「普通か」の答えとはなりえない。
というわけで以下俺意見。

stdafx.h に自作の gen.h を #include したりはしない。
stdafx.h 中で #include するのは「まず絶対に変更の無い」ファイルのみ。
すなわち Windows/VisualC++ 側が用意したもの、ということは簡単に言うと
#include <....> と <> で囲むべきもののみ。

gen.h はもう完成済みで絶対に変更しない！ということならば
stdafx.h 中に書く、という人はいるかもしれないけど、俺はやんない。
普通に CMainDlg.cpp 中に #include gen.h するべし。
っていうかそういう「共通」なものが本当に必要？
グローバル変数なんてのは使わないに限るんだけど。
resource.h なんかは共通に使うけど、変更が多いから stdafx.h には書かない。

あと、エラーになる、って何エラーかわからんのにアドバイスできんよ。

Cgenのクラスで状態遷移関数(50遷移ぐらい)を用意し、
CChildADlg、CChildBDlgでは同じ状態遷移を実行します。
違いは、パラメータ２つのみ。
だから、CChildADlg、CChildBDlgの両方に同じ記述をするのは時間もかかるし
無駄だと思ったのでこのような方法にしました。

＞stdafx.h 中で #include するのは「まず絶対に変更の無い」ファイルのみ。
こういう意識はありました。

エラー内容は以下の通りです。
構文エラー : ';' が、識別子 'pGen' の前に必要です。
error C2501: 'Cgen' : 識別名を宣言するのに、型が指定されていません。
error C2501: 'pGen' : 識別名を宣言するのに、型が指定されていません。

> エラー内容は以下の通りです。
そのクラス(CChildADlg)のヘッダに #include gen.h と記述していないのでしょう
か？

インクルードがらみでもうひとつ質問があるのですが・・・

クラスをたくさん作るとStdAfx.cなどがあるフォルダの直下に
ファイルがたくさんできてしまします。
そこで機能ごとにフォルダを作成し、そのフォルダの直下にファイルをおきました。
そのクラスのＣファイルでも先頭でStdAfx.hをインクルードしてますが、
パスが違うため../StdAfx.hとしないとだめなのでは？
しかし、このようにすると

fatal error C1010: プリコンパイル済みヘッダーの検索中に予期しない EOF を検出しました。

というエラーになります。
パスが違うのに
StdAfx.hだとエラーになりません。
なぜでしょうか？

＞そのクラス(CChildADlg)のヘッダに #include gen.h と記述していないのでしょう
＞か？

してないですよ。
今してみましたが、同じ結果でした。

>してないですよ。
しなければ、CChildADlgがCgenってクラスが何者かわからないのでコンパイルできなく
て当然です。

>今してみましたが、同じ結果でした。
そんなことないと思いますが。一度リビルドしてみてはどうでしょうか？

>パスが違うのに
>StdAfx.hだとエラーになりません。
おそらく、コンパイル時にそのcppを基準に見てコンパイルしないからではないでしょう
か？
(たとえばdwpがあるフォルダを基準にしているとか。)

StdAfx.hでgen.hをインクルードし、
CChildADlgのメンバ変数に
CGen m_CGen;
を宣言し、
CChildADlgクラス内でアクセスすることができました。

＞おそらく、コンパイル時にそのcppを基準に見てコンパイルしないからではないでしょ
＞うか？
多分そんな感じなんでしょうね！
ということは、StdAfx.hの階層にフォルダを作成し、そのフォルダ内に
クラスのcpp,hを置いても問題ないということですね？
クラスがたくさん増えると整理したくなります。。。
１つのフォルダだときたなくみえて！
ファイルを探すのも大変ですし！

ちなみになんですが、

今言われているCgenと言うクラスに関しては別にグローバル変数と言うわけでも
無いみたいですね。単にとあるクラスを他のクラスのメンバーに使いたいと言う
事だけに見えます。私なら各クラスのヘッダーにインクルードしちゃうでしょうね。
その方が転用する時は都合が良いので。

プリコンパイルヘッダーを使用するにしている時に変更が多いヘッダーファイルを
Stdafx.hにインクルードしてると毎回プリコンパイルヘッダーの作り直しが行われるので
プリコンパイルヘッダーを使っている魅力が半減するかもしれません。
それでもソースファイル毎で無くなるからマシではありますが。

「Stdafx.h」でなく、アプリケーションクラス（CWinAppクラス）のヘッダファイル
に加えてみたらどうでしょうか。
　AppWizardでスケルトンを作成すれば、個々のクラスで定義されるはずです。
「Stdafx.h」はVisualCが管理しているヘッダーファイルです。
普通、SDK等で使うヘッダーファイル、MFCのヘッダファイル「Afx」で始まるヘッダファイルです。

>ちなみになんですが、

>今言われているCgenと言うクラスに関しては別にグローバル変数と言うわけでも
>無いみたいですね。単にとあるクラスを他のクラスのメンバーに使いたいと言う
>事だけに見えます。私なら各クラスのヘッダーにインクルードしちゃうでしょうね。
>その方が転用する時は都合が良いので。

詳しく説明するとメインダイアログにボタンが１０個あります。
このボタン押下でそれぞれのダイアログが表示されます。

上で示したジェネリッククラスは
この１０個のダイアログクラスのうち８個で使用されます。
また、同じように８個のダイアログクラスで共通に使用する
ジェネリッククラスが１０個ぐらいあります。

このような状況ではジェネリッククラスの定義を
どのようにするのが妥当でしょうか？

> このような状況ではジェネリッククラスの定義を
> どのようにするのが妥当でしょうか？

妥当性を考えるには、ジェネリッククラスについての情報不足。

> 上で示したジェネリッククラスは
> この１０個のダイアログクラスのうち８個で使用されます。

多くのダイアログクラスが同じようなイベントハンドラを
持っているような印象を受けます。
私ならダイアログクラスの基底クラスを検討すると思う。

> また、同じように８個のダイアログクラスで共通に使用する
> ジェネリッククラスが１０個ぐらいあります。

もしかして、複数のダイアログクラスから、
共通のジェネリッククラスのインスタンスを見たいって事？

その場合、ダイアログの基底クラスのスタティックメンバとして持つか、
ジェネリッククラスのメンバをスタティックにする。

いずれにしろ、これ以上は情報不足。何をしたいのか書いてください。

# 私の書いてることが判りにくければ...
http://www1.kcn.ne.jp/~robe/cpphtml/html02/cpp02028.html

それぞれのクラスが完全に独立してて
しかも、横の情報のつながりが無くて良いなら、

その何十個もあるラス全部を継承したクラスをがんばって作って
それひとつをインクルードするとかｗ

ハードルも高そうですが、すっきりするかもよ？

詳しく説明します。
このアプリは基板の単体調整用ソフトです。

メインダイアログにあるボタンを押下することにより各基板のダイアログが表示されま
す。
基板は全部で９種類。
各基板の試験項目は２０種類ほど。（基板により異なる）
各基板のダイアログに各試験項目のボタンを用意し、
ボタンを押下することにより、試験を開始し、
結果をリストボックスに表示します。
各基板ダイアログのOnTimerで状態遷移をします。
その時に共通の試験項目が１０種類ほどあります。
例えば、メモリテストなど・・（試験範囲とアドレスが異なるのみ）
この試験をジェネリッククラスで状態遷移させ、
各基板ダイアログクラスから共通にアクセスしようとしています。
試験範囲などのパラメータを各基板ダイアログクラスから渡せば
試験の状態遷移は共通化することができます。

いや、だからフツーに #include すりゃいいぢゃん。
stdafx.h に書くのは個人的には絶対却下なので、こんな感じ。

--- generic.h ---
class generic_helper {...};
--- hoge1.h ---
#include generic.h
class CHogeDialog : public CDialog { ...
generic_helper x;
};
--- hoge1.cpp ---
#include StdAfx.h
#include hoge1.h
...

必要なところにきっちり #include を記述すれば正しく動く。

もし何かが正しく動かないとしたら、それはソースコードの記述が悪い。
・#include の順番/位置が悪いとか
・多重 #include に対応してない記述してるとか
・#include StdAfx.h より前に何か書いてるとか

ソース開示なしには一般論しか言えないのであとはがんばってくれ。

「共通のなんたら」がいっぱいあるならたいちうさんのご意見を参考にしませう。