フォーム間の依存関係を最小限に

C#備忘ログ

C#でWindowsフォームを使うようなアプリケーションは殆ど書かないのであまり興味もなかったのですが、今回2つのフォームを使うツールを書いたときに困ったことがあった。

フォームA(class FormA : Form) / フォームB(class FormB : Form) の2つがあって、

1)フォームA内に配置したボタン(Button1)をクリックすると、フォームBを生成すると同時にフォームAは非表示へ。
2)フォームBを閉じると、フォームAを表示する。

通常ならたぶん、フォームAの button1の Clickイベントハンドラに フォームBをnewして Show()メソッドをコール。

//子フォームを生成して表示、自身は非表示にする
private void Button1_Click(object sender, EventArgs e)
{
  this.Hide();
  var formB = new FormB();
  formB.Show(this);
}

そしてフォームBを閉じたり、非表示になった時のイベントハンドラ(FormB_FormClosingとかFormB_VisibleChangeとか)でFormAのShow()メソッドをコール。

//親フォームを表示(復帰)
private void Form1_FormClosing(Object sender, FormClosingEventArgs e)
{
  this.Owner.Show();
}

のような感じになると思うんですが、フォームBを閉じたときに、フォームAを表示するだけじゃなくて、フォームA上のbutton1のTextプロパティの表示も変えたい!とか、button1のEnabledプロパティーを・・・とか、にしたいとき、FormA側にpublicなメソッドを一個追加してコールさせなければならない・・・。

つまり、フォームAの勝手な都合で、全然関係のないフォームBのソースも修正しなければならなくなる。フォームA,フォームBそれぞれがお互いのインスタンスを共有しなければならない、という非常に非効率な状態になる。2つのフォームだけならまだなんとかなるけど、フォーム10個とかになったときの事を考えると恐ろしい。。。

この場合の解決方法はやはり・・・フォームA側から直接フォームBのイベントに+= 演算子でラムダ式を注入するのが一番いい。Showメソッドで自分自身のインスタンスを渡す必要もない。フォームBのソースを汚染することもなくなる。

ま、ちゃんとメソッドを定義して・・・いう書き方の方がいいのか、インラインでラムダ式を放り込む方がいいのか、書き手側の好みの問題でしょうか。

//FormA
private void Button1_Click(object sender, EventArgs e)
{
  this.Hide();
  var formB = new FormB();
  formB.Show();

  //ラムダ式を注入
  formB.FormClosing += ( bs, be ) => {  Show(); button1.Text = "フォームBは閉じられた!";  };
  //デリゲートを追加
  formB.FormClosing += formBClosed; 
}
private void formBClosed(object sender, FormClosedEventArgs e)
{
    Show();
    button1.Text = "フォームBは閉じられた!";
}

また、FormBの子コントロールの特定のイベントにイベントハンドラを注入したければ、子コントロールにもフォームA側からイベントハンドラを注入してあげればいいが、フォームの子コントロールのアクセスレベルは private なので、単純に子コントロールへはアクセスできない。
そういうときは、フォームBのControlsプロパティから目的の子コントロールを得られる。

//FormA 
private void Button1_Click(object sender, EventArgs e)
{
  this.Hide();
  var formB = new FormB();
  formB.FormClosing += ( bs, be ) => {  Show();  };
  formB.Show();
  var ctrl = formB.Controls["button2"]);
  ctrl.Click += (bs,be) => button1.Text = "クリックされたよ";
}
//エラー処理はしていないよ

メインフォーム ⇔ 子フォーム間の依存関係はできるだけ避けたいし、子フォーム間同士の依存関係もできるだけ避けたい。お互いのフォームがお互いのインスタンス(正確にはインスタンスへの参照)を持ってコードを書くとフォームが増えるに従って グチャグチャになってしまう気がする。。。
気をつけよう。

限りなくノンフィクションに近いある日のフィクション

ゴールデンウィーク始まりましたね。ニコニコ超会議とかコスホリとか行きたかったなー。やっぱ、東京っていいなー。

某施設のための集計システム他諸々を受託開発にする話になって、ウェブも絡んでくる話だったので、社内でのミーティングに参加させられてたのですが・・・憂鬱です・・・。関わりたくなくない。。。

開発は、今時の時流に乗って、某大手のクラウドサービスを利用することになっているのですが、開発のメインとなるリーダー(L)の、あまりの計画性の無さ、場当たり的開発手法に、非常な不安を禁じ得ない。

さらには、その打ち合わせに参加している人達の全員が、ウェブアプリケーションのコードを一行も書いたことのない人達(A/B/C・・・)ばかりでシステム営業さんの集まり。新聞やテレビなどのメディアで報道されているレベルの知識と、日頃の業務知識で、聞きかじったIT用語を駆使して喋るもんだから、話は平行線。

A「ハッカーがウェブサーバーを乗っ取ったら、データベースサーバーからデータを抜き取られる!」
【心の声】いやいや、そうなんだけどね・・・ハッカーが乗っ取るのは脆弱性を放置したサーバーであって・・・・

B「ウェブサーバーからデータベースサーバーへのアクセスは禁止にしないとね。」
【心の声】ウェブシステムを全否定するんですね????

B「データベースサーバーから一定時間毎にウェブサーバーに貯めた一時データを取りいくプログラムをバッチで走らせれば!」
【心の声】たかだか受付/ステータス表示にそんな大袈裟なことする必要あるの・・・???

C「何か他に方法は?」
L「それは開発が始まってからどうとでもかなるから・・・」
【心の声】え???どうとでもなるって・・・(゚◇゚) 仕様を決めないで開発はじめちゃうの(゚◇゚)

僕「テーブルの構成とかのデータベース設計は誰がいつ頃してくれるんですかー? 最初に決めてくれないと」
L「それはまだ分からない各々のデータベースを用意してもらったら集めて纏めるから」
僕「いやいや、チームで開発するんだから、データベース設計は最初にきちんと決めておいてくれないと・・・」
L「そういうのは開発の裏の話だから、どうとでもなりますよ」
【心の声】おいおい、お前一人だけで開発すんじゃねーんだよ!!!

ここで僕は、心が折れてしまった。 っていうのも、僕はこの会社の社員じゃないのでこれ以上口を挟んでも、これからの仕事がやりにくくなるのでダンマリを決め込むことにした。

L「とりあえずどういう機能がいるかを担当者からヒヤリングしないと」
【心の声】え??? まだそのレベルなの??? おいらが参加する必要ないじゃん!!!

C「そもそもクラウドにする必要あるの? オンプレミスですれば・・・」
【心の声】こいつ、今更何言ってるの??? よくいるよね「そもそも ○○○ じゃない?」とか言ってちゃぶ台ひっくり返すバカ。

【心の声】そもそも(笑) 、何のミーティングなん???

だれかタスケテ。

ファイル名に使えない文字

C# 備忘ログ。

テキストボックスに入力したワードをそのまま ディレクトリの作成やファイル作成とかのメソッドに渡すと、例外が飛んでくることがある。ほとんどの場合、?,:,/ などの文字をエスケープしてない!のが原因。めんどくさいのう! と思いながら、それらの文字をフィルタリングするメソッドを書いてたんですが・・・結構気の利くメソッドを見つけた。

Path.GetInvalidFileNameChars()とPath.GetInvalidPathChars()メソッド。

単純にコールすると、ファイルシステム上で使えない文字をchar[]配列に格納して返してくれる! ・・・が、ドキュメントを見ると、頼りないお言葉が・・・

このメソッドから返される配列は、ファイルおよびディレクトリの名前に無効な文字の完全なセットが含まれているとは限りません。

おいおい!仕事放棄するなよぅっっっッ!
ってなわけで、結局、”CON”やら”PRN”とかは自前でフィルタリングしないといけない・・・と。

//using System;
//using System.Text.RegularExpressions;
//using System.IO;
//using System.Linq;
//...
/// <summary>
/// ファイルシステムで使用できない文字をエスケープする。
/// CON,PRNなどの文字列の場合は、before,afterを前後に付けて返す。
/// 制御文字などの文字は、16進文字コードに変換する。
/// </summary>
/// <param name="str">検査する文字</param>
/// <returns>エスケープされた文字列</returns>
public static string EscapeInvalidPathChars(string str,string before="x",string after = "x")
  {
    string rv = Regex.Replace(str,
                              string.Format(@"([{0}])",Regex.Escape(new String(Path.GetInvalidFileNameChars()))),
                              m => Uri.HexEscape(m.Value.First()));

    if(Regex.Match(rv,@"^(CON|PRN|AUX|NULL|COM\d|LPT\d)$",RegexOptions.IgnoreCase).Success)
      rv = string.Format("{1}{0}{2}",rv,before,after);

    return rv;
  }

そういえば・・・CONCON問題とかあったのう。。。ブルースクリーンで一喜一憂してた時代でほのぼのしてたなー

Tweet image download agent.

【追記】 2017/08/20 set-cookieヘッダの取得方法を若干変更。 現在2段階認証には対応しておりません。今度対応させます。
https://osdn.jp/users/earlgreyx/pf/TwitterImageDownloadAgent/wiki/FrontPage


【追記】 2017/08/19 ログイン後の画像取得が失敗する不具合を修正。


【追記】2017/08/18 ↓の原因をほぼ特定。暫定的に修正したものを更新予定。


【追記】2017/08/17 ログインのプロセスが変更になった関係で、現在、ログインが成功しても画像の取得に失敗します。ログイン自体が失敗している模様です。また調査次第修正できるようであれば、修正します m(__)m


【追記】2017/07/09 取得するファイルタイプ(拡張子)、ファイルサイズの上下限を設定できるようにした。コードのリファクタリング実施。


【追記】2016/09/06 テキストボックスのところをコンボボックスに張り替え。新しいものから10個まで入力履歴を記憶できるように修正。他、諸々修正。


【追記】2016/04/27 GW前に、ちまちま修正他、検索ワードに対応。これで画像収集が捗るわい(^^;


ちょっと前に書いたツイッターの画像を一括ダウンロードするやつ、のGUI版を 非同期タスクのお勉強も兼ねて日曜プログラミング(^^;

コンソールでコマンドを打つ方が慣れているのでわざわざGUIみたいなクソめんどくさいもん書く必要もなかったんですが・・・。

とくに最近、C#でアシンクやらアウェイトやらウェイタブルとか今まで見たこともないキーワードがガンガン出てくるようなコードを見る機会が多くなったので、勉強がてら練習で作ってみました。・・・・というレベルです(m_m)
とはいいつつ、awaitとかasyncとかまだよく分からないので、Task.Run()をふんだんにちりばめてみました(^_^;;; ま、自分で使うツールだから動けばいいや。
検索とかはまだ実装していません、というか、自分には必要ないので、やるつもり無し。時間があればまたブラウザで解析して・・・時間があれば・・・。
そもそもこの手のツールは他にもっと便利なソフトが窓の杜とかVectorとか探せばあると思うので。。。
動画とかも落とせればいいかなー、とか思って昼休みにchromeの開発者ツールでちょっと調べてみたけど、結構めんどくさそうですね・・・。

twitterimageagent-1 twitterAgent2

Twitter APIじゃないので、ブラウザでの表示方法が変更されると誤動作するでしょう。

ビルド済みのファイルとあまり綺麗では無いソースファイルは、OSDN.JPの作業部屋 ↓↓↓から。(使い方よく分かってません・・・)
https://osdn.jp/users/earlgreyx/pf/TwitterImageDownloadAgent/wiki/FrontPage