2005-09-08
MSIL/ILによるHello Worldの次はCodeDomのHello Worldの実現。 以下のようなソースコードをCodeDomにより生成、コンパイル、実行してみる。 生成するソースコード namespace CodeDomTest { using System; public class HelloWorld { [STAThread()] public static void Main() { System.Console.WriteLine("Hello World"); } } } HelloWorldクラスのソースコードを生成するCodeDomによるアプリケーション using System; using System.Text; using System.IO; using System.Reflection; using System.CodeDom; using S
|[亜-鄢] - Kazzz's diary
日本語を検索する場合に使う正規表現。Shift_JISの範囲であればまずこれで足りる。
![|[亜-鄢] - Kazzz's diary](https://cdn-ak-scissors.b.st-hatena.com/image/square/aa37ed08f00c43e75ae169497fd518ff471af0f8/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729891158%2F6435988827677002641%2F1365598114)
db4o その10(NQの不具合とキャッシュ) - Kazzz's diary
db4oのネィティブクエリ(NQ)だが、使い方によっては意図しない結果になる不具合?があることが判ったので書いておく。 今までのサンプルでも使用した"roster.db"で以下の順で処理を行うとする。 守備位置が"SS"である選手をNQで検索 (D.Jeterが結果に掛かるはず) 守備位置が"SS"である選手の守備位置を"3B"に変更してコミット 守備位置が"SS"である選手をNQで検索 (D.Jeterは結果に掛からないはず) この通りの処理を以下のコードで実行してみよう。 ObjectServer os = Db4o.openServer("roster.db", 0); ObjectContainer db = os.openClient(); try { printResult(nqForPosition(db, "SS"), "NQ for Pos = 'SS'"); Objec
バイオリン奏者と詐欺師(Fiddler)
各所で紹介されているので今更だが、最近お気に入りなのが"Fiddler"という名の、.NETで書かれたWindowsプラットホーム(というかWinINET)専用のHTTPモニタ/デバッガだ。 Fiddler HTTP Debugging Proxy 他のよくあるHTTP-Snifferと違い、IEのプロキシ設定を頼りに動くので面倒な設定はいらないし、IEで行っているHTTP通信ほぼ全てをリアルタイムでトレースして、内容をいろいろな形式(ヘッダ、ツリー、テキスト、16進、等)でデコードしてチェックすることができる。また、GZipエンコードされた圧縮データをデコードしてみることもできるのだ。(.NET2.0ベースとなったFiddler2.0ではHTTPSで暗号化された電文にも対応するようだ) 軽快に動くしこれだけでも非常に有用なツールなのだが、Fiddlerが非凡なのはHTTPクライアントとし
HttpWebRequest#AllowWriteStreamBufferingプロパティとHTTPヘッダ - Kazzz's diary
このプロパティ、ドキュメントには書いていないが、エンドポイントから送信するデータをメモリ上にバッファリングするか否かを指定することで、同クラスのSendChunkedプロパティ又はContentLengthプロパティと連動するので注意が必要だ。 というのも、消費メモリを少しでも節約しようと標題のプロパティをfalseに設定して、サーバ(Tomcat)とXML(XMLoverHTTP)通信すると以下の例外が発生したからだ。 Exception: System.Net.ProtocolViolationException Message: AllowWriteStreamBuffering が無効にされているときに書込み操作を実行するには、ContentLength を負でない数に設定するか、または SendChunked を true に設定する必要があります。 Source: System
Control#SelectNextControlメソッドとデータバインド - Kazzz's diary
WindowsFormsで双方向のデータバインドを行っている場合、バインドしたコントロールのプロパティ値と対応するデータソースオブジェクト(DTO)のプロパティは互いを更新しあうようになる。 例えばテキストボックスのTextプロパティと、PersonDTOという単純なクラスのNameプロパティを双方向データバインドした場合 1. コントロールのTextプロパティ値変更 -> PersonDTOのNameプロパティ変更 2. PersonDTOのNameプロパティ変更 -> コントロールのTextプロパティ値変更 これらが自動化されるわけだが、前者の方向のバインド処理が実施されるタイミングつまりコントロールのプロパティ値がデータソース側に反映されるタイミングは、Bindingクラスのインスタンスを生成した際のパラメタであるDataSourceUpdateMode列挙体の値に依存する。 Dat
ラジオボタンの「ホット状態」を描画する - Kazzz's diary
WindowsXPのビジュアルスタイルが有効なGUIでは、「ホット(Hot)状態」と呼ばれる、マウスがコントロール上をポイントしている際に、強調表示するエフェクトが描画される。 これを知った当初はああ、また実装するコードが増えるじゃないか、なんて面倒な機能を追加してくれたもんだと嘆いたのだが、先日のエントリカスタムコントロール(その3)で紹介した、RadioButtonRendererクラス等のビジュアルスタイルに対応した描画クラスは、この"ホット状態"を容易に描画することができる。 protected override void OnPaint(PaintEventArgs e) { string caption = "ホット状態に対応"; Size textSize = TextRenderer.MeasureText(caption, this.Font); RadioButtonS
Sandcastle script & configuration utility - Kazzz's diary
Sandcastle Blogを始めとして、以前に紹介したいくつかのサイトでは、SandCastleを使ってVisual Studioが吐いたXMLコメントを新MSDN風のHTMLヘルプ形式(chm)のドキュメントに変換する方法が書かれていたが、その方法で使用されるバッチファイルを自動で出力してくれるユーティリティがCodeProjectに掲載されていた。 Sandcastle CHM-compile BAT script & configuration utility このツールは.NET C#/WindowsFormsで書かれたもので、対象となるアセンブリとXMLコメントのパスを指定することで、変換用のバッチファイルを出力する簡単なものだ。例えば、"E:\Hoge\Hoge\bin\Debug\Hoge.dll"というアセンブリ、及び対応するXMLコメントファイル"Hoge.XML"を
ToolStripPanelにCopyrightを描画する - Kazzz's diary
アセンブリに埋め込まれているCopyright情報は、Aboutダイアログに等に表示することが多いが、フォーム上に常時見せておきたいというリクエストもよくある。コード例はToolStripPanelだが、Paintイベントハンドラを持つコントロールであれば、なんでもいけるだろう。 描画にはGDI+ではなく、.NET2.0から追加された、TextRendererクラスを使用している。 ToolStripPanel toolstripPanel = new ToolStripPanel(); form.Controls.Add(toolstripPanel); toolstripPanel.Dock = DockStyle.Top; toolstripPanel.Paint += new PaintEventHandler( delegate(Object sender, PaintEvent
KazzzのJとNのはざまで
してみたけど、広告がうざいのでまだ引っ越さないよ。 スケジュールされたバックアップタスクが実行された際に外部メディアが外れているとタスクは遅延するが、メディアが接続されるとこのように丁寧且つローカライズされたダイアログが出て、タスクを再開するように促される。 素晴らしい対応だ。 これならば標準アプリにも負けない出来であり、購入しかないだろう。というか、買う。 ところで「アーカイブのコンテンツをプルーンします」の"プルーン"ってなんだ? もう何度目だろうか。 ReSharper6まで上げたはいいが殆ど使わずに他のプラットホームの仕事に移ったものの、なぜか現在WPFアプリを書いている最中だが、今後1年間コンスタントにWindowsアプリケーションを書いている保障は全く無いわけで※、今回はさすがにバージョンアップは見送ろうと思ったのだが、ReSharperを使ったコーディングは一度経験してしまう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
