回答編集履歴

2

推敲した

2017/05/20 12:58

投稿

hidori
hidori

スコア402

test CHANGED
@@ -4,11 +4,11 @@
4
4
 
5
5
  子要素もコントロールで作ってるんですよね?
6
6
 
7
- したら割と低いところに Windows GUI の限界があって、たぶんそれにぶつかっています。
7
+ すると古典的な Windows OS GUI の仕組みには割と低いところに限界があって、たぶんそれにぶつかっています。
8
8
 
9
9
 
10
10
 
11
- 数十、数百といいった描画オブジェクトを、コントロールで実装するのは現実的な選択ではないです。
11
+ ドローアプリの描画オブジェクトを、Windows.Forms のコントロール(=実体は Windows OS の古典的な GUI オブジェクト)で実装するのは現実的な選択ではないです。
12
12
 
13
13
 
14
14
 
@@ -16,11 +16,11 @@
16
16
 
17
17
 
18
18
 
19
- Windows.Forms は高解像度環境への対応非常に弱いで、今後を考えるとあまりお勧めテクノロジりません
19
+ WPF を使った方アプリケションやすいと思い
20
20
 
21
21
 
22
22
 
23
- WPF を使った方アプリケションやすいと思い
23
+ また、Windows.Forms は高解像度環境への対応非常に弱いで、今後を考えるとあまりお勧めテクノロジりません
24
24
 
25
25
 
26
26
 

1

文言修正

2017/05/20 12:58

投稿

hidori
hidori

スコア402

test CHANGED
@@ -1,5 +1,29 @@
1
+ 直接の回答ではありませんが。。。
2
+
3
+
4
+
5
+ 子要素もコントロールで作ってるんですよね?
6
+
1
- 直接の回答ではありませんが、WPF 使った方がこの手のアプリケーションは作りやすと思います
7
+ としたら割と低いところに Windows GUI の限界があて、ぶんそれにぶつかっています。
8
+
9
+
10
+
11
+ 数十、数百といいった描画オブジェクトを、コントロールで実装するのは現実的な選択ではないです。
12
+
13
+
14
+
15
+ たとえば、Excel の「セル」はコントロールではなく、編集対象となった「セル」の位置に動的にエディットコントロールを張り付けるなどの実装上の工夫がされています。
2
16
 
3
17
 
4
18
 
5
19
  Windows.Forms は高解像度環境への対応が非常に弱いので、今後を考えるとあまりお勧めのテクノロジーではありません。
20
+
21
+
22
+
23
+ WPF を使った方がこの手のアプリケーションは作りやすいと思います。
24
+
25
+
26
+
27
+ どうしても Windows.Forms で作るとしても、描画オブジェクトをコントロールで実装するのはあきらめて「オフスクリーン」などの適当な技術を学んで実装した方がよいと思います。
28
+
29
+