Panelの次はTextBlockだよね。

文字列を表示させるためのコントロール。似て非なるものにLabelコントロールがある。
・TextBlockはTextプロパティ(string型)
・Labelは、Contentプロパティ(object型)
扱うレベルがはっきりと異なる。コントロールは特化されている方が速いので、文字列限定で言えば、TextBlockが速いかなと。
汎用性が高いのは、Labelだから、融通利くのはラベルなんだけど。
TextBlockの確認兼Panelに配置した時の様子を見たくなった。

<Window x:Class="TawamureDays.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
xmlns:nfc="http://nichia.jp/sys/foundation/component/gui"
Title="MainWindow" Height="350" Width="525">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition/>
<ColumnDefinition/>
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition/>
<RowDefinition/>
</Grid.RowDefinitions>
<Grid>
<TextBlock Name="TBlock003" Background="Gold">TextBlock003</TextBlock>
<TextBlock Name="TBlock002" Background="BurlyWood">TextBlock002</TextBlock>
<TextBlock Name="TBlock001" Background="Azure">TextBlock001</TextBlock>
</Grid>
<StackPanel Grid.Row="1">
<TextBlock Name="TBlock013" Background="Azure">TextBlock1013</TextBlock>
<TextBlock Name="TBlock012" Background="BurlyWood">TextBlock1012</TextBlock>
<TextBlock Name="TBlock011" Background="Gold">TextBlock1011</TextBlock>
</StackPanel>
<DockPanel Grid.Column="1">
<TextBlock Name="TBlock101" Background="Azure">TextBlock1103</TextBlock>
<TextBlock Name="TBlock102" Background="BurlyWood">TextBlock1102</TextBlock>
<TextBlock Name="TBlock103" Background="Gold">TextBlock1101</TextBlock>
</DockPanel>
<Canvas Grid.Row="1" Grid.Column="1">
<TextBlock Name="TBlock111" Background="Azure">TextBlock113</TextBlock>
<TextBlock Name="TBlock112" Background="BurlyWood">TextBlock112</TextBlock>
<TextBlock Name="TBlock113" Background="Gold">TextBlock111</TextBlock>
</Canvas>
</Grid>
</Window>

20120531_1.png

まあ、特にWidthやHeight指定していないから、こんなもんだろ。
TextBlockは文字列専用だけど、黒い文字列だけ表示するのかと思えば、そうでもない。

<Window x:Class="TawamureDays.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
xmlns:nfc="http://nichia.jp/sys/foundation/component/gui"
Title="MainWindow" Height="350" Width="525">
<Grid>
<TextBlock FontSize="20">
<Run FontSize="26" Foreground="Blue">T</Run>
<Run TextDecorations="Overline">awamure</Run>
<Run TextDecorations="Underline">works </Run>
<Italic>application</Italic>
</TextBlock>
</Grid>
</Window>

20120531_2.png

装飾なこともできるようだ。ただ、重そうなので、多用には注意かな。
スポンサーサイト
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

ドキュメント化可能

C#コード内に書いたコメントをドキュメント化(ヘルプファイル)にするのに、.NET1.1の頃は、NDocを使っていた。
でも、このNDoc、.NET2.0以降のサポートがないまま、開発が止まったような感じ(誰かが引き継いでいる?)。
NDOC日本語版
NDoc Online
2005年で更新が止まっている・・・
じゃあ、代替できるアプリないかなと探したら、ありました。
SandCastle
英語版だけども。まあ、英語を読めさえすれば、大体使える。
ドキュメント化できると思ったら、コメント書くモチベーションが上がりやすい、と良いなぁ。

続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

四捨五入したらまだ○○歳です。

計算系でよく使い、実装に悩んでいたのが、四捨五入。
.NET1.1時代ではdecimal.Roundの標準装備では、四捨五入はできていなかった。
.NET2.0以降はできるようになったけど。
数値を四捨五入するには?[2.0のみ、C#、VB]
理由も書いてくれているので助かります。

decimal.Round(1.05M, 1, MidpointRounding.AwayFromZero);

最後の引数がポイントかな。
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

データベース系の実装を如何にするかで悩んだ(2)

データベース系の実装を如何にするかで悩んだの続き。
方針:
・使う側(実装者)から見て、具体的な型(Type)を意識しないで使えるようにする。
・接続文字列は一箇所に記述すれば良いようにする。みんなで其処を参照する。
・接続とトランザクション、クエリ実行は分けて考える。

○具体的な型(Type)を意識しないで使えるようにする
具体的な型を意識させない、という事は、

new SqlConnection(...)

とか

new SqlTransaction(...)

とか

new SqlCopmmand(...)

等を実装者側に記述させないということになる。生成する為のメソッドを用意して、
それを使ってもらうようにするしかないか。戻り値のタイプをインターフェースにする。
○接続文字列は一箇所に記述すれば良いようにする。みんなで其処を参照する。
(案1)設定ファイルに書く
→変更には強い。いちいちビルドし直す必要はない。
 本番用設定ファイル、開発用設定ファイルを分けて作れば、逐一切り替える必要もない。
→接続先情報(パスワード)が丸見えなので、配置するフォルダに参照権限をつけておく必要がある。

(案2)staticクラスにstaticな文字列(或いはconst)で定義する。
→変更に弱い。接続先を変えるだけでもビルドが必要になる。
→開発に使用するDBと本番運用を行うDBは大抵違うサーバだから、逐一切り替える必要が有る。
 変え忘れによる、開発環境から本番DBへの更新、本番環境から開発DBへの更新というリスクがある。
→接続先情報がコード内に隠される。
大体において、案1が使われるかな。1人で開発する規模であれば、案2でも十分いけるけど。

○接続とトランザクション、クエリ実行は分けて考える。
接続とトランザクション制御1回分で、クエリ実行が1回だけとは限らない。
同じ接続で使用するDAO系クラスの数も1つとは限らない。
・接続とトランザクションを管理するクラス(例:DbConnectionManager)
・SQL実行に必要なオブジェクトを生成するクラス(例:DbProviderFactory)
・SQL実行を呼び出すクラス(例:DbTableDao)
に分けるようにする。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

DockPanelにはお世話になります。

DockPanelの性質をメモメモ。

<Window x:Class="TawamureDays.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
xmlns:nfc="http://nichia.jp/sys/foundation/component/gui"
Title="MainWindow" Height="350" Width="525">
<DockPanel>
<DockPanel.Resources>
<Style TargetType="Border">
<Setter Property="BorderThickness" Value="1"/>
<Setter Property="BorderBrush" Value="Black"/>
</Style>
</DockPanel.Resources>
<Border Height="30" DockPanel.Dock="Top">
<TextBlock Text="Top1"/>
</Border>
<Border Height="30" DockPanel.Dock="Top">
<TextBlock Text="Top2"/>
</Border>
<Border Width="50" DockPanel.Dock="Left">
<TextBlock Text="Left1"/>
</Border>
<Border Width="50" DockPanel.Dock="Left">
<TextBlock Text="Left2"/>
</Border>
<Border Width="50" DockPanel.Dock="Right">
<TextBlock Text="Right1"/>
</Border>
<Border Width="50" DockPanel.Dock="Right">
<TextBlock Text="Right2"/>
</Border>
<Border Height="30" DockPanel.Dock="Bottom">
<TextBlock Text="Bottom1"/>
</Border>
<Border Height="30" DockPanel.Dock="Bottom">
<TextBlock Text="Bottom2"/>
</Border>
<Label Background="AliceBlue">Body(Fill)</Label>
</DockPanel>
</Window>

20120530_1
この順番を変えるとどうなるか見てみる。(Labelは変えない)
続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

WPFの開発でまず使うのがPanel系のコントロール。

WPF4でウィンドウを新規作成した時は、

<Window x:Class="TawamureDays.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
Title="MainWindow" Height="350" Width="525">
<Grid>
</Grid>
</Window>

みたいな感じで作成される。
でも、経験上、トップをそのままGridコントロールにする事は滅多にない。
よく使うPanelは、
・DockPanel
・WrapPanel
・StackPanel
の3つ。Gridは偶に使うだけ。
ほとんど使われないのが、Canvasかな。

DockPanel
 上下左右にコントロールをへばり付かせるようなパネル。
名前の通り、ドッキングさせるパネル
メニューバーの配置とか、ステータスバーの配置とかが楽にできる。

StackPanel
 水平方向、或いは垂直方向にただただ配置するパネル。
やる事、やれる事がシンプルなので軽い。Gridよりは軽い。
StackPanelはそれ(軽さ)で重宝される。

WrapPanel
 折り返しができるStackPanel。折り返しができるのがポイント。
折り返せることに意味がある。

Grid
 格子状にコントロールを配置をできる。
別のGridと幅等を同期させる事も可能。
親戚にUniformGridというのがいる。
こいつにGridSplitterを連携させると、サイズ変更ができる。
また、Gridはコントロールを重ねて配置ができるので、それを利用することもある。

GridSplitter
Gridとセットで使われるスプリッタ。マススをドラッグすることでサイズ変更を可能にする。

Canvas
絶対配置ができるパネル系のクラス。Windows Forms系は大抵これだった。
ただ、WPFにおいて絶対配置するようなデザインをしないので、あまり使われない。
まあでも、ドラッグ機能をつければ、デザインによっては良い感じになるかも。
仕事上では、使った事はないかな。
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

XAMLエディターあれこれ

VS2010でなくても、XAMLを編集できたりする。
XAMLPad
Microsoft Windows SDKに入っているらしい。あれ?でもv7.1には入っていない?
KAXAML
テンプレートやスニペットもあって、結構楽しい。でも、64bit環境では不意に落ちることがある。
XamlPadX
まだ使ったことはない。
XamlCruncher
Clicl Onceでインストールが始まる。まだ使っていない。
XAML側のデザインを決めるときにはいいのかも。
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

メインメソッドとコマンドライン引数はどこだ?

WPFプロジェクトを新規作成すると、当たり前にあるはずのMainメソッドがない。
App.xamlの中身は空っぽだ。
ないわけがない。コマンドライン引数取りたり時、どうすんだ?どこいった?と探したら、
obj\Debug\App.g.csという。WPFが自動で生成するコード内にあった。
*.g.csや、*.g.i.csというファイルは、自動で生成されているクラス。XAMLファイル毎にできる。
じゃあ、このメインメソッドを自動生成させない時はどうするんだろ?と思った。
↓のリンク参照。
WPF と Main メソッド
なるほど。こうしないとコマンドライン引数取れないのか?といえば、そんな事はない。
WPFでコマンドライン引数を取得するには?[C#、VB、2.0、3.0、3.5]
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

クロージャを作った。

言語仕様から読み解くC# 3.0入門
関数を返す関数、メソッドを返すメソッド、一般的(?)にクロージャと呼ばれるらしい。
上のリンクにも例があるけど、まあ、加算器のようなクロージャを返すメソッドを作る。

using System;

namespace TawamureDays {

/// <summary>
/// 戯れるクロージャ用クラス
/// </summary>
public static class TawamureClosure {

/// <summary>
/// カウントアップ用クロージャを取得します。
/// </summary>
/// <param name="start">開始の値</param>
/// <param name="step">増加値</param>
/// <returns>クロージャ</returns>
public static Func<int> CountUp(int start = 0, int step = 1) {
var i = start;

return () => {
try {
return i;
} finally {
i = i + step;
}
};
}
}
}

使うときは、こんな感じかな

IList dataList = ...;
var countUp = TawamureClosure.CountUp(0);

foreach (var data in dataList) {
var idx = countUp();
//...
}

クロージャを使わなければ、こんなかんじか?


IList dataList = ...;
var idx = 0;

foreach (var data in dataList) {
//...
idx ++;
}

これでよくね?とか思うときも多々ある。まあ、役割以外の事ができないので、他のものに間違って流用するミスが少なくなるかな。
通常のクラスは、データに対してメソッドがあるけど、クロージャはその逆で、メソッドに対してデータがあると考えたほうがいいかな。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

WPFでデザインモードかどうかを判定しよう。

デザイン中の時には動い欲しくない処理は往々にしてあるものだ。
デバッグ時に強制的にブレイクさせる、System.Diagnostics.DebuggerクラスのBreakメソッドをデザイン時に動かしてしまった時にゃ、デザインビューが壊れちまうんだこれが(経験済み)。
そんな時のためのメソッド。

using System.Windows;

public static class Utils {

/// <summary>
/// デザインモードかどうかを取得します。
/// </summary>
/// <param name="dpObj">操作対象オブジェクト</param>
/// <returns>true:デザインモード</returns>
public static bool IsInDesignMode(DependencyObject dpObj) {
return System.ComponentModel.DesignerProperties.GetIsInDesignMode(dpObj);
}
}

当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

データベース系の実装を如何にするかで悩んだ

C#におけるデータベース接続、操作に関わるクラスは、たくさんある。
現在の開発で主に使うのが以下のクラス(なんとかマッピングやEntity-Framework等は使ってない)。

System.Data.SqlClient.SqlConnection
接続文字列、接続状態を保持するクラス。
System.Data.SqlClient.SqlCommand
SQL Server データベースに対して実行する Transact-SQL ステートメントまたはストアド プロシージャを表すクラス
System.Data.SqlClient.SqlDataAdapter
DataSet へのデータの格納および SQL Server データベースの更新に使用される、一連のデータ コマンドおよびデータベース接続を表すクラス。
System.Data.SqlClient.SqlParameter
SqlCommandに対するパラメータを表すクラス。パラメータクエリに使用される。
System.Data.SqlClient.SqlTransaction
SQL Server データベースで作成する Transact-SQL トランザクションを表すクラス。トランザクション制御を行うメソッドを提供する。
System.Data.SqlClient.SqlDataReader
SQL Server データベースから行の前方向ストリームを読み取る方法を提供するクラス。
普通に使うだけでも、これくらいのクラスに関わる事になる。
続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

値を強制するのとデフォルト値と

依存関係プロパティや、添付プロパティで持っている機能に「強制」がある。
その名の通り強制なので、ローカル値よりも優先順位が高い。
デフォルト値は、優先順位が最も低い値であるものの、既定値なので、頻繁に設定する。
自分で依存関係プロパティや添付プロパティを作成するときはなおさらだ。

最近仕事で実装した中にまさに強制を実装したばかりだったので、メモっておこう。
ListBoxやDataGrid等のItemsControl系のアイテムをドラッグ・アンド・ドロップできるようにするためのビヘイビアクラスを作った。
その際に作成した依存関係プロパティが↓のようなもの。

/// <summary>
/// 移動中のアイテムの透明度を取得/設定します。
/// </summary>
public double DragAdornerOpacity {
get {return (double)GetValue(DragAdornerOpacityProperty);}
set {SetValue(DragAdornerOpacityProperty, value);}
}

/// <summary>移動中のアイテムの透明度</summary>
public static readonly DependencyProperty DragAdornerOpacityProperty =
DependencyProperty.Register("DragAdornerOpacity", typeof(double),
typeof(DragDropBevavior),
new UIPropertyMetadata(0.5D, null, OnCoerceDragAdornerOpacity));

/// <summary>
/// DragAdornerOpacityプロパティ(移動中の透明度)の値を強制するメソッド
/// </summary>
/// <param name="dpObj">対象オブジェクト</param>
/// <param name="value">値</param>
/// <returns>強制された値</returns>
private static object OnCoerceDragAdornerOpacity(DependencyObject dpObj, object value) {
var opacity = System.Convert.ToDouble(value);

if (opacity < 0D) {
//0より小さければ、0.1を返す
return 0.1D;
} else if (opacity >= 1D) {
//1以上であれば、0.9を返す
return 0.9D;
}

return value;
}

この「OnCoerceDragAdornerOpacity」というメソッドが強制を行うためのメソッド。
強制する必要があるかどうかもチェックしている。
この透明度を表すOpacity(double)が取れる値の範囲は0以上1以下なのだ。
マイナス値や1を超える値を設定しても動作させるために、この強制が必要となる。
なお、プロパティ作成時に設定している「0.5D」がデフォルト値。
仕事では、アニメーションなんかはあまり使わないので、強制は滅多に使わない。デフォルト値はいっぱい使う。
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

constとstatic readonlyの違い。

今更ながら迷ってしまった実装、「const」と「static readonly」。
いずれも定数定義に使われる。定数定義の目的は、マジックナンバーや、文字列定数入力ミスの削減にある。どっちを使うか迷うんだ。大して違わない?と思うから。
調べてみると、結構違う事がわかった。
readonlyとconstの使い分けより、両者の違いを箇条書きで。
constはコンパイル時に値がそのまま埋め込まれる。
 →実行速度は速くなる。でも、サイズは増える。
 →switch文や、デフォルト引数に使える。
 →アセンブリ(*.dll)を入れ替えても、参照するアセンブリ側に変更した値は使用されない。
・static readonlyは、アセンブリロード時に適用される。
 →変数は共有されるので、constに比べサイズは小さくなる。
 →switch文や、デフォルト引数には使えない。
 →アセンブリ(*.dll)を入れ替えれば、ロードし直され、変更した値が使用される。
そういえば、埋め込みやったなぁ、と今更思ってしまった。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

変更通知機能

依存関係プロパティ、添付プロパティには、変更通知機能がある。
名前の通り、設定された値が変更すると通知する。要するに、
変わったら教えるよ
だ。この機能が、StyleやTemplateのTriggerにも活用されている。

<Border DockPanel.Dock="Top" Height="100">
<Border.Resources>
<Style TargetType="Border">
<Setter Property="Background" Value="AliceBlue"/>
<Style.Triggers>
<Trigger Property="IsMouseOver" Value="True">
<Setter Property="Background" Value="Chocolate"/>
</Trigger>
</Style.Triggers>
</Style>
</Border.Resources>
</Border>

Borderコントロール内にマウスが入ると、背景色が変わる(抜粋)。
これは変更通知機能を使っているからこそできるもの。
Windows.Forms系ならマウスイベントをフックして~、背景色変えて~の実装が必要だったけど、
この程度なら、XAMLだけで済むというのが、XAMLファミリーのすごいところ、かなぁ。
なお、この変更通知、自分で検知して処理を加える事ができる。

/// <summary>
/// 依存関係プロパティをCLRプロパティの様に扱う為のプロパティ
/// </summary>
public bool IsJumping {
get {return (bool)GetValue(IsJumpingProperty);}
set {SetValue(IsJumpingProperty, value);}
}

/// <summary>依存関係プロパティ本体</summary>
public static readonly DependencyProperty IsJumpingProperty =
DependencyProperty.Register("IsJumping", typeof(bool),
typeof(MainWindow),
new UIPropertyMetadata(false, OnIsJumpingPropertyChanged));

/// <summary>
/// IsJumpingプロパティ変更通知イベントハンドラ
/// </summary>
/// <param name="dpObj">変更発生元</param>
/// <param name="e">イベント引数</param>
private static void OnIsJumpingPropertyChanged(
DependencyObject dpObj, DependencyPropertyChangedEventArgs e) {

if ((bool)e.OldValue) {
//...
}

if ((bool)e.NewValue) {
//...
}
}

UIPropertyMetadataの引数にメソッドを渡すことで変更通知を検知できる。
メソッドはstaticなので、インスタンスな変数等アクセスしようと思うなら
引数のDependencyObjectをキャストして使うしかない。
ここで良くあるのが、イベントへのハンドラ(メソッド)を登録する実装。

/// <summary>
/// IsJumpingプロパティ変更通知イベントハンドラ
/// </summary>
/// <param name="dpObj">変更発生元</param>
/// <param name="e">イベント引数</param>
private static void OnIsJumpingPropertyChanged(
DependencyObject dpObj, DependencyPropertyChangedEventArgs e) {

if ((bool)e.NewValue) {
var window = Window.GetWindow(dpObj);

if (window != null) {
window.PreviewMouseLeftButtonDown +=
new MouseButtonEventHandler(Window_PreviewMouseLeftButtonDown);
}
}
}

だけど、この登録したメソッドは、誰も削除してくれない。
不要になったら、自前で削除するしかない。
ほうっておくと、メモリリークの元になる。じゃあ、どうするの?ってのはまた別に書こう。
続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

添付プロパティ(Attached Property)

依存関係プロパティに並んで、大事なのが、添付プロパティと呼ばれる機構。
依存関係プロパティは、そのプロパティを持つクラスに対してのみ設定できたのに対して、
添付プロパティは、自身以外に設定するプロパティ。自身以外のものに、自分専用のプロパティを添付するって感じかな。
相手に頼んで持ってもらう自分用の情報付タグ?そんな感じ。
これで大概の事ができてしまう。開発では、コントロールを継承する代わりに、添付プロパティを使いまくった。特にDataGrid周り。
仕事では、セルのマージまでやっちまったい。

よく使うのが、DockPanelが持つDockプロパティ。
既出のプロパティで言えば、TextElementのFontSizeプロパティとか。
以下はDockPanelのサンプル

<Window x:Class="TawamureDays.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<DockPanel>
<Label Name="lbTitle" DockPanel.Dock="Top">C#と戯れる日々</Label>
<Label DockPanel.Dock="Top">Edit by チャプターマン</Label>
<Label DockPanel.Dock="Top">Since: 2012/05/14(火)</Label>
<StatusBar DockPanel.Dock="Bottom">
<StackPanel Orientation="Horizontal">
<TextBlock VerticalAlignment="Center">this place is status bar.</TextBlock>
<Button Margin="13,1,1,0">ボタンだよ</Button>
</StackPanel>
</StatusBar>
<StackPanel Orientation="Horizontal" HorizontalAlignment="Center" TextElement.FontSize="25"
DockPanel.Dock="Bottom">
<Button Content="閉じる" MinWidth="75"/>
<Button Content="OK" MinWidth="75"/>
<Button Content="CANCEL" MinWidth="75"/>
</StackPanel>
<ListBox Name="List1">
<ListBoxItem>C#</ListBoxItem>
<ListBoxItem>WPF</ListBoxItem>
<ListBoxItem>その他</ListBoxItem>
</ListBox>
</DockPanel>
</Window>

DockPanelの描画時に、子コントロールをどこにドッキングさせるかを添付プロパティでもたせている。
子コントロールを派生させる事なく、欲しい情報をもたせている。
ちなみにC#上でも、添付プロパティの値を取得することはできる。

var dock = DockPanel.GetDock(lbTitle);

添付プロパティは、依存関係プロパティのようにCLRプロパティではなく、SetXXXXとGetXXXXのメソッドを持つ。
これを利用できる。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

ロギング機能って大事。

ログファイル(ロギング機能)って、小規模なアプリならそれほどでもないけど、サーバサイドや中規模以上のアプリには必ず必要となる。
ロギング機能がない事を考えると・・・

1.今アプリが何やってるかわからない。
2.扱っているデータが正しいか確認できない(常にブレイクできる保証はない)。
3.運用時のエラー特定に時間がかかりすぎる。或いはわからない。

仕事にならない・・・でも、ロギング機能があれば、これらが可能になる。
1.今アプリが何やってるかわからない。
→現在実行中のAPIクラス、メソッドを出力する。かかったコスト(時間)も出力できればなおいい。
 実行されたSQLが確実に出力させる(開発時のみ)。
2.扱っているデータが正しいか確認できない(常にブレイクできる保証はない)。
→メソッド開始前に入力データの内容を出力させる事で、INが何かがわかる。
 ただ、運用時は、常々出す必要はないと感じた(エラー発生時のみくらいかな)。
3.運用時のエラー特定に時間がかかりすぎる。或いはわからない。
 例外発生によるエラーは確実にログに出力させる必要がある。できればStackTraceも。
ただし、ログファイルは単に出せば良いってもんじゃない。
多すぎる
 ・肝心な情報が、どうでもいい情報に埋もれる。検索するのが大変になる。見逃すリスクが高くなる。
 ・放置するとHDDを圧迫する。置き場所に困る
 ・アプリケーションのパフォーマンスに影響する(いちいち同期させるので)。
少なすぎる
 ・そもそも欲しい情報が入っていない。
 ・上記の理由から、結局誰も見ないし、活用しないし
 ・何かトラブルがあった時にログファイルを調査しても、結局わからない事が多い。

エラーファイル内を素早く走査できるなら、前者がいいかな。サイズの心配だけだし。
情報の少なすぎるログファイルって、結局出力しない方がマシ。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

拡張メソッド

会社の同僚さんに聞かれたので、ついでにメモっておくことにしよう。
C#3.0以降から追加された機能に拡張メソッドがある。

これは、クラスを拡張することなく、メソッドを追加しよう!

というコンセプトらしい。使う側から見れば、

まるでそのクラス自身のメソッドを使っているかのように実装できるメソッドを作ろう!

なんだけど。有名な拡張メソッドがLINQが持つ、IEnumerable<>クラスを拡張するメソッドの数々だったりする。
○ルールとか制約とか
・拡張メソッドの主(メソッドが操作する型)をthisで渡す。
・拡張メソッドは、static classにしか実装できない。
・拡張メソッド自身もstaticメソッドのみ。
・あくまで外部のメソッドなので、内部な変数やメソッドにアクセスできない。
○方針
thisで渡されたオブジェクトに対して、nullチェックをしてはいけない。
○メリット
 usingさえすれば、拡張メソッドを持つクラスの名前をしる必要がないし、記述する必要もない。
 インターフェースに対して、共通のメソッドを拡張メソッドで提供すると、サブクラスでの実装が必要なくなる(当然制限あり、実装しすぎ要注意)。
○デメリット
 実際の実装箇所を探すのに苦労する(VS2010等であれな。「定義を参照する」で解決する)。
○参考記事
 拡張メソッド
 拡張メソッド (C# プログラミング ガイド)続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

クラスはシンプルが良い(DAO編)

DAOクラスの方針も大体似たような感じになる。ここで言うDAOはデータベースへアクセスして、検索したり、更新したりするSQLを発行し、その結果をAPIクラスに返すクラスの事。

・SQL等は使い回せるならできるだけ使いまわすが、無理にしなくても良い。
 →無理にしようとすると、結局使い方が複雑になってしまう。
・1つのメソッドでなんでもしようとしてはいけない。
 →融通効かなくなるから。引数なんかで条件分岐すると、いつか収拾がつかなくなる。
・戻り値として返すリストのインスタンスは都度生成する。
 →リストのインスタンスを使いまわすと、ろくな事にはならない。意図しない箇所でクリアされるとか。
・メソッドの引数や戻り値は、抽象的な方が良い。
 変更した時の影響範囲をできるだけ小さくできる(その努力ができる)。
・SQLの実行等には、できるだけログを残す
 SQLServerであれば、SQLプロファイラなんかがあるから良いとか言われそうだけど、いろんな開発(複数のプロジェクト)が同じDBを使うと、自分が実行したログを探すのも一手間になる。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

依存関係プロパティに適用される優先順位(基本値)

依存関係プロパティにおける値決定プロセスのSTEP1、基本値について試してみる。
依存関係プロパティは、色々な所からその値を設定できる。値を提供する箇所を「プロバイダ」なんて呼ぶっぽいけど。
大体は、StyleやTemplateやテーマ(Theme)だったりする。
以下のサイト参考
依存関係プロパティ値の優先順位
直訳ではないけど、時々わかりにくいので、原文も
Dependency Property Value Precedence
既出だけど、もう一回載せておく。
Dependency Properties
それによると、基本値決定の優先順位は、

1.ローカル値(Local Value)
2.TemplatedParent テンプレートのTrigger(Parent Template Trigger)
3.TemplatedParent テンプレート(Parent Template)
4.スタイルのトリガー(Style Triggers)
5.テンプレートのトリガー(Template Triggers)
6.スタイルの setter(Style Setters)
7.既定の(テーマ)スタイルトリガー(Default (Theme) Style Triggers)
8.既定の(テーマ)のスタイル(Default (Theme) Style Setters)
9.包含継承(Property Value Inheritance)
10.デフォルト値(Default Value)

となる。
上になるほど、優先順位は高い。
上の順序で適用可能な値を検索し、発見した時点で検索を止めるんだろう。
だから、ローカル値(1)に設定すると、Style Trigger(5)に反応しない。
包含継承(9)って意外に低いな。デフォルト値(10)は最後の砦ってやつか?続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

StackPanel配下のコントロールにFontSizeを継承させる。

依存関係プロパティの包含継承を使って、StackPanelの要素にのみFontSizeを設定する。
StackPanelそのものは、FontSizeプロパティを持っていないけど、以下のようにできる。

<Window x:Class="TawamureDays.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<StackPanel>
<Label>C#と戯れる日々</Label>
<Label>Edit by チャプターマン</Label>
<Label>Since: 2012/05/14(火)</Label>
<ListBox>
<ListBoxItem>C#</ListBoxItem>
<ListBoxItem>WPF</ListBoxItem>
<ListBoxItem>その他</ListBoxItem>
</ListBox>
<StackPanel Orientation="Horizontal" HorizontalAlignment="Center"
TextElement.FontSize="25">
<Button Content="閉じる" MinWidth="75"/>
<Button Content="OK" MinWidth="75"/>
<Button Content="CANCEL" MinWidth="75"/>
</StackPanel>
<Button Content="閉じる"/>
</Window>

20120520_3

TextElementのFontSizeプロパティが大元締めで、他のコントロールのFontSizeプロパティは、TextElement.FontSizePropertyをAddOwnerしているだけなので、影響を受けるのかなぁ。
ま、スタイル使えば、一緒なんだけどね。
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

依存関係プロパティの包含継承

依存関係プロパティの機能の1つに包含継承がある、と書かかれても、なんのこっちゃ?と思った。
親要素で設定した値を子が引き継ぐ。わかりやすい例がフォントサイズだ。どこのサイトの例でも出てくるくらいだし。

<Window x:Class="TawamureDays.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
FontSize="20"
Title="MainWindow" Height="350" Width="525">
<StackPanel>
<Label>C#と戯れる日々</Label>
<Label>Edit by チャプターマン</Label>
<Label>Since: 2012/05/14(火)</Label>
<ListBox>
<ListBoxItem>C#</ListBoxItem>
<ListBoxItem>WPF</ListBoxItem>
<ListBoxItem>その他</ListBoxItem>
</ListBox>
<Button Content="閉じる"/>
</StackPanel>
</Window>

画面は、↓のようになる。
screen_0520_1
たしかに、Windowに設定したフォントサイズを、子要素が引き継いでる。
引きついていなければ、フォントサイズは前のままのはずだし。
じゃあ、Window配下の要素は、全部そうなるんだ!とか思ったら違ってた。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

クラスはシンプルが良い(Container編)

オブジェクト指向を過信して構造を複雑化しない。するならするで、インスタンスの作り方が明確になるようにする。多少手順を間違えても、Null参照が発生しないようにする。
仕事においては、帳票や、画面に表示するリストに表示させる項目を元にクラスが作られる。
DB内のテーブル通りにクラスを作り、クラスも同じような関係を構築しようと思ってた時があった。結果、複雑化して、インスタンス生成時にエラーで落ちる・・・昔ちょくちょくやった失敗である。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

DependencyProperty(依存関係プロパティ)

これもWPF実装時に、理解する必要のある、値を保持するための機構。

第3回 XAMLコードから生成されるプログラム・コードを理解する
より、依存関係プロパティは、以下のような目的を持っている。

包含継承: 親要素で設定した値をそのまま継承して使うための機構。
リソース: 1カ所で定義したオブジェクトを複数カ所から参照するための、リソースの定義/参照機構。
スタイル: HTMLでいうところのCSSのようなスタイル設定機構。
データ・バインディング: モデルとビューの間など、異なるオブジェクト間で値を結び付ける(一方での値の変更を他方に通知し、即座に反映させる)機構。

WPF実装の肝であるデータ・バインディングと密接な関係にある。
というか、依存関係プロパティ(あるいは添付プロパティ)でなければ、データ・バインディングはできない。
定義方法は見た目ややこしいけど、VS2010等のIDEには、コードスニペットが用意されている。
"propdp"で、TABキーを押すと、実装のテンプレートが生成される。便利になったもんだ。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

クラスはシンプルが良い(Utility編)

Logic系クラスが提供するメソッドとは違い、「あれしてこれしてそれもする」なんていうメソッドはいらない。
できるだけ1つのメソッドには、1つの目的を達成させる。まあ、多くて2つくらいか。
自分が好んで使うメソッドとして、文字列に関するメソッドがある。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

VisualTreeとLogicalTree

WPFで欠かせない単語(知識)が、VisualTreeLogicalTreeの2つ。
LogicalTree
 ●WPFのUIを構築するツリー構造のオブジェクト
 ●イベントが上り下りするのもこのTree。
 ●Treeの構造は静的。動的に追加・削除したりしなければ変わらない。
VisualTree
 ●LogicalTreeをより詳細に展開して、Visualなコンポーネントを全部ぶら下げたツリー構造のオブジェクト
  ただし、LogicalTreeの全要素がVisualTree内に存在するわけではない
  →System.Windows.Media.Visualか、System.Windows.Media.Visual3Dを継承したクラスのみがVisualTreeの要素となる。
 ●Treeの構造は動的。テーマ(内のテンプレート)の適用だけであっさりと構造が変わる。
 とある書籍のサンプルを参考に以下のようにXAMLを編集してみた。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

クラスはできるだけシンプルが良い(Logic編)

クラス設計、メソッド設計における指針は、
できるだけシンプルが良い
にしている。だって、複雑なのを作っても、後(数ヶ月後)で困るし。
SEだろうとPGだろうと、暇な人は少ない。
いつまでも前の仕事で使ったメソッドの複雑な引数とか、クラスの構造を記憶している人も少ない。
引数がいくつもあって、更に何のコメントもないメソッドをどうしろと?

/// <summary>
/// 何するメソッドだよ!
/// </summary>
/// <param name="id"></param>
/// <param name="code"></param>
/// <param name="ucode"></param>
/// <param name="items"></param>
/// <param name="del"></param>
private void CreateProduct(int id, string code, string ucode, string[] items, bool del) {
//...
}

せめて、何をどうするかくらいは書け!と突っ込みたくなる。
閑話休題、どうシンプルにすれば良いかをメモる事にする。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

クラスを如何に作るか?≒基本的な設計思想

初心者の頃に悩んだのが、
まずどんなクラスを作れば良いのか?
だったりする。今だに悩むことがあるけども。オブジェクト指向に拘ると、碌なことにはならないってのが経験からわかってきたくらいか。どのクラスにも入りそうにないものが出てくるんだよなぁ。
色々な本とか読んでも、サンプルはあるんだけど、クラスの設計思想までは教えてくれない。
で、元の会社の先輩である、師匠のクラスの作り方を見て、大体以下のようなカテゴリ(UMLで言えば、「ステレオタイプ」かな)に分けて作ることにしている。続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0

そのURLは本物か?

WPF4で、新規ウィンドウを作成した時にできるXAMLはこんな感じ。
<Window x:Class="TawamureDays.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<Grid>

</Grid>
</Window>
xmlnsは、そのまんまXAML用の名前空間。
その中にあるhttp:で始まるURLをブラウザに入力しても何も出てこない。
何も出てこないけど、ビルドは通るし、実行もできる。このURLは、アセンブリ(*.dll)内で、System.Windows.Markup.XmlnsDefinitionという属性(Attribute)クラスを使って、CLRの名前空間とXMLの名前空間を関連付ける。
この属性クラスは、自作のクラスに対してもできたりする。AssemblyInfo.csに上記の属性クラスを使う。

[assembly: System.Windows.Markup.XmlnsDefinition(
"http://tawamuredays.com/controls", "TawamureDays.Controls")]

こうしておけば、使う側としての名前空間定義は、

<Window x:Class="TawamureDays.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:twd="http://tawamuredays.com/controls">
</Window>
のようになる。このURLは複数の名前空間ともマッピングできるので、名前空間が複数になったとしても、1つの宣言で済ませられる。ただし、このURLでの宣言は、同じアセンブリ内では使えない。Orz
まあ、特に不都合はないんだけどさ。
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: WPF4 | コメント: 0 | トラックバック: 0

現在仕事で使っているもの

C# 4
バージョンも4になってしまった。主に使うのは、Generic、ラムダ式、LINQかな。4からの技術でいえば、Tupleとか。
WPF
Windows.Forms系より、カスタマイズが楽にできるのがでかい。しかし、パフォーマンスが・・・
WCF
Webサービスのようなもんだけど、もっと色々な事ができるらしい。
続きを読む
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: 未分類 | コメント: 0 | トラックバック: 0

サイドバー背後固定表示サンプル

当ブログに書かれたソースコードは流用自由です。

バグ、スペルミス等はありうる事です。

ご利用の際は自己責任でお願いしますm(_ _)m