Category Archives: .NET
[.net]移植に有効活用。developerFusion「Code Converters」
CodeProjectなどでカスタムコントロールを探していると、いいなと思ってソースを見るとC#だ！ということが多いのですが、VBがいいなぁ・・・・。なんてときにとっても便利なのがこちら。
» Free online developer tools - developer Fusion
dobonさんで紹介されてて、精度もなかなかということで実際に使ってみたのですが、自分で移植するより精度が高かったw
C#→VB.NET、VB.NET→C#、それからPythonなんかにもコンバートできるようです。
これまで手で地道に移植して、C#とVB.NETの微妙な違いがそうかそうかと分かっておもしろかったのですが、いかんせんなれないC#だけにVBからのコンバートに時間がかかっていました。でも、これで一発。
dobonさんには今日もお世話になりました。いつまでお世話になることやら・・・。
» DOBON.NET .NET Tips: C#, VB.NET, Visual Studio, ソースコード, サンプル紹介
IISでWordPress。WebPlを使えばインストールが簡単！
購読中のOSS系メーリングリストで知りました。WebPlがバージョンアップしたようなので、ささっとwordpressをインストールしてみました。
» Microsoft Web Platform
DBはMySQLでWEBサーバーはIISです。そのほか管理用にSQLServerがインストールされたり、EntityFramework関係もインストールされるようで、合計約90MBもインストールされるようです。けっこうありますねw ネットワーク経由でのインストール。時間がそれなりにかかったりします。僕は夜中でしたが1時間近くかかりました。
インストール後はMicrosoft WebMatrixを起動。MySite→Wordpress→OKをクリックするとWordpress用のサーバーが起動。URLが表示されるのでアクセスするとwordpressの設定が始まりますと、こんな流れです。かなり簡単でした。
wordpressをローカル環境で設定するにはApacheをいれてやってきましたが、これからはMicrosoft純正ツールですね。
[vb.net]DataGridViewのSelectedCellsコレクションに格納されるセルの順序について
DataGridView上で複数セルが選択された場合、そのコレクションを取得するために"SelectedCellsコレクション"というプロパティが用意されています。
» DataGridView.SelectedCells プロパティ
このコレクション、どうやらセルの選択のされ方によってコレクションに格納されるセルの順序が決まるようです。
以下、検証。
①左上から、右下へ選択
右回りでも左回りでも、結果は変わりませんでした。
左上から右下へセルを選択したとき、MouseUpイベントが発生したセルとSelectedCellsコレクションの0番目のセルは同じとなります。
②右下から左回りで選択
選択領域内の右上のセルが0番目に格納されています。
③右下から右回りで選択
選択領域内の左下のセルが0番目に格納されています。
いまいち規則性がつかめないですが・・・。
なぜこんなことを調べたかというと、SelectedCellsの0番目が必ずMouseUpイベントが発生したセルと一致すると思い込んでましたが、実は違うのかも・・・と思ったからでしたが、見事違いました。
MouseDownイベントが発生したセルをMouseUp時にどうにか取得したいというのがそもそもの狙いなのですが、SelectedCellsをあてにしないほうがよさそうですね。余分なメンバ変数はできるだけ増やしたくない。けど、いい方法があるだろうか・・・。
[VB.NET]For Each…Nextの反復値の変更は無効
し、知らなかった。
LinqでSelectした結果をForEachでまわして、要素の値を変更するプログラムを書いたのですがいっこうに要素の値が変更されないのですが、ちゃんとMSDNに書かれていました。
» For Each...Next ステートメント (Visual Basic)
反復値の変更 ループ内で element の値を変更すると、コードの読みやすさが低下してデバッグが難しくなります。group の値を変更しても、コレクションやその要素には影響が現れません。これらは最初にループに入る時点で確定されます。
"変更されません。"、はい。orz
コレクションの変更 GetEnumerator から返される列挙子オブジェクトでは、通常、要素の追加、削除、置換、または並べ替えを行ってコレクションを変更することはできません。For Each...Next ループの開始後にコレクションを変更すると列挙子オブジェクトが無効になり、次に要素にアクセスしようとしたときに InvalidOperationException 例外が発生します。
ただし、この変更のブロッキングは、Visual Basic ではなく IEnumerable インターフェイスの実装によって決定されます。反復処理中の変更を許可するように IEnumerable を実装できます。このような動的な変更を行う場合には、使用するコレクションでの IEnumerable 実装の特徴を理解しておくことが必要です。
コレクション要素の変更 列挙子オブジェクトの Current プロパティは ReadOnly (Visual Basic) であり、各コレクション要素のローカル コピーを返します。これは、For Each...Next ループ内では要素そのものを変更できないということを意味します。変更は Current から返されたローカル コピーにのみ適用され、基のコレクションに反映されることはありません。ただし、要素が参照型である場合、その要素が指すインスタンスのメンバを変更することはできます。次に例を示します。
ということで、変更されないことがわかりました。
仕事でVBでForEach書いたときは反復値に別の値を代入してもOKだったのですが、C#だとエラーでコンパイルできませんでした。
[.NET]Frameworkの管理外「アンマネージドリソース」の解放と関係。
昨日の[.NET]独自実装クラスにはIDisposableインターフェースを実装すべき?について、調べたのでリンクをば。
» いまさら聞けない、IDisposableインターフェイス
» [.NET]IDisposable インターフェイスをしっかり理解しておきたい。
» IDisposableインターフェースの使い方について
一番上の記事がわかりやすいかったです。
ガベコレによってオートマチックに解放されるのがマネージリソースで、
開発者が責任を持ってマニュアル管理しなければならないのがアンマネージリソース。
マイクロソフトから提供されているクラスについては、ガベコレがマネージリソースを回収するときに、
アンマネージリソースの解放も一緒に行われるが、それは、そのようにそのクラスが実装されているからにすぎない。
自分でアンマネージリソースを扱った実装をするクラスについては、
ガベコレはあくまでマネージリソースしか回収しないので、自らの手でアンマネージリソースを
解放してあげるように実装しなければ、いつまでたってもアンマネージリソースは解放されない。
また、ガベコレが回収を開始するのは、マネージリソースが足りなくなったときに限られる。
アンマネージリソースが足りなくなっても、ガベコレは何もしてくれない。
当然のことだが、アンマネージリソースの解放を怠るとメモリリークが発生する。
いつまでたっても解放されない。.NET Frameworkなのにメモリリークが・・・という原因のひとつはここにあるようですね。
IDisposable インターフェイスが実装されているということは、
クラスがファイル、ストリーム、およびハンドルなどのアンマネージリソースを利用していることを、
クラスの利用者（開発者）に知らせることを目的として実装されていると考えると理解しやすい。
つまり、Dispose()がコールできるクラスはアンマネージドリソースを利用しているから、明示的にメモリ解放してね、プログラマさん。ということですね。実装されているのにはちゃんとした理由がある。なるほど。
間違ってもマネージリソースしか含まないクラスに対して無闇にIDisposableインターフェイスを実装したり、
必要なタイミングでDispose()が正しく呼び出されていなかったりすることがないようにしませう。
これこれ。ちゃんとIDisposableインターフェースが実装されているのには理由があって、それに該当しないクラスは実装してはいけないわけですね。やみくもはダメですよと。
3番目の記事より。
こうすることによって、あなたが開発したクラスの利用者が、万が一 Dispose を呼び出し忘れても、最悪 GC の動作タイミングで、Finalize が呼び出され、アンマネージドリソースが解放されます。つまり、GC の仕組みをアンマネージドリソース解放の為のセーフティネットとして利用しましょう、というカラクリなのです。
クラスの利用者が Dispose を呼び出した場合には、Finalize が GC から呼ばれなくても、もはや何も問題は起きないので、GC 呼び出しオーバーヘッドを減らす為に「Finalize を呼ばなくていいよ」と宣言します。これが SuppressFinalize の意味です。
SuppressFinalize を書くと共に Finalize から Dispose を呼ぶ、これを忘れては、上記のカラクリが活きてません。
ではアンマネージドリソースを利用しているのでIDisposableインターフェースを実装。しかし、その実装方法にも決まりがある。ここのところは注意しなければいけないですね。最悪GCのタイミングでDisposeされるように実装。GCがFinalizeを呼び出したときにすでにDispose済みなら余分な負荷を生まないよう、Dispose済みであることを教えてあげなければいけない。のか。
ここでふっと。Finalizeってあまり意識したことがないかも。
