C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

掲示板トップ C# と VB.NET 入門 新規作成 利用方法 ツリー表示 トピック表示 ランキング 記事検索 過去ログ
ログ内検索
  • キーワードを複数指定する場合は 半角スペース で区切ってください。
  • 検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
  • [返信]をクリックすると返信ページへ移動します。
キーワード/ 検索条件 /
検索範囲/ 強調表示/ ON (自動リンクOFF)
結果表示件数/ 記事No検索/ ON
大文字と小文字を区別する

全過去ログを検索

<< 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 >>
■1799 　Re[1]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ Hirotow -(2007/03/06(Tue) 20:03:42)
>
    どうでもいいことですが、EXEやDLLの数、すなわちプロジェクトの数がふえるほどビルドの所要時間は増加します。
    またプロジェクトに改名の必要が生じたときが面倒です（そんなことしないのが一番ですが）。

    駄文ですみません。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1800 　Re[2]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ Ognac -(2007/03/06(Tue) 20:21:24)
    目の前のプロジェクトで関連する不具合が発生してます.
    100画面程度のアプリを 5つのサブシステムに別けて、各サブシステムを一つのプロジェクト(.DLL型)にしています。
    EntryPointのMenu.exeから,各DLLを参照し画面遷移する仕組み。
    画面遷移の方向にもよりますが、この場合は、プロジェクトは　.exeプロジェクトであるべきでしょう。
    案の定, Sub_AからSub_Bに移り,Sub_BからSub_Aに戻る必要がてぎた時に,相互参照でコンパイルエラーになってました。
    至って初歩的な不具合なんですが、陥りがちです。
    業務アプリでは, SUBシステム単位で .EXEであるべきというのが, 私の主張です。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1802 　Re[3]: アプリケーション作成時に機能別にexeを分けて
□投稿者/ ばこま -(2007/03/06(Tue) 21:51:27)
    2007/03/07(Wed) 12:11:11 編集(投稿者)

    みなさん貴重なご意見ありがとうございます。
    結局は一長一短で規模別に型にはまらず柔軟に使い分けが良さそうですね。

    大変勉強になりました、ありがとうございます。
記事No.1778 のレス / END /過去ログ10より / 関連記事表示
削除チェック/

■1813 　Re[3]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ 渋木宏明(ひどり) -(2007/03/07(Wed) 03:29:32)
>
    2007/03/07(Wed) 03:33:32 編集(投稿者)

    ■No1800 (Ognac さん) に返信
    > 画面遷移の方向にもよりますが、この場合は、プロジェクトは　.exeプロジェクトであるべきでしょう。
    > 案の定, Sub_AからSub_Bに移り,Sub_BからSub_Aに戻る必要がてぎた時に,相互参照でコンパイルエラーになってました。
    > 至って初歩的な不具合なんですが、陥りがちです。

    それ「だけ」が問題であるなら、比較的簡単な作りこみで回避できるんじゃないですかね？

    既に出ている話ですが、プロセスを分割することによってデータ交換の手間が増大し、安易な作りこみによってデータ漏洩などのセキュリティ低下を招くリスクの方が個人的には心配です。

    まぁこれも適当なフレームワークを作ってあげれば回避は可能ですが、穴の無いものに仕上げるには意外と苦労します。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1814 　Re[3]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ Jitta -(2007/03/07(Wed) 07:27:10)
    ■No1800 (Ognac さん) に返信
    > 画面遷移の方向にもよりますが、この場合は、プロジェクトは　.exeプロジェクトであるべきでしょう。
    > 案の定, Sub_AからSub_Bに移り,Sub_BからSub_Aに戻る必要がてぎた時に,相互参照でコンパイルエラーになってました。
    それは別の問題でしょう。
    画面の主従関係が整理されていないため、と思います。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1822 　Re[4]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ Ognac -(2007/03/07(Wed) 10:26:04)
    ■No1814 (Jitta さん) に返信
    >画面の主従関係が整理されていないため、と思います。
    画面遷移を一方通行で構築する範囲では, DLLで構築するほうが,利便性が高いし,薦めるのでが、
    相互に画面を呼び合ったり,ループ状に参照しあったりするケースで,整理できないまま,具合の悪い面を残したまま製造が上がって来るので,予防の意味もあり、そう言っています。(私のチェック怠慢もあります)
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1823 　Re[5]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ 渋木宏明(ひどり) -(2007/03/07(Wed) 10:32:27)
>
    ■No1822 (Ognac さん) に返信
    > 相互に画面を呼び合ったり,ループ状に参照しあったりするケースで,

    Webだと比較的楽なんですけどね。
    上でも書きましたが、画面遷移を管理するフレームワークを作って、それを使わせるのがいいんじゃないかな。

    # 安易な実装を許して、問題が起きたところだけ個別対処するってのも生産的じゃないし。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1828 　Re[6]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ Ognac -(2007/03/07(Wed) 11:10:30)
    ■No1823 (渋木宏明(ひどり) さん) に返信
    >上でも書きましたが、画面遷移を管理するフレームワークを作って、それを使わせるのがいいんじゃないかな。
    >安易な実装を許して、問題が起きたところだけ個別対処するってのも生産的じゃないし

    そうですね。安易な実装を許さないために、防止策として制約を加えるという消極的対策と,フレームワーク等の仕組みを作る積極的対策がありますね。
    消極的対策は絆創膏的な匂いがいますね。反省材料になりました。ありがとうございました。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1834 　Re[7]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ 渋木宏明(ひどり) -(2007/03/07(Wed) 11:43:02)
>
    > そうですね。安易な実装を許さないために、防止策として制約を加えるという消極的対策と,フレームワーク等の仕組みを作る積極的対策がありますね。
    > 消極的対策は絆創膏的な匂いがいますね。反省材料になりました。ありがとうございました。

    小規模なモノなら消極策でもよろしいんじゃないでしょうか。
    手当てに掛かるコストも小さくて済むでしょうし。

    規模が大きくなればなるほど手当てや保守のコストがかさんでくるので、そういう時にこそ事前に下回りを整えてあげることでデスマーチ傾向が低まります。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1837 　Re[3]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ inat -(2007/03/07(Wed) 12:33:04)
    ■No1800 (Ognac さん) に返信
    > 画面遷移の方向にもよりますが、この場合は、プロジェクトは　.exeプロジェクトであるべきでしょう。
    > 案の定, Sub_AからSub_Bに移り,Sub_BからSub_Aに戻る必要がてぎた時に,相互参照でコンパイルエラーになってました。
    デリゲートを使えば回避できると思いますが。。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1855 　Re[4]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ Ognac -(2007/03/07(Wed) 16:25:45)
    ■No1837 (inat さん) に返信
    > ■No1800 (Ognac さん) に返信
    >> 画面遷移の方向にもよりますが、この場合は、プロジェクトは　.exeプロジェクトであるべきでしょう。
    >> 案の定, Sub_AからSub_Bに移り,Sub_BからSub_Aに戻る必要がてぎた時に,相互参照でコンパイルエラーになってました。
    > デリゲートを使えば回避できると思いますが。。
    仕組みを複雑にするのも考えものかと思いますが。どうでしょう。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1857 　Re[5]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ inat -(2007/03/07(Wed) 17:20:36)
    ■No1855 (Ognac さん) に返信
    >>デリゲートを使えば回避できると思いますが。。
    > 仕組みを複雑にするのも考えものかと思いますが。どうでしょう。
    複雑ですか・・・複雑と言われてしまうとどうしようもないですが
    私的にはexe分けよりかは良いと思いまして。
    ちなみにVB.NETは使ったことがないのであまり詳しく言えませんが
    私はC++/CLIを使っていてデリゲートの方が便利だなーと思いました。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1873 　Re[6]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ Ognac -(2007/03/07(Wed) 20:04:35)
    ■No1857 (inat さん) に返信
    > ■No1855 (Ognac さん) に返信
    > 複雑ですか・・・複雑と言われてしまうとどうしようもないですが

    画面遷移は個々の画面に埋め込んだり,Delegateで処理すると遷移先が固定化されてしまい、保守性に欠けると思うのです。画面遷移クラスを作り、そちらにお任せするのが良いのではと考えます。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1902 　Re[7]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ Pandora -(2007/03/08(Thu) 15:19:08)
    > 画面遷移クラスを作り、そちらにお任せするのが良いのではと考えます。

    　そうであれば、なおさらexe単位で分ける必要はないのではないでしょうか？

    　その画面遷移に責任を持つクラスが表示すべき画面を表示すれば良いのではないでしょうか？

    　つまり、各画面は、自分の持分が終われば終了(クローズ)して、後は、画面遷移クラスに任せるというように

    　すれば、複数のexeを作る必要はないと思いますが、どうでしょう。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1926 　Re[8]: アプリケーション作成時に機能別にexeを分けていますか？
□投稿者/ Ognac -(2007/03/08(Thu) 20:16:08)
    ■No1902 (Pandora さん) に返信
    　>つまり、各画面は、自分の持分が終われば終了(クローズ)して、後は、画面遷移クラスに任せるというように
    　>すれば、複数のexeを作る必要はないと思いますが、どうでしょう。
    言葉足らずで御免なさい。
    当初の発言の前提は, 画面遷移が考慮されずに,個々の画面に無造作に記述されて、その結果、循環参照状態に陥ったプロジェクトがあったものですから,予防策としての意味合いが強いです。
    キチンと画面遷移を設計すれば, 全部DLLで、Okなんです。　が,サブシステム毎にクローズなEXEにしたメリットとして,単体で動作するので,違うチーム(会社)への振り分けとテストが行えることがあります。受け入れ側の怠慢でもあるのですが、...
    exeとdllの差って何! COM時代の, Inprocess/OutProcess　の差ではないんですよね. 単独実行できるか否かの差でしかなければ,
    dllでいいですね。発言の一部を撤回します。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1882 　スクロール可能なPanelコントロールにて残像が残ります
□投稿者/ ばこま -(2007/03/08(Thu) 02:59:23)

    分類:[C# (Windows)]　

    2007/03/08(Thu) 10:07:19 編集(投稿者)
    2007/03/08(Thu) 03:11:06 編集(投稿者)
    2007/03/08(Thu) 02:59:38 編集(投稿者)

    度々この場をお借りします。

    VS2005、C#にてPanelコントロールでスクロール可能な画面を作っています。

    スクロール時にPanel内のコントロールの残像が出まくりでイメージがかなり悪いです、普通のコントロールはまだマシですがカスタムコントロールは更に残像が起こっているようです。
    色々調べてダブルバッファをフォームオープン時の処理に書いてみましたが、それでも変わりません。
    VB6でコントロール数が160ぐらいの画面を作ったことがありますが、残像は出ませんでした…

    もし、解決策等あればよろしくお願いします。

    書き込み後色々試してみましたが、なかなか厳しいです…
    Panel内の描画をスクロール後に行うという事は出来ないのでしょうか？どちらにしても、スクロール中は見れたものじゃないので（苦笑
親記事 /過去ログ10より / 関連記事表示
削除チェック/

■1896 　Re[1]: スクロール可能なPanelコントロールにて残像が残ります
□投稿者/ Hirotow -(2007/03/08(Thu) 13:05:54)
>
    よくわかりませんが、
    SuspendLayout() ResumeLayout() 系のメソッドを使ってみてはどうでしょうか？
記事No.1882 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1897 　Re[1]: スクロール可能なPanelコントロールにて残像が残ります
□投稿者/ シャノン -(2007/03/08(Thu) 13:10:49)
    ■No1882 (ばこま さん) に返信
    > スクロール時にPanel内のコントロールの残像が出まくりでイメージがかなり悪いです

    AutoScrollを有効にしたPanelのスクロール時は、スクロールすることによって新たに表示された部分しか再描画の対象になりません。
    それに関連した問題のような気がする。
記事No.1882 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1933 　Re[2]: スクロール可能なPanelコントロールにて残像が残ります
□投稿者/ ばこま -(2007/03/08(Thu) 22:50:22)
    シャノンさん、Hirotowさんレスありがとうございます。

    あれからいろいろ試しましたが力量不足でうまくいきません…
    言語もどんどん新しくなるにつれ機能充実の反面、処理も遅くなるのでしょうか？？
    C#初めてもうすぐ一ヶ月になりますが、画面ひとつも作ってません（涙）
記事No.1882 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1937 　Re[3]: スクロール可能なPanelコントロールにて残像が残ります
□投稿者/ シャノン -(2007/03/09(Fri) 09:07:34)
    ■No1933 (ばこま さん) に返信
    > シャノンさん、Hirotowさんレスありがとうございます。
    >
    > あれからいろいろ試しましたが力量不足でうまくいきません…
    > 言語もどんどん新しくなるにつれ機能充実の反面、処理も遅くなるのでしょうか？？
    > C#初めてもうすぐ一ヶ月になりますが、画面ひとつも作ってません（涙）

    どういうコードを書いているかわからないと、これ以上は何も言えませんね。
記事No.1882 のレス /過去ログ10より / 関連記事表示
削除チェック/

＜前の20件 | 次の20件＞

<< 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 >>

ヒット件数が多いので過去ログ1〜10 までの検索結果 / 過去ログ11からさらに検索→
パスワード/

- Child Tree -