質問への回答を書いておきます。TabControlからDataGridViewが取得出来ないのは、コントロールの階層を誤っているからでしょう。TabControlからカレントのTabPageを取得して、TabPageからDataGridViewを取得します。(DataGridView)page.Controls["dataGridView1"];grid.Rows.Add("test");となります。2010で試していますが、取得に失敗した時のことは考慮していないので、適切に対策を講じて下さい。私は技術的理由で「お勧めしない」といってるわけじゃないので技術的理由で「お勧めしない」といってる方にお尋ねください。(0)通報するANo.13noname#160041#12を投稿した時に更新されていたので、追記しておくと、>>「技術的理由ではなくて設計思想上の理由」と答えてるのにそれを無視して技術的理由とし解釈しようとしてたわけですか。それは話が通じるわけないですね。>>私は「技術的に問題があるからお勧めしない」といってるわけじゃないですから。ウチは技術的理由を求めたんだけどねえ。>>そもそもContorolsがpublicなプロパティ(この場合は変数でも変わらないでしょうが)という事を知らないのであれば「他フォームのControlを直接操作するのはお勧めしない」ということもいえないと思いますが?「ということもいえないと思いますが」とかそういう話じゃなくて、貴殿の事ですよ。知らなかったんでしょ。>>フォームにメソッドなりプロパティを用意すると書いてるのもControlを取得するためのメソッドやプロパティを用意しましょうと書いてるんじゃなく、値を取得したり設定するためのメソッドやプロパティを用意するということなんですけど。>>それにControlsプロパティを使って他フォームから直接操作した場合、そのフォームの画面構成が変わった場合にその操作を行ってるフォーム全てを書き直すことになりかねませんが(これも#6に書いてます)ウチは技術的理由を求めたんだけどねえ。質問者も#1もControlsプロパティを使用して操作していたのに、「何故お勧めできないのか」の技術的な理由を訊いたら、>>仮にフォームAとしますけどフォームAのコントロールを他のフォームBが直接操作するためにはpublic(internalとかもありますが)にする必要があります。>>これをクラスで考えた場合、クラスAのメンバ変数を他のクラスから操作させるがためにpublicにするというのと同じだと思います。>>通常はクラスAにアクセスするためのメソッドを用意するなりクラスAのプロパティとして定義したりすると思いますが、いかがでしょうか?なんて文言が返って来た。「Controlsはパブリックなプロパティ」なのに。これは如何に?>>タイマースレッドだしたのは1例としてあげただけのはずですが。>>フォームが増えた場合の話も出してるのに、勝手に人の話をそれだけの限定したものにしないでください。申し訳ないけど、ウチはこういうやり取りが一番嫌いでねえ。・シングルスレッドの場合は、Controlsプロパティで操作しても技術的な問題はない。・マルチスレッドの場合は、別スレッドからControlsプロパティで操作するのは技術的な問題があると。上記2項目のいづれもFormの数に関わらずですよ。それ以外に技術的な問題があると言うのなら、MSDNを交えて簡単にご説明頂ければと。>>人の話をねじ曲げて解釈してコメントされても困ります。捻じ曲げたつもりは無いんだけど、もうちょっと技術的な返答をしてほしいと言うのが本音ですなあ。(0)通報するANo.11wormhole>>>デリゲートを使った例は書きましたけど私の主張してるのは「他のフォームのコントロールを直接操作するのはお勧めしない」ですし。>>いや、質問は別Form上のDataGridViewの操作の仕方でしょ。質問者も#1もControlsプロパティを使用して操作しているのでしょ。>で、ウチが「何故お勧めできないのか」の技術的な理由を訊いたら、>>>>通常はクラスAにアクセスするためのメソッドを用意するなりクラスAのプロパティとして定義したりすると思いますが、いかがでしょうか?>>なんて意味不明な妄言が出て来たと。要はControlsがプロパティである事を知らなかったんでしょ。>そんな御仁の主張など無意味だわな。「技術的理由ではなくて設計思想上の理由」と答えてるのにそれを無視して技術的理由とし解釈しようとしてたわけですか。それは話が通じるわけないですね。私は「技術的に問題があるからお勧めしない」といってるわけじゃないですから。そもそもContorolsがpublicなプロパティ(この場合は変数でも変わらないでしょうが)という事を知らないのであれば「他フォームのControlを直接操作するのはお勧めしない」ということもいえないと思いますが?フォームにメソッドなりプロパティを用意すると書いてるのもControlを取得するためのメソッドやプロパティを用意しましょうと書いてるんじゃなく、値を取得したり設定するためのメソッドやプロパティを用意するということなんですけど。(0)通報するANo.10wormhole>いや、Controlsがプロパティである事自体、ウチがMSDNを突き付けて初めて知ったんでしょ。(以下略)「Controlsがプロパティであることをお前は知らなかったんだろう」と決めつけのコメントされても・・・>タイマースレッドも別スレッドで非同期動作するマルチスレッドの一つなんだけど。タイマースレッドだしたのは1例としてあげただけのはずですが。フォームが増えた場合の話も出してるのに、勝手に人の話をそれだけの限定したものにしないでください。>NetFrameworkは広大なものだから全部理解する事は不可能だけど、何かを主張するなら、ある程度はMSDNなり書籍なりで調べてもらわないとねえ。人の話をねじ曲げて解釈してコメントされても困ります。(0)通報するANo.9noname#160041>>そうですね。>>Contorolsはpublicなプロパティですね。>>でも私はControlsプロパティがpublicなのはVisualStudioのデザイン画面(のプログラム)のためだと思ってますから。>>だからといってControlsプロパティを使うなとはいうつもりはありません。>>使う必要があるなら使えばいい。いや、Controlsがプロパティである事自体、ウチがMSDNを突き付けて初めて知ったんでしょ。>>誰がマルチスレッドだけを前提にした話をしてたんでしょう?タイマースレッドも別スレッドで非同期動作するマルチスレッドの一つなんだけど。>>デリゲートを使った例は書きましたけど私の主張してるのは「他のフォームのコントロールを直接操作するのはお勧めしない」ですし。いや、質問は別Form上のDataGridViewの操作の仕方でしょ。質問者も#1もControlsプロパティを使用して操作しているのでしょ。ウチが「何故お勧めできないのか」の技術的な理由を訊いたら、>>通常はクラスAにアクセスするためのメソッドを用意するなりクラスAのプロパティとして定義したりすると思いますが、いかがでしょうか?なんて意味不明な妄言が出て来たと。要はControlsがプロパティである事を知らなかったんでしょ。そんな御仁の主張など無意味だわな。>>誰にとって当たり前の話なんでしょう?>>少なくとも今の私にとっては当たり前じゃないんですが、.NET使い始めのころはやってた気はしますけど。さあ「.NET使い始めのころはやってた気はしますけど」なのに、何でControlsがプロパティである事を知らないんだろう。NetFrameworkは広大なものだから全部理解する事は不可能だけど、何かを主張するなら、ある程度はMSDNなり書籍なりで調べてもらわないとねえ。(0)通報するANo.8wormhole>いかがでしょうも何も、ControlsってのはWindowsFormsで定義されているパブリックのプロパティだぞ。>要は自作した全てのFormにはControlsというパブリックのプロパティが存在する。Contorolsはpublicなプロパティですね。私はControlsプロパティがpublicなのはVisualStudioのデザイン画面(のプログラム)のためだと思ってますから。いってControlsプロパティを使うなとはいうつもりはありません。使う必要があるなら使えばいい。フォームが他のフォームのコントロールを直接操作しないと実現できないことってそんなにあるんですか。>スレッドセーフにするのならデリゲートを使用しないとまずいんだが、そもそもマルチスレッドのGUIアプリなんて、マルチスレッド前提のソースが必要になるから、将来的にマルチスレッドになるかもしれないなんて言う想定レベルのソースじゃ話にならない。>シングルスレッドのGUIアプリなら、インスタンス外からFormのControlsプロパティを操作するのは当たり前の話。誰がマルチスレッドだけを前提にした話をしてたんでしょう?デリゲートを使った例は書きましたけど私の主張してるのは「他のフォームのコントロールを直接操作するのはお勧めしない」ですし。誰にとって当たり前の話なんでしょう?少なくとも今の私にとっては当たり前じゃないんですが、.NET使い始めのころはやってた気はしますけど。質問者の方には関係ない話で申し訳ありません。(0)通報するANo.7noname#160041>>仮にフォームAとしますけどフォームAのコントロールを他のフォームBが直接操作するためにはpublic(internalとかもありますが)にする必要があります。>>これをクラスで考えた場合、クラスAのメンバ変数を他のクラスから操作させるがためにpublicにするというのと同じだと思います。>>通常はクラスAにアクセスするためのメソッドを用意するなりクラスAのプロパティとして定義したりすると思いますが、いかがでしょうか?いかがでしょうも何も、ControlsってのはWindowsFormsで定義されているパブリックのプロパティだぞ。要は自作した全てのFormにはControlsというパブリックのプロパティが存在する。http://msdn.microsoft.com/ja-jp/library/system.windows.forms.control.controls.aspxhttp://msdn.microsoft.com/ja-jp/library/system.windows.forms.form.aspxスレッドセーフにするのならデリゲートを使用しないとまずいんだが、そもそもマルチスレッドのGUIアプリなんて、マルチスレッド前提のソースが必要になるから、将来的にマルチスレッドになるかもしれないなんて言う想定レベルのソースじゃ話にならない。シングルスレッドのGUIアプリなら、インスタンス外からFormのControlsプロパティを操作するのは当たり前の話。(0)通報するANo.6wormhole>何で?>どう言う技術理由?技術理由というよりは設計思想上の理由といった方があってるかもしれません。http://okwave.jp/qa/q7487579.htmlの#1の回答者の方も書かれていますがコントロールを操作するのは、そのコントロールを所有するフォームの仕事だからです。仮にフォームAとしますけどフォームAのコントロールを他のフォームBが直接操作するためにはpublic(internalとかもありますが)にする必要があります。これをクラスで考えた場合、クラスAのメンバ変数を他のクラスから操作させるがためにpublicにするというのと同じだと思います。通常はクラスAにアクセスするためのメソッドを用意するなりクラスAのプロパティとして定義したりすると思いますが、いかがでしょうか?またフォームAのコントロールを操作するのがフォームBひとつだけの場合はまだいいですが、フォームC,フォームD...フォームに限らずバックグラウンドのタイマースレッドからなど多数出てきた場合、フォームAのコントロールなのにそのコントロールを操作するコードが各所に散らばるという事態になりかねません。その散らばった状態でコントロールが全く別のコントロール型に仕様変更になったらそれら全て書き換えますか?少なくとも私はそんなことしたくありませんが。コントロールを所有するフォーム以外のフォームが直接操作するのはお勧めしませんし、コントロールの操作はそのコントロールを所有するフォームがするようにすべきと私は思います。絶対やるなとはいいませんけど。(0)通報するANo.5noname#160041#4>>フォームから他のフォームのコントロールに直接値を設定することはしない方がいいと思いますよ。(0)通報するANo.4wormhole以前にも似たような質問あったのですがフォームから他のフォームのコントロールに直接値を設定することはしない方がいいと思いますよ。(0)通報するANo.3Wr5>Form1を表示した後にForm2を表示します.また,dataGridViewはtabcontlorの中にあります.でしたら、DataGridView自体は存在していますね。true)で検索して引っ張り出すか...でしょうか。同じ名前がなければControl[]の先頭が対象のコントロールになるハズです。1つしかなくてもControl[]で返されるコトになりますが。true)[0]);で行けますかねぇ......。Panelの上に設定した場合も...でしょうかね。Text4);の行にブレークポイントを設定します。ブレークした時にf1_Textはどうなっていますか?f1.Controls["dataGridView1"];で取得できていないのではありませんか?f1の方がnullで落ちている。いう可能性もあるかも知れませんが......。VB6.0を使用しています。VB.NETとDB(オラクル)を使って開発をしています。テキストボックスなどに表示されるテキストが指定領域内に入っているか確認したい。avascriptでテキストボックスを追加したいのです。開発歴1年未満の開発者ですがよろしくお願いします。ユーザーフォームに決定ボタンで、テキストボックスを任意の数追加しました。プログラミング初心者です。Reserved.掲載情報の著作権は提供元企業等に帰属します。