TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
【Delphi】Embarcaderoオッチャ その33【C++ﾋﾞﾙﾀﾞ】
[RPA]PC自動化技術総合スレ[効率化] Part.8
【Delphi】Embarcaderoオッチャ その33【C++ﾋﾞﾙﾀﾞ】
【.NET】F#について語れ2【OCAML】
Java 高速GUI SWT 3
C++/TemplateMetaProgramming
くだすれPython(超初心者用) その47【Ruby禁止】
【統計分析】機械学習・データマイニング19
C# vs Java どっちが好き? その5
C++でXML（主にxerces）やろう！
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22
- 1 ：2017/12/13 〜 最終レス ：2018/09/11
- Windows Presentation Frameworkについて語るスレ。
前スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part21
http://mevius.2ch.sc/test/read.cgi/tech/1494288553/
関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.sc/test/read.cgi/tech/1499658092/
コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/
- 2 ：
- <Grid>
<Canvas>
<Path Data="M 29.602622 23.073567 0.97801322 35.798371 V 31.333527 L 23.550279 21.535676 0.97801322 11.737825 V 7.272981
L 29.602622 19.997785 Z M 71.175277 23.073567 42.550668 35.798371 V 31.333527 L 65.122933 21.535676 42.550668 11.737825
V 7.272981 l 28.624609 12.724804 z
M 104.36395 37.708332 H 84.37137 V 33.93802 h 7.689453 V 9.1829419 H 84.37137 V 5.8095044 q 1.562695 0 3.348632 -0.2480469
Q 89.50594 5.288606 90.423713 4.7925122 91.564729 4.1723951 92.209651 3.229817 92.879377 2.2624342 92.978596 0.65012949
h 3.844726 V 33.93802 h 7.540628 z " Fill="DimGray" />
<Path Data="m 125.10066 38.502082 q -7.9375 0 -8.33437 -5.357812 -0.19844 -3.373438 7.9375 -12.104688 1.5875 -1.5875
15.27968 -15.279687 H 116.56785 V 1.9895826 h 27.38437 l 0.99219 -0.99218749 3.175 2.18281249 q 1.38906 0.5953125 -0.79375
1.190625 -12.10469 11.7078124 -19.24844 19.4468744 -6.15156 6.548438 -6.15156 8.532813 0 2.38125 3.96875 2.38125 h 21.03437
q 2.18282 0 3.175 -1.389063 0.99219 -1.389062 1.38907 -4.960937 l 4.16718 0.79375 q -0.59531 3.571875 -1.38906 5.754687 -1.38906
3.571875 -5.95312 3.571875 z" Fill="DimGray" />
<Canvas.Effect>
<DropShadowEffect BlurRadius="4" ShadowDepth="2" Color="Gainsboro" />
</Canvas.Effect>
</Canvas>
</Grid>
- 3 ：
- Virtualized TreeViewでスクロールを繰り返すと
stackoverflowexceptionが出る件、まだ直らないのか
- 4 ：
- MVVM的に真っ当にタイマー処理をするにはどういう設計にすればいいですか？
Modelでタイマーオブジェクトを管理するのはおかしいですか？
- 5 ：
- >>4
タイマの目的によると思う
定期的なビューの更新をしたいだけなら、モデルにはなるべく静的なロジックだけを持たせるようにしておいて、
ビュー側からタイマー起点で最新情報をモデルに要求する形にするほうが綺麗(いわゆるプル型)
例えば倉庫の作業管理システムで30分毎に休憩のためのアラーム鳴らすとか、
ビジネスロジック的なタイマー処理ならモデル側で時間測ってビューへプッシュしてやるべきだろうね
- 6 ：
- 補足しとくと、VMはビューに含まれると考えてくれ。
ビューにタイマを持つと決めたなら、VかVMのどちらに置くかははっきり言ってどうでもいい。
MVVMはあくまでビュー層に閉じたデザインパターンであって、
モデルとの役割分担さえ守れてればあとは大した問題ではない。なんならVMなんか無くても大枠には影響しない。
- 7 ：
- >>5
定期的にサイトをダウンロードして解析してメール送信等を行うプログラムの場合はどうしますか？
- 8 ：
- >>7
モデルというか内部処理側だな
少なくともビューに直接埋め込むのは無い
あと、そういう単画面のツール的なアプリにVMは要らん
MVVMはDBの単純な読み書きをしたりするだけの紋切り型の画面を大量生産するのに使うんだよ
- 9 ：
- >>7
Mでいいんじゃないかな。
タイマーは単体テストするならインターフェース挟んで実装差し替えれるようにしておくと幸せかも。
- 10 ：
- WPFでMVVMパターン勉強中(Prism6 + ReactiveProperty)
ボタンとWebBrowserを配置して，ボタンを押したときにWebBrowserのRefreshメソッドを
実行したいのだが，どのように実装すればよいか教えてほしい。
メソッド自体はBehaviorで実行できるが，メソッドへのトリガのかけ方がわからない。
Messenger? ActionTorigger?あたりを使う？
あと，できればWPFの勉強方法も教えてもらえるとありがたい。
- 11 ：
- WPFでMVVMパターン勉強中(Prism6 + ReactiveProperty)
ボタンとWebBrowserを配置して，ボタンを押したときにWebBrowserのRefreshメソッドを
実行したいのだが，どのように実装すればよいか教えてほしい。
メソッド自体はBehaviorで実行できるが，メソッドへのトリガのかけ方がわからない。
Messenger? ActionTorigger?あたりを使う？
あと，できればWPFの勉強方法も教えてもらえるとありがたい。
- 12 ：
- なんも処理はさまないならEventTriggerでClickイベント拾ってCallMethodActionでWebBrowserのReflesh呼んでもいいんじゃないかな
- 13 ：
- 普通にイベントハンドラでやればいいでしょ
間にVMを噛ませる意味が全くない
- 14 ：
- MVVMを勉強したいだけならWPFより他の方法を取ったほうがいい
BehaviorにしろEventTriggerにしろMVVMやるだけなら要らん
Commandも要らん
焦点がぼやけるだけ
- 15 ：
- MVVMを勉強したいならテーマ選定も不適切だね
モデルが明確に定義できないものにMVVMは向いてない
自分のToDo管理システムでも作っとけ
- 16 ：
- 複数選択できるチェックボックスつきのリストビュー
というのがWPF初心者には不向きな題材に思えるけども
年賀状住所録とか交通費清算フォームとかがいいんじゃない、Master-Detailな画面で
- 17 ：
- 今後複雑化したら（既に複雑だから）UIとロジックを分離したいんだろ
- 18 ：
- >>17
迷ったときは原則に立ち返ることが大事。
なんでビューとロジックを分けるかというと、オブジェクト指向でいう「関心の分離」に従って
それぞれビューはビューだけ、ロジックはロジックだけに集中して開発できるようにするのが目的だ。
でMVVMはさらにこのビューを「ビューの状態とその制御」と「デザイン」とに分離するわけ。
で質問者のケースでは、大まかに関心を分離すると、ブラウザの制御、スケジューリング、ビュー、となるだろうな。
こう分離したときビューっておそらくかなり単純なものになるはずだよ。
その上であえてVMを分離する必要があるだろうか？ということ。
- 19 ：
- 先に言っておくけど、バインド使いたいだけならコードビハインドにプロパティ定義すれば済む話だからね。VMを使う理由にはならない。
- 20 ：
- WebBrowserに依存関係プロパティは存在せず、かと言ってsealed宣言されてるクラス
セキュリティ上の制約という説明になってるが早い話がいじれない
他の選択肢があるんじゃないか、例えばCefSharpなら今風でナウい子向けじゃないの
- 21 ：
- 前スレのポトペタできるを信じて勉強がてらユーティリティ作ろうと思ったんだけど、
フォルダダイアログって WindowsAPICodePack を入れるしかないのか？
- 22 ：
- チープな奴でよければWindows.Formsを参照に追加しても使える
何となく負けたような感じがするが気にしてはいけない
全てはMSが悪い
- 23 ：
- WPFはポトペタできるって主張したの誰だよｗ
WinForms 使ってやってみる、ありがとう
- 24 ：
- あ、WinForms のフォルダブラウザダイアログを使って WPF を使ってみるってことね
- 25 ：
- 勉強なら自作するのもありじゃん？
- 26 ：
- BitmapImage を MemoryStream から読み込んで作ってるんですが、
特定の jpeg ファイルを非同期で読ませると、デコードが非常に遅くなります（他のファイルの 10 倍くらい）
同期的に読ませると普通に速いです
メモリには余裕があり、また Visual Studio のプロファイラを見る限り、GCが頻発してるわけでもありません
また jpeg を bmp に変換してやると問題は解消されて、他のファイルと同じくらいの速度でデコードが完了します
(1) なぜ特定のファイルだけ遅くなるのか
(2) なぜ非同期だと遅くなるのか
このあたり、何か知ってる方はいるでしょうか？
- 27 ：
- 新規アプリ作ってその１つのファイルだけ読んでも遅いんだよね？？
まぁ、そうだしても思い当たるふしねぇな。
- 28 ：
- どこから持ってきたJPGなんだい？
ステガノグラフィや埋め込みバイナリとか付いてるんじゃない？
JPGファイルの内部をチェックしてみてはどうかな？
- 29 ：
- >>18
それらを現実のもので例えたら何？
- 30 ：
- JPEGと言ってもプログレッシブJPEGとかグレースケールJPEGとかある
- 31 ：
- いろいろアドバイスありがとうございます
眠すぎるのでわかったことだけ
問題のjpegファイルですが、セグメントを一個ずつ消してみて
デコード速度を測定したところ、APP2セグメントが問題だと分かりました
APP2セグメントを消すと他のファイルと同じくらいの展開速度になります。
BitmapImage がカラープロファイルを見ていい感じに表示しようと頑張ってるんだと思います
それにしても非同期のときだけ10倍も遅くなる理由が分かりませんが……
- 32 ：
- BitmapCreateOptionsにIgnoreColorProfileあるから、それ指定すると速くなるのかな？
- 33 ：
- >>32
どんぴしゃです
100倍くらい速くなりました
コードはこんな感じです
ttps://ideone.com/6iePK6
- 34 ：
- Pixel Shader Effects Libraryのプロジェクトが古すぎるから2017でもビルドできるように作り直した
8年前というとWindows 7が出たころだよな
現在でも機能が先進的すぎて使いこなせる気がしない
- 35 ：
- 俺も触ってみるか
- 36 ：
- 最近、海外でwpf、wpf言うから流行ってんのかと思ったらwtfだったわ
- 37 ：
- wpfで助かったｗ
製品型番で微妙に設計が違う画面設計が数十種類もあって、WinFormsではコマタだったが、wpfで事なきを得た。
WinFormでは、ロジックからGUIコンポーネントにアクセスするのに対し、wpfはコンポーネントからコントローラーにバインドする。
画面バリエーションに対し、ロジックを共通に使えるのは助かる。
- 38 ：
- winforms触ったことねぇけど、フォーム？の継承はできなかったんけか？
- 39 ：
- >>38
普通にできるよ
- 40 ：
- そっか。なら
>製品型番で微妙に設計が違う画面設計が数十種類
もWinFormsでも問題なさそうだけどな。
- 41 ：
- 微妙に違うカスタムコントロールを継承先から差し替えするのか？
ChildrenからName探して、カスタムコントロール差し替え&イベント設定するのも手は手だな。
- 42 ：
- WPFに慣れると発想からしてすべてが面倒になるんだな
- 43 ：
- 項目増やしたり減らしたりするのが、xamlだと簡単だってのも在るね
- 44 ：
- 一部分でも誉めると親の仇を取りにくる奴がいるのは難点だな
- 45 ：
- >>42 が WPF、WinForms どっち側を勧めているのか分からない
WPF推奨： WPFに慣れると（Formsを扱う場合）発想からして（コントロールの扱いやUI差し替えなどWPFに比べて）すべてが面倒になる（面倒くさく感じる）んだな
Foms推奨： WPFに慣れると（設計についてごちゃごちゃ考えるようになり）発想からしてすべてが面倒（面倒な扱いの人）になるんだな
- 46 ：
- ちょっとしたアニメーションをつけるだけでWindowsフォームだと大騒ぎになる
WPFならトリガー入れてStoryboardでアニメーションがあっさり入る
もちろんWinformsでも頑張ればできるわけだが手数かかってしまい手早くインスタントな作りにならない
- 47 ：
- アニメーションするUIは散々ウザいってよく言われてるのにカッコイイとか思ってる奴もいるのね。
flashのUIがウザい理由もそれ。
- 48 ：
- やっとXAML分かってきたわ
最初の一歩の敷居高すぎやろ
魔除けかよ
- 49 ：
- >>47
WindowsのOS自体がアニメーションだらけの時代に、化石みたいなこと言う人いるんだな
- 50 ：
- >>47
アプリの動作とは全く無関係なアニメーションがウザいだけ。
- 51 ：
- VS2008のアニメーションは最低最悪のUXだったよな
オフにできるとはいえ、WPFになる直前の史上最高完成度のVSがあれで台無し
- 52 ：
- WidowsのアニメーションをONにしてる開発者ってかなりの初心者。
アニメーションしてるおかっこいい、最先端、革新とか言ってるのか。
マジ笑える。>>49
- 53 ：
- アニメーションはカッコいいだろ
電卓がまともに計算できなくなるとしても優先すべきだ
- 54 ：
- >>52
おじいちゃんこんにちは
- 55 ：
- やあこんにちは小僧
- 56 ：
- アップルのアニメーションなら良いのかなw
- 57 ：
- Widowsだから、恐らく未亡人アニメのことかと
- 58 ：
- >>49 ←こいつ、Windowsの効果音もONにしてそうwww
- 59 ：
- iPhoneでOK
- 60 ：
- ウインドウズはもちろん若い子が夢中のアイホンにアンドロイドもアニメーションだらけ
あれがカッコイイんでしょ
- 61 ：
- アニメーションをオンにして遅くなるようなボロいマシン使うなよ。
- 62 ：
- どんなに速いマシンでもアニメーションをオンにしたら遅くなることも理解できないアホがいるとは。
ここム板なんだけど。まさかコード書けない奴までいるとは想定外。
- 63 ：
- お前はプログレスバーアニメーションのようなものまで否定するのか?
- 64 ：
- 進捗しているように見せかけるプログレスバー(ブラウザに多い)はR
- 65 ：
- ｗｐｆ使えない人は、こういう言い訳するんだな
出来ないのに出来る人を蔑むプライドっって笑えるね
- 66 ：
- >>64
失礼なことを言うな
進捗率の「%」部分が
「%」と「I」が交互に表示されて
動いてるように見えるだろう
でも、死んでるんだけどね
- 67 ：
- 実年齢は分からないけど面白いお爺様がいるのね (´・ω・`)
- 68 ：
- 視線誘導とかの目的にはアニメーションいいと思うけどね。
- 69 ：
- >>61はたぶん体感の話
>>62は日本語の理解力が足りないアホ
- 70 ：
- >>69 ←こいつすげー馬鹿。アニメーションの実装したことないことがバレバレ。
- 71 ：
- アニメーションがかっこいいとか遅いとかそういう事言い合ってるのに、突然実装の話しだす。無理するなよw
- 72 ：
- 横レスだがWindowsのアメニーションを体感で遅くなるとか言ってる人はWindows使ったことないと思う。
Windowsのアニメーション装飾が何の機能か知らない人の発言。おらそく馬鹿マカー。
- 73 ：
- 当たり前だがPCの速度でアニメーションが早くなったり遅くなったりするような実装になってない。
だから速いPCにしろというのはさすが意味不明、筋が通らない。体感なんてなおさら関係がない。
MS開発者はアニメーションはふつうOffにすることすら知らないんだからやはりマカーだね。
Appleは古い機種をアップデートすると故意に遅くなるようにしてたらしくて訴えられたが。
- 74 ：
- > 視線誘導とかの目的
これが嫌われてる細大の理由だね。flash=詐欺広告、下品なエロ広告
- 75 ：
- 夜中までご苦労さん w
- 76 ：
- >>70
今更アニメ作れるみたいなこと言い張ってもバレバレですわ、爺様
- 77 ：
- すまんのう、ガンダム世代の爺なのぢや
- 78 ：
- >>74
もしかして本当に呆けてるの？
- 79 ：
- Windowsのアニメーションをオンにしてる開発者を一度もみたことない。
顧客からもアニメーションのオフにする方法は聞かれるが仕様でアニメーションにしてくれなんて要望されたこともない。さすがに無職でしょう。
- 80 ：
- パフォーマンスオプションの視覚効果のことなら今どきのPCならデフォルトでONだろうが、
開発者でもわざわざOFFにしてる奴なんて見たことない。
- 81 ：
- 他人のPCの設定を念入りにチェックする奴なんて見た事ないわ
- 82 ：
- >>81
他人のPCの視覚効果ON/OFFって設定見ないと分からんのか？
- 83 ：
- 作れないやつが、ほぼ言いがかりで作れるやつにマウンティングするとか笑えるねｗ
webがアニメしまくりなのに、もしかするとjavascript切るんだろうか？
- 84 ：
- よく知らないけど、iPhoneの電卓がバカなアニメーションのせいでまともに使えなかったことは知ってます
- 85 ：
- 操作性を損なわない程度のものならあっていいんじゃないかい。
画面に変化のあったところを気づかせるためや、マウスオーバー時になにかできることしめしたりや、ナビゲーション時に前のページと関連のある項目をわかりやすくするためとか。
すごくアプリに慣れた人にとってはいらないかもだけど、そうでない人にとって気づきやすくさせるために使えると思う。
エロ広告みたいなうざいやつだけではないから、適切に使えばいいだけの話。そして、WPFには組み込みのアニメーション機能があって、そういうのが無いプラットフォームよりも楽に作れるってだけじゃん。
なんで言い争ってるの？
- 86 ：
- 組み込みのアニメーションが憎くてしょうがない
WPFにメリットがあってはならない
- 87 ：
- 僕は林檎るdisることができればスレの流れは気にしません
- 88 ：
- そんなに楽なのか
俺はトランジションが難しすぎてドハマりしてるけどな
アーティファクトを発掘したはいいが使い方がわからない感じ
- 89 ：
- 操作の遅延動座でしかないアニメーション装飾で喜ぶなんて小学生低学年までとマカーだけだろ。
- 90 ：
- 人間はそういうふうに思うんだからいいじゃない
- 91 ：
- WPFの次はアニメーションが親の仇かw
- 92 ：
- 正月ということもあって勢いでスライドショーするソフト作ってみたが
アニメーションが重いというのはないね、軽快で快適
どちらかというとダウンロードの仕組みが入ると遅い
上手いこと先読みしたりキャッシュしとかないと無理あるね
- 93 ：
- 本気で言ってるなら頭の病気。
- 94 ：
- XPと秀丸をこよなく愛してそうなおっさん
- 95 ：
- WPFむずいわー
今日はTreeViewをやった
けどTreeViewってWinFormsでもむずいんだよな
むしろFormsのほうがむずいまである
はあ〜しんど
- 96 ：
- >>95
正直なところTreeViewをMVVMであれこれやるところが一番めんどくさい
やらなくていい
- 97 ：
- ComboBoxも結構面倒だと思うよ、TreeViewより頻出だと思うし
文字に色つけたりアイコン画像入れたり
- 98 ：
- このスレまだあったのか。しかも伸びてる。相変わらず普及しない、ゴミという話題ばかり。
- 99 ：
- 今年は飛躍の年になる
たぶん
- 100 ：
- あるならこれよりマシなGUIフレームワークを教えて欲しいわけだが
- 101 ：
- WPFはシステムであってフレームワークは自分で構築するか、既存のフレームワークを導入する必要がある
以前からWPFがむずかしいと言われる理由の一つがこの導入コスト学習コストの高さ
- 102 ：
- Visual Studio InstallerもElectronで作られる時代
- 103 ：
- VisualStudio本体もWPFで作られてるというよりWPFを描画と入力に使った独自フレームワークだからね
次のVSは本体にもElectronが入ってくるだろうけど
- 104 ：
- >>103
なぜそう思った？
- 105 ：
- VisualStudioのIDEってサードパーティー製のコントロールを使ってるって以前聞いたけど
本当なのか？
- 106 ：
- グレープシティは入ってたはず
- 107 ：
- MVVMの本質ってModel View ViewModelに分けることであって、
データバインド機能がなくてViewとViewModelを手動で結びつけててもMVVMです？
手動でやるとMVVM以外に結びつけるクラス(コード)が必要ですけど。
- 108 ：
- 本質はまあそう（責務の分離）かも知れんが……
- 109 ：
- >>107
MVVMはバインディングを効果的に利用するためのパターンなので、本来はバインディングを使わないならMVVMとは呼ばない
手動でやるのはMVVMの基になったMVPとかPassive Viewっていうパターンがある
- 110 ：
- >手動でやるのはMVVMの基になったMVPとかPassive Viewっていうパターンがある
WPF発祥の地ということ詳しい人がたくさんいるのはここだと思って
でここで質問したんですが、実際はWPFは関係なくてJavaScriptのWebアプリなんですよね。
で、実際、クラスを設計しようとして、モデルクラスつくって、次にビューモデルクラス作ってと
やってビューのフレームワークは実際React使うですんが、Reactはデータの流れは１方向で
ビューで発生したアクションは手動でビューモデルのメソッドを呼ぶように作ろうとしています。
で、責務的にはMVVMっぽくわけてるんですが、これMVVMって呼んでいいのかなとふと疑問に思ったもので・・
- 111 ：
- MVPとかPassive Viewとか前にチラッと言葉だけは覚えたんですが、調べてみます。
- 112 ：
- どうでもいいけど、
WPF発祥の地
は
MVVM発祥の地でした
- 113 ：
- reactならfluxでしょ
少なくともビューとC/P/VMを双方向に同期させないのはデータフロー的にもMVVMとは根本的に異なるよ
- 114 ：
- fluxというかreduxはややこして、今mobx使おうと思ってます。
>ビューとC/P/VMを双方向に同期させない
だからこれを手動で双方向に同期させようとしてるんです。
- 115 ：
- >MVVMはバインディングを効果的に利用するためのパターンなので、本来はバインディングを使わないならMVVMとは呼ばない
つか、仮にそうだとすると、バインデイングの機能を単に誰が用意するかの話問題になっちゃういますよね？？
自分で手動で用意するか、標準で用意されてるか誰か他の人がバインディングライブラリを作ってそれを利用するかの・・
それでMMVMと呼ぶか呼ばないかが決まっちゃう。
うーん。
- 116 ：
- 共通の仕組みを使うのと毎回手書きするのは違うだろ
- 117 ：
- https://qiita.com/takahirom/items/597c48ece57b4623cdee
ちょっとPassive Viewについて見てみました。おっしゃる通り本質的にはMVVPとデータフローは
同じでビューと(ビューモデルまたはプレゼンター)間がデータバインディングされてるか
されてないかの違いっぽいですね。
そうなると自分のはMVPかな？
クラス名の末尾をViewModelではなくPresenterにしとけばいいかなw
- 118 ：
- >おっしゃる通り本質的にはMVPとMVVMはデータフロー
に修正します。
誤字がひどくてすみません。
- 119 ：
- 正直、実装するときにはどうでもいい話だな。
- 120 ：
- 今日はComboBoxをちょっとだけ勉強したで
ワイWinFormsではデータセットからポトペタしてたんやけど同じようにできるっぽいんかこれ？助かるわ。
せやけど表示のカスタマイズ方法が馴染みなさすぎてｵｯｻﾝついていかれへんで
- 121 ：
- オーナードローよりは遥かに春かに簡単
- 122 ：
- データソースからポトペタしたデータグリッドのコンボボックスそのままやと使いもんにならんやんけ
これだけで1週間かかったわ
あったまっがパーン
- 123 ：
- かっそ過疎やな
せやけどXAMLおぼえたらあんまり話すネタないよなこれ
- 124 ：
- もう使ってる人いなくて新しい話題がないからね
- 125 ：
- 登場しからずっと話題は、普及はまだ？ 馬鹿には使えない!! のループだったな。
- 126 ：
- UWPスレよりは人いるから…
- 127 ：
- しかしWindows用のデスクトップアプリを作るとなったとき、現実的な選択肢はこれしかなくないか？
UWPは10用だし、マルチプラットフォームのあれこれはまだ発展途上で、
結局シングルソースじゃなかったり容量が馬鹿でかくなったりするし
- 128 ：
- >>127
Electronで十分だわ
- 129 ：
- >>128
容量がおかしいのそれだよ
Electron製で50MB以下のパッケージ見たことない
インスコしたら200MB超えましたなんてのもザラ
ついでにメモリも大食い
- 130 ：
- >>129
で？
- 131 ：
- で、>>127に戻る
- 132 ：
- >>131
ただ、Win10その他の制限が問題ない場合はUWPが良いよ
特に起動が１０倍単位で早いってのがね
コンパイルは１００倍単位で遅いけどね
- 133 ：
- >その他の制限が問題ない場合はUWPが良いよ
そりゃ、マイナス条件がないならプラスしか残らんのは当たり前だわなw
同様に、WPFの制限が問題ないならWPFが良いし、WinFormsの制限が問題ないならWinFormsが良い。
- 134 ：
- >>133
Fornsのアドバンテージは人足を集めやすいことで、wpfは特別な制約はなくて強いて言えばGridViewなどが遅いことぐらい
UWPは逆汗が難しいことやパフォーマンス。それとｔｏｏｌｋｉｔが標準で用意されていること
それぞれ使い分け出来たら良いけど、人足集めるのが大変だわなwpfとuwpは
- 135 ：
- メトロUIは業務系ユーザーに不評だから提案する気になれない。
- 136 ：
- wpfのネイティブコンパイルが出来れば全て解決なんだがなぁ
進んでるのかな
- 137 ：
- せっかくXAML覚えたのに来月からJavaScriptの仕事になってもうたわ
けどワイMS製品で育ったしいつかまた会うやろ。じゃあの・・・
- 138 ：
- コロコロと違う言語やプラットフォームに技術者をぶち込む企業はさっさと転職したほうがいい。
- 139 ：
- 若いうちならご褒美だろう。
- 140 ：
- 20代ならなー
- 141 ：
- 俺は45過ぎてからC++とGPGPU始めて、50近くになってTypeScriptとSPAやってるとこだわ。
- 142 ：
- このスレ加齢臭がする
- 143 ：
- ４０・５０過ぎてもC++とか理解できますか？
- 144 ：
- >>143
地頭とプログラミング適性次第
- 145 ：
- c++の文法ルール自体はそんなに難しくない
自動でメモリ解放してくれるようにもなったし
c++は生まれ変わった
でもライブラリなどがレガシーの塊なので非常に地獄
- 146 ：
- >>143
CとC++の壁？ かなり高いよ。
年齢は関係無い。
- 147 ：
- C#はすっと頭に入ったけど、C++はなかなか入らないですね
特にMFCというのが昔から苦手で今日まで来てしまった
- 148 ：
- 別にMFCはC++の構成要素じゃないよ
好きなフレームワーク使えばいい
- 149 ：
- だいたいwpfでC++もないやろ
なんでそんな話になってんだ全く
- 150 ：
- 次々からフレームワークが出て習得するのが面倒だよな。PGはそんなに暇じゃないっての。
フレームワークを使い捨てにするMSはアホ。wtfだってまだ使ってんだよ。
というか.netの売りは言語自由だったはずなのにwpfではC++を排除してるのかよ。ほんと嘘つきだな、MSは。
- 151 ：
- .NETのウリは言語自由って初めて聞いたが
いくつかの言語から選べるってのはよく聞くけど
- 152 ：
- WPFおもろいわ。
仕様拡張も含め、.net core対応ｷﾎﾞﾝﾇ
- 153 ：
- 全く。マウンティングするための道具として最高におもしろいわ。
- 154 ：
- WPFはエヴァンジェリストとブロガーのオモチャ。
- 155 ：
- Windows10,VS2017でWPFでWindowChromeちゃんを使って、
Windowのスタイルをカスタマイズしようとしてるんだけど、
タイトルバー高さをSystemParameters.WindowCaptionHeightで取得すると
23が返ってくるんよ。で、これ実際にPhotoshopとかで測定すると、31ぐらいなんだけど、
これって、もしかして72dpiと96dpiの違いで、96/72=1.333...をこの23に掛けてるんかな？
例えば、電卓の右上の[X]ボタンはH:30,W:48なんだけど、
SystemParameters.WindowCaptionButtonWidth=36
SystemParameters.WindowCaptionButtonHeight=22
36 x 1.333...= 47.999999
22 x 1.333...= 29.333333
こういう資料って、公式のどっかに説明あるんでしょうか？
- 156 ：
- >>152
わたしもきぼんぬ
- 157 ：
- >>155
試してないけどこれはどう？
http://blogs.microsoft.co.il/alex_golesh/2009/09/20/wpf-quick-tip-how-to-get-wpf-window-client-area-size/
- 158 ：
- >>157
どうもThemeの方にヒントがあるようね。
Firefoxのソースでも、Themeからひろってきてるみたい。
- 159 ：
- デザイナ画面で、現在作業しているプロジェクトファイルのパスが取得したいのですが、方法ありますでしょうか？
AssemblyやGetCurrentDirectoryを使ってもXDesProcのパスが返ってきて取得できません
- 160 ：
- TreeView を操作していると、StackOverflowException 例外で WPF アプリケーションが強制終了します
https://blogs.msdn.microsoft.com/japan_platform_sdkwindows_sdk_support_team_blog/2018/03/30/treeview-stackoverflowexception-wpf-47-crash/
- 161 ：
- まだ枯れてないのか。
- 162 ：
- ComputeFirstItemInViewportIndexAndOffsetがFloorをつかっている件か
- 163 ：
- datagridにおいて、以下のようなキーボード操作はXAMLだけで記述できますでしょうか？
・セルのtab移動を止める
・enterキーで次の行に移動するのを止める（矢印キーのみで移動）
- 164 ：
- DataGridは未完成糞品質のまま開発打ち切られて放置されたままのゴミだから使っちゃダメ
WinFormsのをホストして使うかサードのを買うかListViewでスクラッチするかWPFを捨てよう
- 165 ：
- >>164
行数少なければ十分使えるから、数百行表示させないようにプログラムすればいいだけですね
- 166 ：
- 2ヶ月ちょいjs/javaやったけど
Eclipseはポトペタできへんから面倒くさすぎる
いやワイが知らんだけかもしらんけど
しかしIDE落ちまくるし同期とらんと時々嘘くさい表示しよるし何なんやこれ
隣の席のやつ(javaﾏﾝ)はWPFやらされててワカランワカランいうてるし
ちゃんと履歴書読んどんのかここの会社逆やろｗ
- 167 ：
- そう思うんなら便所に落書きするより上司に相談しろ
喜んで入れ替えてくれるだろ
その程度の交渉や調整もできないカスなら何やらせたってダメだし、会社もお前に何も期待しないよ
- 168 ：
- eclipse使ってる企業なんてまだあったんだ
- 169 ：
- 替わりたくないんやが
ちな会社は赤字垂れ流して潰れそうやでw
- 170 ：
- 嘘みたいな話だけどeclipse大好きっこているんだぞ
一個も共感できないeclipse自慢話してくるよ
- 171 ：
- eclipseはモダンemacs的な開発者のオープンプラットフォームとして、
今でいうVSCodeに近いポジションを占めてたから、そういう面ではわりと根強いファンはいた
今ではJavaはIntelliJに取られemacs的な用途はVSCodeに取られ完全にオワコン
- 172 ：
- >>170
あるある
- 173 ：
- GridSplitter を挟んだUIを作成中です
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="1*"/>
<ColumnDefinition Width="Auto"/>
<ColumnDefinition Width="3*"/>
</Grid.ColumnDefinitions>
...
上記のように Columnの幅を1:3などの割合のまま、
Properties.Settings のメンバに Bind するにはどのようにしたらよいですか？
下記のように書いてみましたが、いくつか問題にぶち当たりました
<ColumnDefinition Width="{Binding Source={x:Static p:Settings.Default}, Path=ColumnSplitterSize, Mode=TwoWay}"/>
・Column の幅を変更して、Settings.Default.Save() しても Settings に反映されない（Settings の他の値の変更は確認済み）
・Settings の要素の型に GridLength を指定した場合、3* などを指定できない（数値かアスタリスクのみ）
・1:3 などの割合を指定したまま、サイズを保存、復元する方法があるのか不明
グリッド幅の保存は基本だと思うので簡易な方法があると思うのですが……
- 174 ：
- GridLength 構造体
- 175 ：
- >>174
はい、GridLength 構造体です
Settings の要素の型を GridLength にしても反映されないので質問しました
何か基本的なことを見落としてるような気がします
- 176 ：
- GridLength GridUnitType.Starでぐぐる
- 177 ：
- >>170
マルチプラットフォーム的なのが少なかったんで
選択肢がそこに居ちゃっていたってことじゃないんかな？
- 178 ：
- >>173
１：３なのに、なんでAUTOが入ってるの？
- 179 ：
- >>178
GridSplitter
- 180 ：
- 試行錯誤しつつ、あれから冷却期間を入れて試したところ 2番目の問題は設定できるようになりました
>>176
> GridLength GridUnitType.Starでぐぐる
「・Settings の要素の型に GridLength を指定した場合、3* などを指定できない」
ことへのコンストラクタを使ってコードを書くべきというアドバイスかと思います
本当に申し訳無いのですが当方の思い込みが含まれていました
実際に試した値は「1*」で、書き込むと「*」になるため、誤認していました
正しく書き直すと、
プロジェクトの「プロパティ」→「設定」→要素の「型」で
PresentationFramework の System.Windows.GridLength を指定した
ケースでの「値」列の内容について、XAMLで指定できる文字列「1*」を指定できず、
書き込むと「*」になるということです
Settings.Designer.cs での DefaultSettingValueAttribute の引数の文字列です
試しに「3*」を入れたところ、3:3(=1:1)に指定できましたので Settings で初期化はうまくできていましたので、
2番目の問題は解決しました
（「1*」は値として同じ意味の文字列「*」に自動で変換されるみたいです）
XAMLは下記のとおり、
<ColumnDefinition Width="{Binding Source={x:Static p:Settings.Default}, Path=ColumnSplitterLength}"/>
<ColumnDefinition Width="Auto"/>
<ColumnDefinition Width="3*"/>
ただ、Settings で指定は可能なのですが、Grid.Width プロパティは実際のサイズに連動しておらず、
Mode=TwoWay を追加しても、肝心の1番目、2番目が解決できませんでした
実際のサイズに連動するよう少しずつ調査する予定です
（ActualWidth:double を読み取って、GridLengthのコンストラクタを使って Settingsに保存する？）
>>179
はい、GridSplitter を挟んでGridの列を 1:3 にするXAMLの書き方になってます
- 181 ：
- あああ、typo です
「ただ、Settings で指定は可能なのですが、Grid.Width プロパティは実際のサイズに連動しておらず〜」
ColumnDefinition.Width プロパティの間違いです
- 182 ：
- 175は忘れてください
Value+GridUnitType <--> 文字列 相互変換できてました
フォルダー <UserName>\AppData\Local\<アプリケーション名>
の下のほうの user.configに書き込まれているはず
- 183 ：
- splitterの幅をバリアブルにしている理由はなんなの？
- 184 ：
- ま、いいか理由はあるんでしょうから。
- 185 ：
- 質問させてください。
以下の画像のようにウィンドウの表示がSizeToContentの値によっておかしくなる場合があるのですが、
対策方法など分かる方がいらっしゃれば教えていただけないでしょうか。
https://dotup.org/uploda/dotup.org1526890.png
VSのバージョンは15.6.7、ターゲットフレームワークは4.7.1、
実行環境は Windows 10 で「拡大縮小とレイアウト」の設定は100%です。
XAMLは以下の通りです。どうぞよろしくお願いいたします。
<Window
x:Class="SizeToContentIssue.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
Width="213" Height="55"
SizeToContent="Width"><!--←Width を Manual に書き換えると正常に表示される-->
<Grid>
<TextBlock>
<Run Text="{Binding Width, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type Window}}}"/>
x
<Run Text="{Binding Height, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type Window}}}"/>
縦棒が入ったり入らなかったり→
</TextBlock>
</Grid>
</Window>
- 186 ：
- >>185
SizeToContent paints an unwanted border
https://stackoverflow.com/questions/16356507/sizetocontent-paints-an-unwanted-border
<Window UseLayoutRounding="True" />
でとりあえずその線は消えた
- 187 ：
- >>186
レスありがとうございます！私の方でも線が消えることを確認しました。
Webで検索しても答えを見つけられなかったので質問させていただいたのですが、
恥ずかしいことに紹介していただいたページは見落としてしまっていたようです。
何はともあれ、お答えいただきどうもありがとうございました。
- 188 ：
- >>185-187で自分の検索の不十分さを反省して以前から抱えていた別の問題も改めて検索してみたのですが、
やはり私の力ではどうしようもありませんでした。
立て続けに申し訳ないのですが、こちらについてもお力を貸していただけないでしょうか。
以下のような Binding のマークアップ拡張を作成したところ、
Mode が TwoWay のときは期待通りに動作するものの、
Mode が OneWay だと正しくバインディングできずに困っています。
class MyBindingExtension : MarkupExtension
{
public PropertyPath Path { get; set; }
public BindingMode Mode { get; set; }
public override object ProvideValue(IServiceProvider serviceProvider)
{
var service= (IProvideValueTarget)serviceProvider.GetService(typeof(IProvideValueTarget));
var target = (DependencyObject)service.TargetObject;
var dp = (DependencyProperty)service.TargetProperty;
BindingOperations.SetBinding(target, dp, new Binding { Path = Path, Mode = Mode });
return target.GetValue(dp);
}
}
（続く）
- 189 ：
- （続き）
原因はほとんど分かっていて、
・Mode が OneWay のとき、ターゲット側が書き換えられるとバインディングがクリアされてしまう
・ProvideValue が呼び出されたあと、その戻り値でターゲット側が書き換えられる
ということだと思うのですが、この問題を解決する良い方法が見つかりません。
苦肉の策として、SetBinding の行を次のように書き換えればとりあえず動作することが確認できています。
// BindingOperations.SetBinding(target, dp, new Binding { Path = Path, Mode = Mode });
Application.Current.Dispatcher.BeginInvoke((Action)(()
=> BindingOperations.SetBinding(target, dp, new Binding { Path = Path, Mode = Mode })));
ただ、バインディングのタイミングがずれてしまうと、
例えば SetBinding してから ClearBinding したつもりが順番が逆転してしまうなど
思わぬバグの原因となりかねないためできれば避けたいと考えています。どうぞよろしくお願いいたします。
- 190 ：
- 良かったなお前ら
https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/
- 191 ：
- YATTA!
- 192 ：
- やるやん
- 193 ：
- 日本語でOK
- 194 ：
- Windowsでしか動かない.NET Coreアプリw
一体何の意味があるのか
- 195 ：
- せっかく.NET Coreが盛り上がってきてたところだったのに、水を差すことになりそうで心配だな
Linuxサーバーで運用してる人達からしたら、結局梯子外してWinに誘導するいつものMSがまた正体を現したかと疑念を持たれるよこれ
- 196 ：
- >>194
Windowsにインストールされた.NET Frameworkに縛られなくなる
- 197 ：
- >>195
そもそもWindowsでしか動かなかったもののランタイムが変わるだけだし、corefx自体に追加されるわけじゃない
むしろ.NET Coreの普及を後押しする
- 198 ：
- 実質何も発表なかったこと一緒ってこと?
.NETは完全にWinプラトフォーム環境限定ということでオワコン
- 199 ：
- サーバーサイドはクロスだけど微妙にしか人気ねぇし、Xamarin捨てる勇気なかったのか
- 200 ：
- >>198
どこをどう読んだらそうなるんだよｗｗｗ
- 201 ：
- .NET Core 3ハWindowsデスクトップアプリをサポートする
https://www.infoq.com/jp/news/2018/05/net-core3-announced
開発者が、既存の.NET Framework for Windowsではなく.NET Coreを使いたい理由はなにか？
それにはいくつかの理由がある。まず、.NET Frameworkとは違い、.NET Coreアプリは完全に独立しており、異なるバージョンの.NET Coreを使用することが可能だ。
.NET Core 3の新しいオプションでは、.NET Coreランタイムと組み合わせて実行できる単一の実行ファイルを生成することが可能だ。
この発表に反応した開発者は、WPFとWinFormsをGitHub上でオープンソース化する可能性について尋ねた。
興味深いことにこの要求は、Lander氏に否定されてはない - Microsoftは将来的にオープンにする可能性がある。
コミュニティの主な望みは、これらをmacOSやLinuxに移植するよりも、Windows用のGUIツールキットの拡張とモダン化である。
- 202 ：
- .NET Coreが全然注目されないからいろいろやりだしたんだな
いままでの.NET Coreって誰から見たら魅力があるのかわからない微妙な物だから
積極的に使いたいと言う人は少なかった
- 203 ：
- 日本は全体的に低レベルなエンジニアが多い
なのでUIとその他のロジックがガッツリ結合して分離できない
なのでそう簡単には.Net Coreに移植できなかった
そうする必要のないあらゆるものまでがdnfやwindowsインフラに依存してしまっていたんだ
そりゃ移植して使えないものに魅力は感じないだろう
海外では設計が綺麗なので細かいコンポーネント事に移植の可能性を検討することができた
移植可能なものはすぐに移植する動きが広まってあっという間にCore対応が進んだ
彼らは高パフォーマンス、セルフコンテインドデプロイ、マルチプラットフォーム対応といった様々な収穫を殆どタダで得ることができた
.NET Coreはとても魅力的でエキサイティングなアップデートだった
- 204 ：
- .NET Coreは既存の環境から乗り換えたいと思わせるだけの魅力がない
windowsで,.net frameworkから乗り換える人は少ない
linuxで他の言語から乗り換える人も少ない
利点をはっきり打ち出せてない
ただ作りました使ってくださいじゃ使わない
- 205 ：
- コンパイルして起動時間が一桁早くなるってのは十分な魅力だと思うが
- 206 ：
- >>204
>>203でも書いたけど日本ではスパゲティシステムだらけで移植のコストが高すぎたから受け入れられなかった
海外では日頃から品質を高める努力をしていたので移植が容易にできた
そして様々なメリットを享受することができた
利点を示せなかったのではなく
利点を示したけど日本だけが利点を受け入れる下地ができてなかっただけ
つまり日本はハブられたんだよ
いじめられっ子がリア充の生き方なんつまらないと負け惜しみを言うようなもの
キツネとすっぱい葡萄の心理というやつだ
- 207 ：
- >>205
起動は確実にクソ遅くなるよ
今までは共有ライブラリとしてシステムにインストされいて自然にメモリにキャッシュされてた大量のDLL達を、
ローカルにバンドルしていちいちディスクからロードするんだから
- 208 ：
- >>207
.net nativeはスタティックリンクだから、ライブラリの中で使っている部分だけ切り取って本体に取り込んでリンクするんだわ
通常はファイルサイズが激減します
- 209 ：
- >>208
勘違いしてるようだけど、.NET CoreのSCDと.NET Nativeは別物だよ
SCDは.NET Coreランタイムと依存DLLを全部バンドルするだけ
- 210 ：
- >>209
一番要望の多いnative取り入れないとは思えないが、情報あるの？
- 211 ：
- 体感的にわからない程度に起動が遅くなるかもしれない
デメリットってそれだけ？
- 212 ：
- >>210
https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/
あくまで.NET自体を簡単にバンドルできるのが売りだ
.NET NativeはあくまでWinRT版の.NETの機能で、今出てる.NET Coreとは関係ない
ちなみに、.NET CoreではNuGetパッケージを結構細かく分割するのが普通だから、
WinFormsやWPFがそれぞれ丸ごと一つのNuGetパッケージになるようなことはたぶんない
必要なNuGetパッケージをある程度小分けで取捨選択できるようにはなるから、
今のSystem.Windows.Forms.dllよりは結果的にロードするサイズが小さくなる可能性はあるよ
- 213 ：
- >>212
将来はともかく、最初はこの程度なんかね
- 214 ：
- よく分かんないけど
動作環境の.NETバージョンに影響されずに済むって話じゃないの
- 215 ：
- >>211
全部バンドルしちまえってのは今時の流行りで基本的には良いものだけど、あえて挙げるならこんなとこかな
・配布サイズがクソ大きくなる
・DLLのディスクキャッシュが共有されないのでメモリを食うかも
・.NETに重大な脆弱性や不具合が見つかってもユーザーの裁量で.NETを更新できない
・NuGet必須なのでインターネット環境がないとビルドすらできない
・NuGet必須なのでキャッシュなしの状態だとビルドがクソ遅い
- 216 ：
- ・.NET Coreは(NuGetのせいでもあるが)デバッグが遅い
も追加で
- 217 ：
- >>202
どうやら違う世界に生きてるようだ
- 218 ：
- >>215
こいつC#使ったことないやろ…
- 219 ：
- >>215
RuntimeStoreも知らないようだし、NuGetがインターネット必須ってのも大嘘
ユーザーの裁量でRuntimeを更新できないってのも嘘
- 220 ：
- >>218
最近はずっと.NET Core&C#&Azureやってるよ
一般的な常識に基づく推論と俺の個人的経験で書いただけだから、間違いがあるなら具体的に指摘してるれると助かる
- 221 ：
- corefxやcoreclrも知らないからユーザーの裁量でランタイムを更新できないって発想になるんか？
- 222 ：
- >>217
そちらは新規開発案件の1割以上がc#を使ってる世界ですか？
不思議な世界ですね
こちらの世界は全ソフトウエア開発者で.Net Coreを知ってる人が
1%以上いるかどうか怪しいです
- 223 ：
- >>220
配布サイズが大きいのは、RuntimeStoreのない時代かもしくはランタイム自体をアプリに同梱する場合ね
- 224 ：
- >>222
ああ奴隷の世界ねごめんよ
- 225 ：
- >>224
いい加減に空想の世界から出て来いよ
.Net Coreなんてほとんど誰も知らない
C#使ってる中でも知られてない
みんな跨いでいく
- 226 ：
- デスクトップでCore使うメリットはSCDで、当然それは大前提だと思ってたんだけど
システムにCore入れるならそれこそ何の意味もなくね？
- 227 ：
- サーバサイドでも使われてない
デスクトップでも使われてない
業務でも使われてない
趣味で使うのがちょうどいい
C#大大大大好きだけど.Net CoreやAsp.net CoreやUWPは早く消えてほしい
- 228 ：
- >>225
Stackoverflowのreportでも見て現実を直視しろよｗｗｗ
- 229 ：
- >>226
どうも思い込みが激しいようだ
どっちかって言うとSCDこそ特殊な場合で、SideBySideでランタイムをインストールする方が良い
- 230 ：
- >>226
Microsoftのブログくらい読めよ
https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/
- 231 ：
- >>229
だからそれFull .NETのサイドバイサイドと比べて何のメリットがあるの？
- 232 ：
- >>231
>>230
- 233 ：
- >>231
たとえば.NET4.5.2と4.6.1はSideBySideでインストールできないっしょ？
- 234 ：
- >>233
結局システムに.NETを入れさせなきゃいけないのは同じだよね
.NET Coreなんか頻繁にアップデートされてるから事実上はほとんど特定のアプリと一対一になるだろうし、
アプリ側で.NETのバージョンを上げたくなったらまたそのアプリのためだけにまた特定バージョンのCoreをインストールさせるのか?
そのとき前のバージョンを安全に削除できるかどうか誰がわかる？
開発環境でのテストくらいにしか使えないよこんなの
- 235 ：
- まだ実用化されていない技術のブログ記事上げてドヤってる
それは既存の.Net Coreの利点じゃないだろ？
- 236 ：
- コアのアーキテクトの戦略がフラフラしてる
魅力のないロードマップがそれを物語ってる
- 237 ：
- >>234
前のバージョンを削除ｗｗｗ
- 238 ：
- >>231
こいつSideBySideなんて知らんのやろ
- 239 ：
- >>237-238
.NET CoreのSideBySideを利用したデスクトップアプリの正しいデプロイサイクルを具体的に説明してくれ
- 240 ：
- ちなみに.NET Coreって月一くらいのペースでバージョン上がってるんだが、それ全部SideBySideするってことだぞ？
アプリとは別にシステムの.NETのバージョン管理の余計な手間が増える以外になんかSCDと比較してメリットある？
- 241 ：
- >>240
全部とかただのキチガイか
- 242 ：
- >>215
NuGetって言葉覚えたてかな？嘘ばっかｗｗｗ
- 243 ：
- >>241
結局アプリごとに必要とするバージョンが違うケースが多いはずだからSCDでいいだろと言ってるんだけど、これだけ言っても伝わらない？
- 244 ：
- >>243
RuntimeStore
- 245 ：
- >>243
>アプリごとに必要とするバージョンが違うケースが多い
なんで？
- 246 ：
- >>245
そりゃ.NET CoreかつFDDのアプリ自体が(WinFormsやWPFがサポートされてもなお)稀だろうし、
フレームワークの方も月一で更新されてるとなれば共有できるケースは現実にはほとんど無いでしょ
- 247 ：
- もちろんデスクトップアプリに限った話な
サーバーだと一括で複数のアプリをデプロイしたりすることは普通にあるからもちろん意味はあるよ
- 248 ：
- WPFってグラボの違いでどれくらい速度変わってくるものなの？
ハイスペックグラボ使う意味ある？
- 249 ：
- >>246
妄想おつ
- 250 ：
- 大変そうだな。予防線はりまくりマウント取ろうと形だけは前傾で
- 251 ：
- デスクトップ対応はありがたい
業務系でウェブアプリはめんどくさいだけなんだよね
- 252 ：
- >>212
https://github.com/dotnet/corert
corertとかあるけどこれちゃうの？
ちょくちょく試すけど相変わらずx86がうまく生成されなかったりIssue多すぎて
比較的アクティブとはいえ使い物になるのかよくわからん状況だけど
VCランタイムすら不要の単体PEファイルになってdnSpyとかじゃなんも見れなくなるし
こういうのがプロジェクト単位でざっくりと組み込み検討できそうだから
デスクトップ向けの.NET Coreも結構期待してたりするんだけどね
WinformsとWPFのポーティングは朗報だけどどうせ改良する気はないんだろうし
クロスプラットーム化は無理でもせめてReference Source下じゃなくOSSにまでして提供してほしいもんだぬ
- 253 ：
- なんでDateTimePickerすら入ってねえんだこのゴミは
こんなんだから普及しねえんだよ
- 254 ：
- オープンソース化もあり得るって話だぜ
なんであれが無いんだーじゃなくてなければ作ってプルリクが当たり前になるのかな
数年後には有料サードパーティライブラリのような高級コンポートが標準化されるかもね
- 255 ：
- 標準でnumericupdownすらないWPFに何を言っても無駄
- 256 ：
- 欲しいものは自分で書いてプルリクを出せばいい
同じことをみんなやりだすからすぐにリッチコントロールが整備される
- 257 ：
- そういえば標準じゃフォルダー選択ダイアログもないな
- 258 ：
- WPFって正しく作法に従った汎用コンポーネント作るの結構難しいから、外野がプルリク投げてもなかなかマージされないと思うぞ
MS謹製のToolkitですら悲惨な品質でWPF本体にさっぱり採用されないまま潰れちゃったし
- 259 ：
- Material Design In XAML ToolkKit 使えばいいじゃん
- 260 ：
- 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
204GM
- 261 ：
- FormsとWPFはUIテスト自動化への対応具合どうなの？
UIテスト自動化が快適にならないと躊躇してしまうよね
いちおうappiumのドライバは見つけたけど業務で使いこんでるぜって類の記事が全然出てこない
- 262 ：
- >>261
https://github.com/Microsoft/WinAppDriver
- 263 ：
- 1.0.0が出たのは去年の10月だからね
- 264 ：
- prismってmessengerパターンするならEventAggregator使うようになったの？
InteractionRequestは過去のも？
- 265 ：
- 今のprismってMSの手を離れて単なるコミュニティプロジェクトの一つだからなあ
開発者の好みが反映された寄せ集めのツールキット集に過ぎず、もはやリファレンスでもなんでもないよ
- 266 ：
- >>264がInteractionRequestが好みなら自分でプロジェクトにコントリビュートすればいい
EventAggregatorよりも充実させればInteractionRequestがPrismの主流に見えるようになるだろう
今のPrismってそういうもんで、トレンドを追っても何の意味もない
- 267 ：
- Datagrid内comboboxのdatatemplateのバインディングがどうやってもできないw
- 268 ：
- >>267
サンプル見ると、スタティックなオブジェクトリンクしている
- 269 ：
- Prism6.3でInteractionRequestのRaiseAsync使おうとしたらないんだけど
問題あってなくなったの？
- 270 ：
- >>269
どこの馬の骨とも知れないメンテナの気まぐれ
君が復活させてもいいんだぞ
- 271 ：
- 共同ツール 1
https://seleck.cc/685
https://trello.com/
ボードのメニュー → Power-Upsから拡張可能 Slack DropBoxなど
Trello Chrome拡張機能 elegant
ttp://www.kikakulabo.com/service-eft/
trelloのオープンソースあり
共同ツール 2
https://www.google.com/intl/ja_jp/sheets/about/
共同ツール 3
https://slack.com/intl/ja-jp
https://www.dropbox.com/ja/
https://bitbucket.org/
https://ja.atlassian.com/software/sourcetree
https://www.sketchapp.com/
ttp://photoshopvip.net/103903
ttps://goodpatch.com/blog/sketch-plugins/
Trello Chrome拡張機能プラグイン集
https://chrome.google.com/webstore/search/trello?_category=extensions
Slackプラグイン集
https://slack.com/apps
Sketchプラグイン集
https://sketchapp.com/extensions/plugins/
https://supernova.studio/
- 272 ：
- >>253
>>255
いつかはWPFって思ってたのに移行できねーよそれじゃ
まあ、趣味ではWebサイトの方で忙しいから最近はC#あんまできないんだが
- 273 ：
- UWPにもnumericuodownないんだよな。Rよと思う。
- 274 ：
- タッチデバイスのためとはいえ、ほんと実用軽視には反吐が出るな。UI統一は大失敗。
- 275 ：
- >267
俺はこんな感じでやってるけど
comboBoxItemListはDataGridItemのプロパティにしてる
<DataGrid
ItemsSource="{Binding Path=dataGridRowList}">
<DataGrid.Columns>
<DataGridTemplateColumn>
<DataGridTemplateColumn.CellTemplate>
<DataTemplate>
<ComboBox
ItemsSource="{Binding Path=comboBoxItemList}"
SelectedValue="{Binding Path=column1}"/>
</DataTemplate>
</DataGridTemplateColumn.CellTemplate>
</DataGridTemplateColumn>
</DataGrid.Columns>
</DataGrid>
- 276 ：
- 質問失礼します
以下の2つのTextBoxはどちらも期待通りに動作しますが
2つ目はx:Staticを使っているため文字数が多くなっています
<TextBox
HorizontalContentAlignment="Right"
Background="Red"/>
<TextBox
HorizontalContentAlignment="{x:Static HorizontalAlignment.Right}"
Background="{x:Static Brushes.Red}"/>
新しく定義した型で1つ目のような短い記述を行いたいのですが、
HorizontalAlignmentのような列挙型では特に工夫することなく実現できるものの
Brushesのようなケースではどのようにすればいいか分かりませんでした
BrushesはRedのような静的プロパティをたくさんもつだけのクラスなので
Background="Red"という記述が受け入れられたり
この記述を行うときに入力補完が働いたりする仕組みが全く想像できないのですが、
そのような仕組みを新しく定義した型で使うことは可能でしょうか
もしご存知の方がいらっしゃれば教えていただけると嬉しいです
よろしくお願いします
- 277 ：
- AQ8
- 278 ：
- AQ8
- 279 ：
- >> 275
wpfのソース
- 280 ：
- 良きゲームだった
https://goo.gl/VuXjSo
- 281 ：
- >>279
お返事どうもありがとうございます
以下のコードを読んでみたのですが、それらしい箇所を見つけることはできませんでした
お手数をかけて申し訳ありませんが、読むべきソースを具体的に教えていただけないでしょうか
どうぞよろしくお願いします
（NGワードのためURL省略）
- 282 ：
- 280のURLです。NGワード回避のため一部省略しています
XXX = https://referencesource.microsoft.com/（中略）/System/Windows/Media
XXX/Brush.cs
XXX/Brushes.cs
XXX/KnownColors.cs
- 283 ：
- 何度も申し訳ありません
（中略）の部分は #PresentationCore/Core/CSharp です
- 284 ：
- コンバーターが明示的に指定されてないけどデフォルトでそういう動作すると決まってるだけでしょ
そういう仕様
自分の作ったクラスは明示してコンバート
- 285 ：
- ようやっと過去の物をprismに移行した
livetさらば
- 286 ：
- ゴミが作ったもんなんて普通は使わない
- 287 ：
- MSが作ったモノが使われなくなって早10年か。
- 288 ：
- だが果たした役割も大きいで…見方によっちゃリーディングカンパニーではあった
- 289 ：
- そう思ってるのはWPF関係者だけで
今の世の中に対してなんの爪痕も残せてない
影響はどこにも及んでない
FBがWPFをぼろくそに言ったことも忘れてる
そのFBはreact作ってる
- 290 ：
- AndroidのGUIフレームワークなんか明らかにWPFを参考にしてるし、
今やWebのSPA開発の標準となったMVVMの発祥地でもある
まあプロダクトとしての設計や実装がアレだったが根本の思想はわりと広く受け入れられた
- 291 ：
- うわぁこれは日本スゴいと同じメンタルですね
ダッサ
- 292 ：
- MicrosoftのC#が発祥でパクられまくってる便利機能って多いよね
MVVM、MVC、Task、async/await、Linq、Rx、var、EF、、、
Nullセーフティなど最近は遅れる事があるけどSpanやrefタイプみたいな試みはまだまだ先を行ってるね
- 293 ：
- webのMVVMとWPFのMVVMは全然別物なんだけど
- 294 ：
- >>292
よく見たらMVCまでC#起源とか言い出してるし
韓国人みたいなメンタルになったら終わりだぞ？
- 295 ：
- いい年こいて自己評価が低い奴ほど所持品や帰属集団を持ち上げるのよ
そうしないとアイデンティティが保てないからね
- 296 ：
- マカーのことですかね？
- 297 ：
- マカーは間違いない
- 298 ：
- ボタンにマウスが乗っかるときのアニメーションを切りたいんですが
どんなコードになるんでしょう
XAMLじゃなくてコードで書きたいです
- 299 ：
- >>298
テンプレートを丸ごと入れ替える
コードじゃなくてXAMLで書いてください
- 300 ：
- なぜ知ってる範囲だけで済まそうとして苦行をしようとするのか
- 301 ：
- ありがとうございました
出来ました！
- 302 ：
- FormsよりWPFの方が、VisualStudioがよく落ちるな
WPFって脆弱なイメージがあるけど大丈夫か
- 303 ：
- ヒミツだ
- 304 ：
- やりたかったのはJSPなのかも知れないが、
現時点ではそびえ立つ糞
- 305 ：
- その印象は正しいよ
WPFはDirect3Dを使うからハードウェアとの相性で落ちたりしやすい
- 306 ：
- 脆弱フレームワークだから寂れていくのは当然だな
- 307 ：
- 見るからに煩雑で洗練されてないもんな。馬鹿文系が設計したイメージ。
- 308 ：
- docker for winのGUIはWPF
- 309 ：
- 見づらいフラット文化をなんとかしてくれ。
- 310 ：
- 老害は分化から去れよ
- 311 ：
- >>310
フラットって昔からあるデザインだということも知らんとかアホすぎ。
時代錯誤なんだよ、おまえとフラットは。おまえの脳もフラットなんだろうwww
- 312 ：
- >>311
顔真っ赤だよw
- 313 ：
- フラット脳乙w
- 314 ：
- 額縁ド3Dはダサいとなっちゃったからなぁ…
- 315 ：
- ならクビにする必要ねぇな。なんでMSはフラット推進した奴をクビにしたんだよ。
Windows8以降の移行、普及の失敗はそれ以外にないからだろwww
タダでも移行しない人が半数もいるとかどんだけダサいんだって話だ。中身はほとんど同じカーネルなのに。
しかもカッサコイイだの最新だの言ってる奴はどいつも単発ID。過疎スレである以上同一人物なのは明らか。
つまり、全く人気がない、流行ってないのに、さも人気があるようにレスしてるマカーと同じ行動w
この恥ずかしい自演は自ら人気がないことを自覚してるからに他ならないwww
- 316 ：
- フラットは個人的に好きじゃないが、ただでも移行しない理由がそんなとこあるとは思えん
むしろ個人的には完全強制せずによく半数も移行したなって思うくらい
- 317 ：
- Windows8のUIはフラットがどうとか以前の問題だと思うが。
- 318 ：
- MicrosoftのModern以降のUIはシグニファイアを全く考慮してないので
素人がガワだけ真似たのが丸わかりなんだよ
フラットとかそういう問題以前
- 319 ：
- 流石に3Dルックは古い
- 320 ：
- マテリアルデザインはショボすぎだわ。もうちょっとエフェクト多用してGPU使ってほしいわ
- 321 ：
- まぁ、fluent designもアクリルエフェクト抜かせばマテリアルデザインと似たようなもんか
- 322 ：
- Aquaが出たとき俺はあまりのダサさに絶句したけど、称賛する人多かったね。
- 323 ：
- >>319 ←こういう馬鹿ってスマホしか使ったことないんだと思う
- 324 ：
- 今wpfで組むならデザイン何使うのがオサレなの？
- 325 ：
- >>319
おじいちゃんはまだWindows1.0を使ってるの？
- 326 ：
- >>324
Luna
- 327 ：
- >>324
Material Design In XAML Toolkit が結構良い感じだ。
ほとんど手を加えなくてもそこそこの見た目になるのでお手軽だし、サンプルのデモプログラムも良く出来てる。
- 328 ：
- 画面遷移するのに、標準のNavigationWindowとPrismのNavigationのどちらを使うか迷っています。
それぞれメリット・デメリットは何がありますか？
- 329 ：
- >>326
LunaってXPみたいなやつ？
>>327
Material Design In XAML Toolkitってまだイケるんや
- 330 ：
- WPFってほんと情報ないよな。誰も使ってないんじゃないの？
- 331 ：
- Stackoverflow（非JP）がバイブルすぎてな
あそこ見りゃ大抵は解決するので他の情報サイトの出番が無い感じ。
- 332 ：
- 入門みたいのの話じゃない？
定番の本とかもないしstackoverflowはある程度わかる人には便利だけど
みんなMSDNオンリーでマスターしてんのか
- 333 ：
- Pro WPF 4.5 in C# のサンプル
- 334 ：
- >>330
GitHubに参考になりそうなのめっちゃあるやん
- 335 ：
- 俺はMSの外人サン記事？のwpf サンプルから盗んだなぁ最初は
あと基礎部分はMSDNだな。依存関係プロパティとかそこらへんの基礎分かってないと辛い
- 336 ：
- なるほど。これは惨いな。
しかしこんなゴミのスレがPart22まで伸びるなんてMSの力は恐るべしだな。
やはり使ってる人が多いのだろう。
- 337 ：
- >>336
なにが？
- 338 ：
- WPFの宣教師がたくさんいたらいいのにね
- 339 ：
- ぶっちゃけWPFは先行きどうなの？
あと、Windowsのデスクトップアプリ作るのにWPFでやる利点あるの？
- 340 ：
- MSはWPFの終息宣言を出す一歩手前らしいよ（出すかどうかはわからないけど）
もうメンテナンスレベルだから最新の技術を使いたいならUWPに行くしかない
- 341 ：
- >>340
ソース
- 342 ：
- >>340
.NET Core3.0でわざわざアレするのに？
- 343 ：
- UWPこそ将来性どうなのよ
- 344 ：
- UWPてWindows10だけだろ？
- 345 ：
- >>344
基本的にはね
unoみたいな例もあるけど
- 346 ：
- UI変更だけでここまでWindows10が拒否られるとは。
やはり、UIは変更するなと言ってたゲイツは天才だったんだな。
- 347 ：
- >>346
Windows10が嫌われてるのはUIだけが原因じゃないだろ
- 348 ：
- つまりFormアプリケーションが鉄板だったてことか（ry
- 349 ：
- 残念ながらそう
- 350 ：
- Visual BasicのFormアプリが一番良いよなｗ
俺のような馬鹿でもいっぱしのモノが作れたのに、なぜWPFみたいに小難しいものを作ってしまったのか・・・
- 351 ：
- WPFでもビハインドにイベントベタ書きならFormsと同じ感覚で楽チンやで
- 352 ：
- 同じことするのに新しいことを覚えなきゃならないならまず覚えないよな。
- 353 ：
- >>330
かずきさんのブログ(かずきのBlog)のWPF4.5入門
- 354 ：
- Formが良かったとかじゃなくて、先に出たものはその仕様に合わせて作るんで
次に考えるときそれが標準で考えちゃうってことだろうな。
必要ない動きでもFormがこうだったから、とか。
最初のツールが右下に決まったものがでるようになっていたら
後のツールも右下に出ないと困るとか。右上でも問題なくても
今までそうだったから。
なんってところでしょう。
- 355 ：
- ずっと言われてるけど
JSとかflashの受けが良かったんで.NETに乗せたって事でしょ？
- 356 ：
- strict感と冗長感が敗因
.NETに乗せると命名が省略できないからなぁ
- 357 ：
- web技術の流行なんて使い捨てばかり。だって作ってる奴らは何も考えてないもの。
- 358 ：
- WPFでGUI作成がより合理的になったと思ったんだけどな
まさかFormにあるのにWPFにないコントロールがあるなんて・・・
タッチ前提とかふざけるな、まるでFormのサブセットじゃないか
- 359 ：
- NumericUpDownすらない...
みんな自作してるの？
それともフリーや有償のUIコンポーネント使ってんの？
- 360 ：
- 商法のひとつなのかもしれない
- 361 ：
- そういやBlendで小銭稼ごうとした罪があったな…
- 362 ：
- mf
- 363 ：
- >>359
NumericUpDownはWPFの機能紹介のためにあえて削られている
NumericUpDownくらい簡単に自作できるのがWPFなんですよみたいなノリで
いたるところいろんな人たちにより作り方が公開されてる
- 364 ：
- ボケてるんですか、おじいちゃん。ただの実装忘れですよ。
- 365 ：
- WPFは、実際の現場でコーディングなぞしないエヴァンジェリスト達がブログやセミナーでドヤ顔するための道具
- 366 ：
- は？
- 367 ：
- ひたすら画面を量産する業務アプリのコーダーにXAMLを弄くって遊ぶ余裕は無い。
- 368 ：
- Forms のいいとこは、コントロールのカスタマイズ性の低さでもあると思う
ここまでしかできないんですよ、ってのはメリットでもある
- 369 ：
- 追加やカスタマイズが容易だから最低限のコンポーネントしか用意しなかったってのは
最初の方針として悪くないと思うけど、一段落ついたところで MFC FeaturePack みたいなものを
用意してくれたらよかったのにねぇ。VSにいろいろ作り込んだコンポーネント公開するとか。
- 370 ：
- WPFは楽そうで全然楽じゃない
普通にボタンそのままだと楽だけど選択表示の青色を変えようとするととんでもなくめんどくさい
あとは意味不明の動作がたまにある
listboxのセレクションが単独になってるのに複数青色の選択状態になってたりする
- 371 ：
- あと日本人に青天井仕様は合わないんだよ。天井決められなくて右往左往する
- 372 ：
- 自由度が高いとおれジョブス的な馬鹿がトンデモなUIにするからな。
- 373 ：
- >>369
それいいね
- 374 ：
- >>370
テンプレートを修正すればいいだけだから、慣れたら簡単なんだけどな
ヴィジュアルステートマネージャーとか取っつきにくいのは確かだが
- 375 ：
- なんという時代遅れの開発。viで開発してた暗黒時代かよ。RADはどこ行った？
- 376 ：
- WPFとか関係なく時代の流れで消えてったな>RAD
- 377 ：
- ポトペタじゃレイアウトできん
- 378 ：
- .NET core3でWPFが動く方になったりUWPコントロールをホストできるようになるらしいが、未来はUWP。
- 379 ：
- wpfのテンプレートに文句言う人は、formsでgdi+触ったことない人なんだろうね
あれに比べたらwpfは天国だよ
- 380 ：
- このコードを碌に書いたことがない素人が設計したとか思えないWPFが天国だとは。
キミはOSS出身者か？ キミがどういう開発経験を経てWPFを使ってるのか聞きたいものだ。
- 381 ：
- 下をみたらどんなクソでも天国じゃんw
そんなの使いたくねー
- 382 ：
- 上を見ようにも、.NETでデスクトップアプリ作る場合は、他に選択肢無いし
FormsとWPFならWPFの方取るな
作るものにもよるけど
- 383 ：
- よく映画であるように、WPFでマンションなどの建物を
3dのワイヤフレームで表現したい。
この場合、建物のモデリングというか座標計算は
別のツールを使うのが定石でしょうか？
path情報をxaml形式で吐き出してくれたり
するのでしょうか
- 384 ：2018/09/11
- SharpDX
Vue vs React vs Angular Part.2
Gtkプログラミング on Windows!!!
【超高速】C/C++に代わる低級言語を開発したい 8
懐かしのMS-DOSプログラミング ver.2
【統計分析】機械学習・データマイニング20
自然言語処理スレッド その５
(´･ω･｀)人間はプログラムやがな
mallocの後にfree不要と言うバカいるの?Part2
COBOL？極めてやんよ シュッシュ!!
【コボル】COBOL不要論【ただのDSLだよね?】
--------------------
【ひろき】上田泰己6【カッシーナ
MSX1、SG-1000、FCの3機種で販売された作品
【ハゲ】山梨総合【オワコン】
【名無し奥も○○奥も】気楽に井戸端会議4061【みんな来い】
【実務・コテ禁止】第二種電気工事士試験 Part427 【本スレ】
改札口に切符入る時は当然左手で入れるよな
ミッツマングローブ「石橋貴明はうんこ以下」 ３ｳﾝｺ
スイミングスクールにパンツの落し物なかった？
【KNIVESOUT】荒野行動 part1【Switch】
ALSと筋ジストロフィーを考えるスレ2
”ごま豆腐”大好き！
【NGT48】荻野由佳 応援スレ★60【おぎゆか】
【福岡】フェイスグループ総合スレ【FACE】
【韓国】韓国に衝撃、トランプ大統領の「米韓合同軍事演習を中止」発言、「非核化語らない金正恩氏にプレゼント」
【新型コロナ】大阪大など開発の新型コロナワクチン、７月にも治験開始へ…国内初 [しじみ★]
【ファミレス】サイゼリヤ、525店に全自動お掃除トイレを導入導入 2億円投資
【２０年優勝無し】なぜ智弁和歌山は弱いのか【古豪化石】
日本ダービーを勝った馬の中で一番ファンが少なそうな馬
平面バッフルと後面開放スピーカー★５
村瀬紗英
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
