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失敗
なんてオチかもしれないなぁ・・・