インストールされているプリンターの一覧を取得する。
using System; using System.Printing; namespace LocalPrintersName { class Program { static void Main(string[] args) { foreach(var queue in new LocalPrintServer().GetPrintQueues()) { Console.WriteLine(queue.FullName); } Console.ReadLine(); } } }
LocalPrintServerのインスタンスメソッドGetPrintQueuesを実行
実行した端末のPrintQueueクラスのコレクションが返る。
後はPrintQueueクラスのプロパティを出力
既定のプリンター名を取得する。
using System; using System.Printing; namespace DefaultPrinterName { class Program { static void Main(string[] args) { Console.WriteLine("既定のプリンタは{0}です。", LocalPrintServer.GetDefaultPrintQueue().FullName); Console.ReadKey(); } } }
system.printingを参照設定に追加
LocalPrintServerクラスのstaticメソッドGetDefaultPrintQueueでプリンタ設定のインスタンスを取得
FullNameプロパティでプリンタ名を取得
WPFで帳票 参考リンク
ネットで色々検索してみるとWPFでも帳票印刷が出来るらしい。
後で参考に出来そうなリンクをメモ
以下参考:
WPFでの印刷の基本(1) 単一ページの印刷 - Qiita
WPFでの印刷の基本(2) 複数ページの印刷 - Qiita
WPFを帳票フレームワークとして使う - @kotyのブログ
WPF/XAMLで帳票のデザイン・印刷を行う - Qiita
[C#]プリンタ一覧と、デフォルトプリンタを取得するには
のぶろぐ WPFでの印刷
C# App.Configでエラー
DbProviderFactoriesの仕組みを勉強してて、DbProviderFactories.GetFactoryClasses()でConfigurationErrorExceptionが発生。
App.Configをよ~く見てみるとセクションの後のスペースが交っていた。
これを消してやると解消。
1時間くらい悩みました・・・
インターフェースを考える(14)考えを整理(出来ていない)
C#実践開発手法のシングルメソッドインターフェースで色々書いてきたけども、
途中途中浮かんだ考えをだぁーっと箇条書きにしてみる。
C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング
- 作者: ゲイリーマクリーンホール
- 出版社/メーカー: 日経BP社
- 発売日: 2015/06/25
- メディア: Kindle版
- この商品を含むブログを見る
- オブジェクト指向や〇〇パターンとかはツールであって目的ではないということ。
- 処理は小さく、抽象化されており、組み換え可能であることが望ましい。
- シンプルな処理であればあるほど、コードを修正する可能性は低くなる。
- 小さいクラスは設計・開発・テストのサイクルがシンプルで作業を理解しやすい。
- コードに修正の余地が無ければ、たった一つでも仕事をしていれば資産と言える。
- コードを修正して機能を増やすことよりクラスを増やして機能を増やしていく。
- クラス数が増えるのは問題ではない、増えたクラスがライブラリや名前空間で整理されていないのが問題。
- 複数の処理を持っているクラスはその分コードを修正する可能性が高くなる。
- 修正の可能性が低いコードほど堅牢で修正の可能性が高いコードほど脆弱なコードになる。
- 10の機能を持った1つのクラスを作るなら、1つの機能を持ったクラスを10個つくれば良い。
- 具体的な処理は不変であり、コラボレーション部分のみが修正の対象となれば良い。
- 分岐を目的としたパラメータを持つメソッドはパターン毎にメソッドを分割出来るはず。
- 条件分岐はパターン毎の処理を実行するという責務と、パターン毎に振り分けを行うという責務に分離する。
- シングルメソッドインターフェースは構造化プログラミングとOOPのポリモーフィズムのおいしいとこ取りをしている。
- 複数の処理を持ちたければ振る舞いクラスに委譲すれば良い。
- インターフェースのみに依存する場合、またはクラスに依存していても行き着く依存先がインターフェースのみであれば静的クラスの利用も悪くない。
- 何かを呼び出して戻り値を受け取る処理はまた別ななにかを呼び出して依存する。戻り値が必要無いように組み替えれば余計な依存関係は生まれない。
- プログラムの仕様変更が入った時のことを想像する。それがそのまま責務を分割する糸口になる場合がある。
- 思い切ってクラスの継承は無いものと考えた方が設計が捗る。