WPFではDrop=Trueで何でもDrag & Drop  OK。
※と云うか、WPFはいつもそんな感じの大雑把な作りなので、実用的な実装をしようとすると、ひどい目に遭う。
でもWindows Formでも同様にControl.AllowDrop = Trueにすれば良いんだけど、

なぜかPictureBoxだけプロパティ・ウインドウにAllowDropが無い。

IntelliSenseでもプロパティの候補にあがらない。
なので、
C#のソースに、
picturebox.AllowDrop = true;
と書いて実行してみると
DragEnterに処理が渡ってくるし、e.Effect = DragDropEffects.Copyとか設定しておけば、ちゃんと、DrapDropまでやってくるからOKなのかといえば、
このAllowDropの部分を選択してメニューから「次候補」を選択してもプロパティのドロップダウンリストが出ない。
そう内部でエラーが連発している気がする。
この状況を続けるとVS内部のストレスが溜まって、終いには暴走しそうな気配がする。
 
ま、原因はよく判らないけど、
どこかの国の誰かさんが
何かの都合で、PictureBox のAllowDropをオーバーライトした際に
public class PictureBox
{
・・・
[Browsable(false)]
public overwrite bool AllowDrop { get ; set ; }
・・・
}
とやらかしたらしい。
 
ただ、
PictureBoxのAllowDropを見えなくして、
どこかの会社の（ボクみたいな）そそっかしい奴に、どこかの会社の高価なユーザコントロールを購入させようともくろんでいたのかもしれない。
と思う方が一般的かもしれない。
 
対策としては、不都合を解消するためのカスタム・コントロールを作り、

using System.ComponentModel;
using System.Windows.Forms;

namespace Custom.Control
{
class ccPictureBox : PictureBox
{
[Browsable(true)]
public override bool AllowDrop { get ; set ; }
}
}

※オーバーライドするので他の属性が気になるならデザイナーのボタンのプロパティウインドウの内容を見ながら、 [DefaultValue(false), Browsable(true), Description(“コントロールが、ユーザがドラッグしたデータを受け入れできるかを示します。”), Category(“動作”)] と書いてもいいだろう、でも結果は同じだ。
ツールボックスに追加された、ccPictureBox をフォームに貼り付ければOK。
ただし、IntelliSenseのため作り直したVS2013のパーザー（文法解析）ルーチンは、あからさまに正しくないコードに対して脆弱性が高く、すでにccPictureBoxの名前でコントロールを作っているところにこのソースを追加すると、エラーが出っぱなしになりパーサーがパニックになってしまう。こうなると、クラス名を訂正してもダメ、ファイルを全部保存しVS再起動しないといけない。
ちゃんとしたソースなら問題ないけど、妙なソースだと、上記の様に素直に妙な動きをするので、その点からも IntelliSenseの「次候補」が出ない状態にしておくのは、やっぱり怖い。（大笑
本当にきれいに直したいなら、IntelliSenseの内容はSQL Server-Expressの中に書き込まれているそうなので、
TextBoxのAllowDropのデータを基にPictureBoxのAllowDropデータを作り、入れてしまえば良いのだろうけどね。
ただ、パッチが来たら、綺麗に戻ってしまいそうなので、やる気が起きない。（大笑
 
もしかすると、[Description(“延々と長い・・・・・・・・長い説明”)]で、
OverLength　Errorが起きてRollBack!
PictureBox.AllowDrop丸ごとINSERT失敗
なんてオチかもしれないなぁ・・・

近くアメリカで発売されるらしい、日本での発売は当然不明。
CPUは多分AtomかCeleronだろう。
ディスプレイは８インチぐらいで、キーボード付きケースも用意しているようだ。
外付けディスプレイに表示できるなら１つ買ってもいいかなと思えるけど、MHL-HDMIは付いていないだろう。
何に使うかと云えば、日報とか持ち運ぶちょこまかとしたテキストやEXCELのシートとかを入れておくPCとしては十分だ。
後は価格かな？
本体価格が4万円を越えたらパス。
それにこのタイプの本命はBay-Trailではなく年末のBroadWellなのは間違いない、電池も持ちとOfficeの動きが全く別次元になるハズだからだ。
さらにSkylakeと続き Skymountが現在の微細化の限界点（10nmルール）らしい。
あと数年でシリコンの微細化の限界に到達してしまうんだね。
限界突破はできないだろうけど。
 
 
 
 
 
 
 

コンシュマー向けの格安で小型なPCのキット。
付属のケースはW 118 mm × D 70 mm × H 56 mm。
CPU：Bay Trail-M SoC
メモリ：2Gバイト(DDR3L)
SSD：32Gバイトか64GバイトのeMMC
LAN：ギガビットEthernet
無線:IEEE 802.11a/b/g/nとBluetooth 4.0
USB: 3.0 と　2.0ポートが１個づつ
画像出力：D-Sub とHDMI
電源：5V／3A
価格：18K円前後（予価
となっているから、後はUSB接続のDVDドライブとWindows8.1、USB３は外部ストレージ、USB２はLogicoolのUnifyingレシーバーでも付ければよいだろう。NUCならチップセットは既存のものなのでWindowsなら当然動くし、CentOS6.3でもすぐ使えた気がする。しかし、Linuxは、Bay Trail-MのSocのチップセット周辺のドライバー対応が終わるまではサクっとは動かないだろうけど、そこが面白い人には価格も安く丁度良いかもしれない。
残念だけど付属のケースはVESAマウンター未対応だが、何かのVESAマウントの金具が入手できれば、工夫次第で取り付けられそう。０スピンドル（ファンやモーター無し）なのでVESAマウント取付け用のテレビハンドルに紐でケースをぶら下げるダケの大雑把なやり方も、持ち運びにも便利そうだ。（笑
何分CPUが非力でGPU性能もショボイので、使い道はブログサーバー、無音のPCオーディオを楽しむ、youtubeのチョット観とか、用途は結構狭い気がする。
NUCが死んだら、コレ使おうかな。
 
しかし、安価なベアボーンの最大の弱点は安価それ自体にある。これにWindows8.1とMS-Officeを購入すると、あまり安さを感じられなくなってしまうし、もしカクカクしたり、処理が重いなぁ～などと感じたりしたら、もっとパワーがあるものにすればよかったとか思ってしまうことだ。

無線ルータ　WHR-G301N　を中継モードにすると
大元のルータからIPアドレスが割り当てて貰えず設定画面が開けない状態だった。
だから設定を変えるにはROUTERモードに変えなくてはいけないが、
IPアドレスのセグメントが変わってしまうので、ipconfig /RENEW とか色々面倒で、扱いにくくて仕方がなかった。
でも、このルータ専用のツール（エアステーション設定ツール(Ver.2)　Ver.2.0.15を使うと、
中継モードのまま、ルータに勝手にIPアドレスを割り当てられる。
インストして起動。
「はじめに」の画面は　【次へ(N)】　を押す。
「２つ以上のネットワーク接続がつながっています・・・」と出た場合は【続行(C)】を押す。
「エアーステーション無線親機の選択」で、IPアドレスを割り当てたい親機を選択して【次へ(N)】を押す。
既にIPアドレスが割り当てられていれば「設定画面を開く」を押してブラウザで設定画面が開く。
「この無線機のIPアドレスを設定する」を選択、
DHCPサーバー（つまり回線の元のルータ）からIPアドレスを自動的に取得する。（かんたん）
か
次のIPアドレスを使う（上級者・管理者向け）　で　IPアドレスのネットワークマスクを入力して
を選択する。
 
ただ一度どちらかで設定してしまうと、

2度目以降の変更は「からなず失敗する」

但し、IPアドレスを忘れてしてまってもこのツールが設定済みのIPアドレスを探してくれるから、
ブラウザの管理画面のLAN設定から「LAN側IPアドレス」を設定しなおせばいいだろう。
しかし、一旦スタティックにIPアドレスを振った後に、DHCPで取得するようにしても、同じIPアドレスになったのは、何となく納得できない。大元のルータのDHCPの割り当てリストにもちゃんと載っているから大元のルータがIPアドレスを変えないように配慮した結果なのだろう。
それより、DHCPサーバのネットワークのセグメントを変えちゃった時にこのツールが重宝するんだろうね。

プログラムを作る時、
大抵はいくつかのパーツに分ける。
プロパティファイルを読み込むリーダーを作るなら
BinaryFileReader <- TextFileReader <- LineFileReader <- PropertyFileReader
な感じだろうか。
普通ならPropertyFileReaderに使うプロパティファイルをパラメータで指定し、
BinaryFileReader <- TextFileReader <- LineFileReader
の部分は何も変更が無く、大抵のファイルならそのまま流用ができる。
この場合の正統派なコピペは、
PropertyFileReader pfr1 = new PropertyFileReader(“xxxxxxx-1.property”);
PropertyFileReader pfr2 = new PropertyFileReader(“xxxxxxx-2.property”);
PropertyFileReader pfr3 = new PropertyFileReader(“xxxxxxx-3.property”);
となる。
ところが実際には・・・
String [] fileNameList = {
“xxxxxxx-1.property”
,”xxxxxxx-2.property”
,”xxxxxxx-3.property”
};
List <PropertyFileReader> pfrLst = new List <PropertyFileReader>();
for( propertyFileList in propertyFile) {
pfrLst.Add( new PropertyFileReader(“xxxxxxx-1.property”) );
}
の様に、やりたい事に比べて助長過ぎるソースが美しいとされるが、何もメリットは無いし、
static final int   PROPERTY_FILE_INDEX_1  =0;
static final int   PROPERTY_FILE_INDEX_2  =1;
static final int   PROPERTY_FILE_INDEX_3  =2;
pfrLst[PROPERTY_FILE_INDEX_1 ].get(PROPERTY_MEBMER_1);
pfrLst[PROPERTY_FILE_INDEX_2 ].get(PROPERTY_MEBMER_2);
pfrLst[PROPERTY_FILE_INDEX_3 ].get(PROPERTY_MEBMER_3);
のように面妖なConst 定数を使ってプロパティファイルにアクセスしなくてはならなくなり、また勢いソースの行は妙に長くなってしまう。
悪い例のレビュー前： 　pfr1.get(“1”);
悪い例のレビュー後：　pfrLst[PROPERTY_FILE_INDEX_1 ].get(PROPERTY_MEBMER_1);
つまり、やりたい事を理解せずにソースレビューだけするとたった３行のコピペが上の様な有様に至ってしまう。
更に、ファイル名をConstクラスに差し込んだり、あるいは・・・プロパティファイルに入れてみたりすると、もう終わってる感じがする。
これはWEBでよく見かける見栄えの良いコーディングとは

無駄の塊

でしかないことを意味する。
では、
PropertyFileReader pfr1 = new PropertyFileReader(“xxxxxxx-1.property”);
という1文は見栄えが悪いのかと云えば、そんなことは無い。
ただ、
PropertyFileReader pfr1 = new PropertyFileReader(“xxxxxxx-1.property”);
・・・(98行中略)・・・
PropertyFileReader pfr100 = new PropertyFileReader(“xxxxxxx-100.property”);
となれば何か方法は無いのか？と云いたくなるだけだ。
こうなると、先の無駄の塊がなんとなく見栄えが良く見えてくるから不思議である。
但し、１００個もファイルを開いて何をするつもりなのか？という根本的な問題をまず考えるべきである。
その結果が、

１００個ファイルを開いても大丈夫なことを確認したかっただけ

だったりすると、１００行のコピペで十分な気がする。（大笑
ただ世の中には尋常ではないコピペが存在する。
JCLである。
古い話で恐縮だが、JCLに渡せるパラメータは1個のINT型だけだった古い時代。
Aファイルを読み、書式を変換し、Bファイルに書き出す。
のような単純なことでも
Aファイルが１０個あれば
JCL00001
・・・
JCL00010
と違うプログラムを流さないといけなかった。
そう、この１０個のプログラムで異なる部分は入力ファイル名と出力ファイル名だけである。
なせなら、C言語が出現する前にも文字列型変数はあったが、概ね固定長であった。
このためJCLのパラメータに文字列型変数を使える様にすると
main( char parameter[10] ) {
・・・
}
にするしかなく、とてもかっこが悪かった。
更に、文字列型のパラメータの数を増やしたりしたら
main( char parameters[5] [10] ) {
・・・
}
とかになっても、どうやって読めばいいのか直観的に判らないシロモノになってしまうからだ。
もっとも、JCLごとにパラメータの数が違うような仕組みは考えられなかったのだろう。
なんたって、１バイトのメモリは血の一滴。とても貴重だった時代なのだから・・・
 
もっとも、パラメータが１～１０の場合にファイル名をＩＦ文で振り分ければいいハズだが、ソースレベルデバッガどころがラインデバッガさえ使わせて貰えない時代。つまりＶＤＴな画面とキーボードなんて高値の華だったころは、パ ンチカードな時代で、ＩＦ文を書くより、ファイル名の１行（カード１枚）を差し替える方が簡単で動作も確認しやすかったのだ。
ただ、その流れが現在も続いている（もちろん機能は色々拡張されている）のはかなりウザいなぁと思う次第だ。
※もちろん、ＭＭＯＲＰＧのマクロはＪＣＬ系ではある。
しかしＪＣＬを使うのが金稼ぎに来たプログラマなのに対して、
マクロを使うのはお金を払ってくれるユーザであるため、
使いにくいとは云われつつも、ＪＣＬの数億倍もパラメータが使いやす。
ＪＣＬに似ているが全くの別物である。

# chkrootkit | grep INFECTED

Searching for Suckit rootkit... Warning: /sbin/init INFECTED
フム。
# reboot
うまく起動できないので電源ボタン長押しで強制終了して起動。
# chkrootkit | grep INFECTED
今度は何もでない。
自動アップデートで/sbin/initが更新されたのかな？