先日書いた画面が表示された直後に入力値の妥当性検証を行い画面にフィードバックをする方法ですが、MSDNフォーラムの元質問者の方からコメントをいただけました。 私の方で悩んでいた部分としては、初期化時にエラーにしたいのではなく、「画面初期化時はエラーの値が入っていてもエラーにしない」という処理を実装しようとしております。 現状、一応それらしい動きにはなってきているのですが、「エラー値&エラー表示無し」のコントロールにフォーカスを当てて、値を変更せずにLostFocusした時に、エラーを表示するという部分が突破できていません。要件を整理すると 初期表示では入力にエラーがあってもエラー表示はしない TextBoxのでフォーカスが外れたタイミングで検証を行わせたい 入力内容を変更してない状態でもフォーカスが外れたタイミングで検証を行わせたい ということになると思います。 先日のサンプルをちょっ
どーも最近、ダメな子扱いされがちな LINQ to SQL ですが、クエリ結果を(ほぼ)透過的にキャッシュすることで実行速度を約3倍に加速してみました。 使い方はひじょーにカンタン。 通常 var connectionString = Properties.Settings.Default.Database1ConnectionString; using (var db = new DataClasses1DataContext(connectionString)) { var array = db.Products.Where(__ => __.Price > 500).OrderBy(_ => _.Price).Take(200).ToArray(); } みたいに書くところを var connectionString = Properties.Settings.Default.Dat
TextBox を使う場合、数値以外は入力させたくないというケースって結構あると思います。Window のイベントハンドラで対処してもいいし、TextBox を継承してもいいとは思うのですが、より汎用的に使いまわすには「添付ビヘイビア」がお勧めです。添付ビヘイビアさえ用意しておけば、後は XAML で定義するだけなので、使う側から見てもとっても扱いやすくなります。 「添付ビヘイビア」に関してはかずきさんの以下の記事を参考にさせて頂きました。 テキストボックスをフォーカスがくると全選択状態にしたい かずきさんのブログは、他にもコアな情報がたいへん多いのでお勧めです。(引っ越し前後で記事が別れているようですが・・・) まず「添付ビヘイビア」のコード XAML はこんな感じになります。 #2010/12/07 追記 上のコードは、クリップボード経由で数値以外のデータが貼り付けられてしまいます。
ObjectContext は、メモリ内オブジェクトのコンテナーを表します。 オブジェクト コンテキストは、他のクラスやインターフェイスと連携して、オブジェクトの ID、状態、オブジェクトのプロパティの元の値と現在の値を管理し、キャッシュ内の各オブジェクトに対して行われた変更を追跡します。 オブジェクト コンテキストにオブジェクトをアタッチする方法については、「オブジェクトのアタッチとデタッチ (Entity Framework)」を参照してください。 ここでは、変更追跡、ID 解決、および状態管理がオブジェクト コンテキストでどのように行われるかについて説明します。 変更の追跡 オブジェクト グラフの変更追跡情報は、アタッチされている各オブジェクトについて ObjectContext が作成する ObjectStateEntry オブジェクトに格納されます。 ObjectStateEnt
INotifyPropertyChangedインターフェースでお馴染みのPropertyChangedイベントですが、これのイベントハンドラのコードが気に入らない。というか書いてて、ちょっとなんだかなぁと思ってしまいます。 例えば、以下のようなNameプロパティとAgeプロパティを持ったINotifyPropertyChangedインターフェースを実装したPersonクラスがあったとします。 public class Person : INotifyPropertyChanged { private string _name; public string Name { get { return _name; } set { if (Equals(_name, value)) return; _name = value; OnPropertyChanged("Name"); } } priv
Vim Advent Calendar 2012 の 173 日目の記事です。 今回は C# を書くのに便利な OmniSharp と言うツールを紹介します。これさえあれば、エディタとしての Visual Studio はもう必要ありません! 経緯 (興味ない人はここは飛ばしてインストールのところから読むと良いです) 先日、OmniSharp なるものの存在を教えてもらいました。 @thinca これってでどうなんでしょう URL 2013-05-09 23:47:26 via YoruFukurou to @thinca @mizchi お、面白そうですね!私は知らなかったです。明日あたり見てみますー。ありがとうございます。 2013-05-09 23:51:36 via tweetvim to @mizchi と言うわけで調査してみることにしました。 様々な罠にかかりつつ、ソースコード
この記事の以下の例では、この分野の一般的なデータ ソースを使用します。 public enum GradeLevel { FirstYear = 1, SecondYear, ThirdYear, FourthYear }; public class Student { public required string FirstName { get; init; } public required string LastName { get; init; } public required int ID { get; init; } public required GradeLevel Year { get; init; } public required List<int> Scores { get; init; } public required int DepartmentID { g
●Bindingマークアップ拡張の書き方 これまでの例では、Bindingマークアップ拡張を単に「{Binding X}」というように記述してきたが、Bindingマークアップ拡張にはさまざまなプロパティがあり、データ・バインディングの挙動を細かく設定することができる。以下、主要なものをいくつか紹介していく。 ○データ・バインディングの向きとタイミング Modeプロパティで、データ・バインディングの向きとタイミングを指定できる。Modeプロパティに対して設定できる値は以下のとおりである。 OneTime: UI要素生成時に一度だけ、ソース・プロパティの値を読み出してターゲット・プロパティに与える。 OneWay: ソース・プロパティが変更された際に、ターゲット・プロパティに変更を反映させる(逆は行わない)。 OneWayToSource: ターゲット・プロパティが変更された際に、ソース・プ
概要 LINQ to SQL で使われる Table クラスなどは IQueryable と IQueryProvider インターフェースを実装しています。 これら IQueryable および IQueryProvider は、 LINQ クエリ式から「式木」を構築する。 構築した式木を解釈して、独自のクエリ処理を行う。 というような機能を提供するインターフェースです。 一度、式木(実行可能コードではなくて、プログラム中で読めるデータ)になるので、 IQueryable の実装次第で様々な機能を提供することができます。 となると当然、IQueryable を実装して、独自の LINQ プロバイダを作成したいとき、 クエリ式 → 式木の構築手順 式木を独自に処理 の2つのことを理解しておく必要があります。 後者は要するに、式木に関する理解があればできることです。 なので、ここでは、前者の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く