季節の味わいというものは楽しみなものである。この時期、駿河湾の桜えびもそのひとつだ。中でも由井は有名である。東京から東名高速を進むと、山間を抜け開けた海岸の景色が印象的な由井。ついスピードを出してしまいそうな所だが安全運転に心がけたいものである。
さて、桜えびが有名な由井だが、隠れた名品があるのをご存知だろうか。
テレビ朝日の土曜日朝の放送の「旅さらだ」でゲストが各地の美味を取り上げるコーナーがあり(現在では番組の構成は違っている)、この地の「由井缶詰所」が紹介された。
商品は、まぐろの油漬けである。早速、Webで注文、格別の味である。
もう、スーパーで売っているツナ缶には戻れない。
桜えびを求めて出かけた折には、今度は現地で購入したいと思っている。
View(Form1)の役目は、Controllerにコントロールの値(textboxの値)を伝えること、そしてメソッド(Yno)を呼び出すこと。
フォームに追加するコードは、//の部分だけ。
Controllerクラスのメソッドを呼び出すため、インスタンスを生成して、変数に格納。
public partial class Form1 : Form
{
private Controller controller; //private変数に格納
public Form1()
{
InitializeComponent();
controller = new Controller(); //コンストラクターでインスタンス生成
}
--------------略----------------
ボタンのクリックイントに追加するのは、//の部分だけ。
textbox1の値をControllerに渡し、メソッドを呼び出す。
///の部分はおまけ、結果を別の場所で利用できるようにクリップボードにコピーしておく。
private void button1_Click(object sender, EventArgs e)
{
controller.Jcode = textBox1.Text; //コントローラーに渡す郵便番号
string gt = controller.Yno(); //メソッドの呼び出しと戻り値が入る変数
textBox2.Text = gt; //戻り値(住所)をtextboxに表示
Clipboard.SetText(gt); ///クリップボードにコピー
}
このように、フォームのコードは少なくごく簡単なものである。実行結果を示すと
Controllerはフォームから受け取った情報もとに、処理はModelに任せます。
コンソールアプリ(Model)のYubinクラスのYnoメソッドを呼び出し、結果を受け取ります。
public class Controller
{
public Controller()
{
Yubin yubin = new Yubin();
}
public string Jcode { get; set; } //フォームから受け取るプロパティJcode
public string Yno()
{
var gtcreator = new Yubin();
return gtcreator.Yno(Jcode);
}
}
以上、出来上がっているコンソールアプリ(Model)は全く変更なく、ViewとControllerとの連携がとれました。
javaをかじった経験から言えば、必ず出てくる「クラス」「クラスの継承」「インターフェース」などなど、分かったようで結局定着しない。分かりやすい例え話の説明も概念としては理解できるが、実際の場面でどう応用すべきか発想ができない。まあ、自身の力不足と言ってしまえばそれまでだが、そもそも、
textBox1.Text=”なんちゃらかんちゃら”;
とか、当然のように使っているから「クラス」など特に意識していない。
VSで、フォームアプリケーションを新規作成すれば、自動的にForm1のデザイン画面が表示される。実行すればForm1が表示される。デザイン画面で見ているForm1が実体だと思ってしまうのも無理はない。
従って、Form1とForm2がある場合、Form2を呼び出そうと思い
DoCmd.OpenForm ”Form2” のような
Accessの感覚でコードを発想すると痛い目に会う。
なんでこんな簡単なことができないのだろうと思ってしまう。
そこで初めてFormも「クラス」だと思い知る。
Formクラスを継承したForm1やForm2なのである。
「インスタンス」を生成しなければ、呼び出せないのである。
VSでは簡単に開発できるが、反面意識が及ばない部分が多々ある。
データベースプログラミングで経験したtextboxのVisibleプロパティの件だが、改めて思う。デザイン画面でVisibleをFalseに設定するとデータバインドしないという事実。インスタンス生成時にそもそも描画対象とならないのだから、バインドもされないと理解できる。
話を元に戻そう。
今回、オブジェクト指向を明確に意識できるよう、MVCに挑戦しようと思う。
課題は、住所録で登場した、郵便番号から住所を検索する部分だけを取り出してみる。
まずコンソールアプリケーションで課題となるロジックを作成する。
データベースへの接続はADO.NETを使う。検索結果としての住所は、SQLで抽出する。
実行結果の画面を示すと
さて、次回はこのModel(ロジック)をどのように、View（ビュー、いわゆるフォーム）、と連携させるかである。Controller(コントローラー)はどうすればよいのだろう。
通信教育の教材を読み進め、コンピューターの仕組み等を理解し、機械語・アッセンブリ言語へと進む。16進のコードを慎重に打ち込み、開始番地を指定しGO、タイマーが動く。感激する。大学の授業とは大違いである。目の前で実行結果が見られるのは何物にも代えられない。嫌いな教科として、よく数学があげられるが、好きな教科としても数学があげられる。理由は、「答が出るから」。プログラミングの楽しみは正にこれであろう。「指示通りに動き結果(答)が出る」、1文字でも間違えばエラーとなり実行できない。間違えを見つけて正しく動くと嬉しくなる。
ワンボードマイコンからモニター、キーボード付きマイコンへ
TandyRadioShack TRS-80を購入、価格は忘れだが、現在からそのスペックを見ればかなり高価なものだったはずである。
ここで、初めてBASICに出会う。16進のコードを入れるのとは大違い。
続いて、NECのPC8801、パソコン誌も充実してきて本格的にBASICに取り組む。
しかし、当時としては高価なものであった。カラーモニター20万円程度、ドットインパクトプリンターも20数万円したと思う。電卓パチパチの時代に、職場へ持ち込み、業務処理をしてみせると驚きの声が上がったものだ。手書きが当たり前の時代、アイ企画のワープロソフト「文筆」は大いに活用できた。ゲーム機のような8801だが実用にも十分役に立った。しかし、文筆を開発した人はすごいなと今でも思う。そして時代はPC9801へと進んでいく。
またしても余談だが、ワープロについて一言。ワープロソフトもいろいろなものが発売された。印象に残っているのは、super春望、P1EXEなど。jx太郎はその後一太郎として一世を風靡する。ATOKは別として、一太郎には当初から限界を感じていた。画面上の「行」というものに縛れている感じがしたのである。それを端的に表しているのが、行罫線と行間罫線である。この考え方を変えない限りワードのような多様な表組は無理だろうと思う。Ver7までは見守ったが、Ver8で完全に見放し、資産のすべてを完全にWordへと移行した。
ワープロ専用機が普及するようになり、職場にもＯＡの波がやってくる。基幹業務にコンピューターを導入するよう強く要請、検討チームの一員となった。責任者には大先輩が就いたが、技術的なことは小生が進めた。力のある大先輩のお蔭で内部的な根回しや起案書はすんなり通った。当時の業務システムはまだまだ独自発注するしかなく、オフコンが主流である。NECのオフコンが導入され、端末は2台、ラインプリンターの構成でスタートする。事務システムの開発言語は当然のごとくCOBOLであった。COBOLは経験なかったが、納入されたシステムだけでは不足の部分もある。内部で独自にカスタマイズできるよう、NECの簡易言語SMARTを習得、多彩なレポートも自作することができた。
時代は、急速にパソコンが普及するようになり、オフコンベースの集中処理から、多数のPCを配置する分散処理へと移行することになる。クライアントサーバーシステムの導入へと向かうことになる。SQLSERVERを使った業務ソフトが導入され、Accessとの連携が始まる。Windows3.1時代から初代Accessとの付き合いがあったが、ようやく本格的な利用ができるようになった。パッケージソフトのカスタマイズは費用がかかる。Accessによる現場開発は欠かせない。BASIC、QuickBASIC 、VisualBasicなどの経験が役にたったと思う。
この間、インターネットの環境も急速に整い、NTServer+IIS+perlCGIなどにも取り組んだ。UNIXベースのものをWindowsへ移植するのは結構苦労した。
専門的教育を受けたわけではないので、独学で躓きながらも、時間を忘れ取り組むことができたのはやはりプログラミングの楽しさの所以であろう。
そもそも小生が初めてプログラム言語に接したのは、大学での実習、FORTRANである。内容は覚えていない、というか印象がない。
パンチカードを渡されて何かしたとは思うが、肝心のコンピューターには触れたことも見たこともない。
コンピューターそのものは一般人には馴染みのないものだったのだ。大学に入って、授業に必要で初めて購入した電卓が秋葉原で20,000円もした。それも、単純な四則演算しかできないものが。関数電卓もあったが10万円以上もする高価なもので学生が購入できるものではなかった。もっぱら計算尺で頑張っていた時代である。その後、しばらくして12,000円~13,000円でカシオから関数電卓が発売になったのは衝撃であった。今思えばこの時期に半導体技術が進歩し、LSIの大量生産が始まったのだろう。そして、時代は8ビットCPUへと進んだ。
コンピューターという用語も一般的ではなかった。電子計算機ということがほとんどであった。電卓は電子卓上計算機なのだ。小生がコンピューターという言葉を初めて聞いたのはアメリカのテレビドラマ「タイムトンネル」の中でのことである。その横文字の意味ははじめ理解できなかった。しかし妙に格好よく聞こえた。調べてみるとcomputerであった。計算computeするもの、計算機であると理解した。余談であるが、コンピュータは表記として認められているようだが、小生はあくまでコンピューターである。放送用語としてはコンピューター(NHK以外確認してないが)である。
これも余談ではあるが、日本は公式には横文字を嫌う。役所から来る通達等にはコンピューターの文字はない。電算化、電磁的記録など旧態依然と言ったところであろうか。法律家ではないので、深い意味があるのかどうか知らない。
小生がコンピューターなるものに興味を持ったのは、大学を卒業し、テレビゲームでテニスゲームがはやったころである。これが自作できるという。そうなのかと思いながら、通信教育のセットを購入したのが始まりである。何冊かの教材と、ワンボードのマイコンが付属していた。どうでもよいことであるが、マイクロコンピューターのことが分かっていないと、その後のパソコンという言い方とマイコンを混同する人がいるようである。
何はともあれ、この教材によって
アッセンブリ言語(assembly language)と出会うことになったのである。
続きは次回。
仕上げとして
1.入力は上の項目から順次入力していくのが通常であろう。
マウスを使って、次の項目(他の項目)にカーソルをもっていく人が多いかもしれない。
しかし、TABキーで移動できることを知っている人は、そうするかもしれない。
従って。TabIndexは適切に設定しておく。
住所検索ボタンをクリックしたときは、住所欄に入ったテキストの最後にカーソルが移動しておくようにする。そうすれば続けて番地等が入力しやすい。
そのためには
住所検索ボタンのClickイベントに、住所欄テキストボックスにfocusが移るように設定、
TextBox.Focus();
住所欄テキストボックスのEnterイベントに
TextBox.Select(TextBox.Text.Length, 0);
2.不用意にフォームを閉じてしまい、更新内容が反映されないのでは困る。
dirtyフラグを使い、各テキストボックスのTextChangedイベントにdirtyフラグをtrueにする。実行直後や保存ボタンをクリックしたときはフラグをfalseにする。
全体としてもっと効率のよい方法もあるだろうが、今回はとりあえず個々に設定。
高度な方法は今後の課題にしておく。
終了時、FormClosingイベントに変更確認のダイアログMessageBox.Show();を表示させる。
ボタンはYesNoCancelにしておく。
それと、bindingNavigatorDeleteItemによる削除は、いきなり削除されてしまうので、
Clickイベントに削除確認を行うようにする。
せっかくだから、
DataRowView.Row.ItemArray[Index]からId(Indexは0)または氏名(Indexは1)、
あるいは両方を取り出しMessageBox.Show()で確認すれば、より確実である。
両方の場合は、ダイアログに2行で表示させる。改行コードは’\n’である。
初めてのVisualStudio2017C#の勉強としては参考となる事が多かった。
郵便番号検索機能を組み込む
これについては、現在ではいろいろなサイトでよく見かけるし、市販の住所録(宛名作成)ソフトなどでもおなじみなので使い方の説明はいらないだろう。番号を入れると、都道府県市区町村名までが自動で入るものである。
元データは日本郵便のサイトからCSVファイルをダウンロードして使用する。
必要な部分は、郵便番号および都道府県名市区町村名だけだが、ﾌﾘｶﾞﾅなどもすべて読み込んでおいた。データはいくつかの区切りで構成されている。
例えば
0600041なら, 北海道, 札幌市, 中央区大通東
1036090なら, 東京都, 中央区, 日本橋東京日本橋タワー
番号を入れ、ボタンをクリックした時に、検索結果として
北海道札幌市中央区大通東
東京都中央区日本橋東京日本橋タワー
というデータをどのように取得するかを考える。
Accessとの付き合いが長いもので、ついついテキストボックスに個別に取り出し連結することを思いついてしまう。MessageBoxに変数の内容を入れ動作の確認をするのもわずらわしいので、TextBoxで直接確認できるのはありがたい。すべて確認が済んだら、不要なTextBoxのVisibleプロパティをfalseにして体裁を整える。
しかし、ここで思いがけない落とし穴があった。にわかには理解しがたいことだが、TextBoxのVisibleプロパティをfalseにすると、参照すべきデータが入ってこないのである。Accessでは経験したことがない。どこかコードが間違っているのではないか。いろいろ確認してみても、Visibleプロパティをfalseにしただけでダメなのである。
最終的に確認できたことは、データバインドしたTextBoxはVisibleプロパティをfalseにするタイミングによって挙動が異なるようなのである。フォームのデザイナーでfalseにしてしまうと参照できないようである。というか、データそのものが入ってこない。参照自体はエラーにはならないので、何がいけないのか理解できないまま時間だけが過ぎていく。結論としてフォームのロード後にfalseにすれば問題なく参照できる。明確な理由は分からないが事実として受け入れざるを得ない。そのうえで、これでよしとするかデータバインドしない方法を考えるかどちらかである。
そこで、思いつくのはどうせデータバインドさせないならいくつもTextBoxを配置するより一発で連結データを取り出す方が早い。クエリである。
列データを連結するのは簡単である。
SQLでは
SELECT [列名1] + [列名2] + [列名3] AS エイリアス名
FROM テーブル名
WHERE [〒番号] = @パラメータ名
得られた結果を住所欄のテキストボックに表示すればよい。
まあ、こちらの方がすっきりしている。
いずれにしても住所欄にデータが入ったら、残りの番地や建物名などを自分で追加入力する。住所は文字数が多いこともあるので、テキストボックスはMultiLineプロパティをTrueにしておく。
少し時間がかかったが、いろいろ参考になることが多かった。
これで主要な部分は完成した。
最後の仕上げをしよう。
独自機能の追加
1 氏名による検索(前方・後方一致あいまい検索)
BindingSourceのスマートタグ(右上の三角)から「クエリの追加」を行う。
「条件検索ビルダー」が起動するので、クエリテキストを次のように変更する。
Sql文がうまく書けない人は、SQLSeverManagementStudioでビューを作成するときのようなグリッド形式のGUIも使うことができる。
——————————————————————-
SELECT Id, Name, 〒No, Address, Tel, Email FROM table名
WHERE Name LIKE ‘%’+ @パラメータ名 + ‘%’
——————————————————————-
SQL 文では文字列をシングルクォーテーションで挟む。パラメータクエリのパラメータの前後に、シングルクォーテーションで挟んだ「%」の文字列を加えると、部分一致のクエリになる。%田%であれば、田中・中田・小田原などが検索対象となる。
クエリが完成すると
BindingNavigatorの下に、パラメータ名のラベルとパラメーター入力用のテキストボックス、クエリ名のボタンが配置されたfillByToolStripが貼りつく。
パラメータを入れ、ボタンをクリックすると以下のイベントハンドラーが呼び出される。
(注：fillByの引数等は設定で異なる)
private void fillByToolStripButton_Click(object sender, EventArgs e)
{
try
{
this.テーブル名TableAdapter.FillBy(this. データセット名DataSet.Table, textToolStripTextBox.Text);
}
catch (System.Exception ex)
{
System.Windows.Forms.MessageBox.Show(ex.Message);
}
}
これを参考に、独自にTextBox、Buttonを配置してデザインすることも可能、先に示した画面サンプルではデフォルトで貼りついたもののデザイン(fontやtext)を変更して見やすくしただけのもの。
2 住所による検索
例えば、「東京」都在住、「大阪市」在住などを検索するために、1のNameをAddressに変更すれば
よいことになる。完成したらもう一つfillByToolStripが貼りつく。
これも独自にフォームのデザインをしてもよい。
3 検索結果の解除(全件表示に戻る)
検索結果を確認したら、元に戻す必要がある。そのためのボタンとクリックイベントを記述する。
画面サンプルでは、1つ目のfillByToolStripにボタンを追加して「検索解除」のボタンとして配置した。もちろん独自にボタンをフォーム上に配置してもよい。
コードは以下の通り。Fillを使っていることがわかる。
private void fillToolStripButton_Click(object sender, EventArgs e)
{
try
{
this. テーブル名TableAdapter.Fill(this.データセット名DataSet.Table);
}
catch (System.Exception ex)
{
System.Windows.Forms.MessageBox.Show(ex.Message);
}
}
住所録の基本機能としてはこんなところか。変更や更新の確認など、細かい点は最後にする。
次回は、〒番号の検索である。イメージは何となく分かっていたものの、AccessのVBAでは経験したことのない落とし穴にはまることになるとは、予想もしなかった。
さて、細かいコードの説明の前に、データベースとのやり取りをする仕組みの概略を理解しておく。
3で述べたように、最初にデータ接続があった。
これは、データベースに接続するための設定情報を含むAdapterと呼ばれるプログラムとConnectionと呼ばれるプログラムなどデータベースに接続するための必要なプログラムの総称である。VisualStudioを使ってデータベースおよびテーブルを作成すると自動的にデータ接続が設定される。
その後、データソースを追加したが、これがデータセットDataSetである。
データセットはデータベースのコピーのようなものでメモリ上に展開される。直接データベースとやり取りするのではなく、メモリ上のデータセットとやり取りして、全てが終了するときに、データベースへ変更結果を書き込むようにするのである。メモリ上の処理なので高速であること等のメリットがある。
横文字のコンポーネントがいくつか登場しました。改めて確認しておく。
tableBindingNavigator フォーム上のインターフェース、独自デザインで自作も可能。
tableBindingSource フォーム上のコントロールとデータベースを接続する機能
tableTableAdapter データの取得や変更の通知を管理、テーブルへのデータをDataSetに格納。
tableAdapterManagerデータを関連するデータテーブルに保存する機能を提供するコンポーネント。
tableTableAdapterとtableAdapterManagerの違いはよくわからない。しかし、Managerの登場が後なので、データの更新にはこちらを使うようである。UpdateAllメソッドがそれ。
tableTableAdapterの方はUpdateメソッドで、こちらでも更新は可能。ただし、エラーが発生する場合があるため、アダプターの Update メソッドを呼び出すコードは try/catch ブロック内に配置する必要がある。
自動生成されるtableBindingNavigatorSaveItem_ClickイベントはManagerよるUpdateAllで更新。try/catch ブロックはない。
初期設定のまま、実行するとデータグリッドにテーブルの全データが表示される。
これにはAdapterのFillメソッドが使われている。FillはSELECTコマンドの実行結果を格納している。検索には、これにフィルターを付加して実行させる。詳細は次回とする。
内部を理解するには結構大変である。
ここまである程度理解して、独自の機能を追加してコードを記述していく。
なかなか手に入らない、つぼだい。
3つのサイトを常時チェックしているが、品切れ状態が続いている。
小さいものなら、1つのサイトで何とかなるが半身で200g程度でも1000円以上する。(1180円)
半身250gは1500円。幻の高級魚である。
