WPF(.NET4.x, .NET Core) GUIプログラミング Part23
レス数が1000を超えています。これ以上書き込みはできません。
Windows Presentation Frameworkについて語るスレ。
前スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22
https://mevius.5ch.net/test/read.cgi/tech/1513175747/
関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.net/test/read.cgi/tech/1499658092/
コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/ openfiledialogとsystem.diagnostics.process.startの違いはなんでしょうか
openfiledialogのほうがエクスプローラが開かなかったですが
実現したいのは、フォルダを開いてファイルを選択するというものです
var dialog = new OpenFileDialog();
dialog.InitialDirectory = @"C:";
System.Diagnostics.Process.Start("explorer.exe",@"c:"); openfiledialogはファイルを開くためのものですね
勘違いすてまし wpfでフォルダのファイルを、リストビューなどで表示するには何を使用するんでしょうか リストビューで表示するんなら使用するのはリストビューでしょｗ https://dobon.net/vb/dotnet/file/getfiles.html
wpfでaddrangeが出てこないのですが、なぜでしょうか
addしか出てきません
addrangeはSystem.Collections.Generic;に含まれるそうですが、これはきちんと記述しています
>>11
表示するコントロールはそうなんですが、一覧を取得する方法を調べてました >>13
wpfじゃないんですかね
だとしたら何を使うんでしょうか
マイクロソフトのリファレンスはC#用とwpf用わかれてるわけではないんですよね？ this.ListBox1.ItemsSource = Directory.EnumerateFiles( @"C:\Windows" ); もしくは
foreach ( var file in Directory.EnumerateFiles( @"C:\Windows" ) )
{
this.ListBox.Items.Add( file );
} >>14
リファレンスは分かれてるというか、違う。名前空間が。
datagrid にしても、forms で使用されているコントロールとwpfで使用されている物とは違う。
webにあるサンプルなど、どちらのコードかってのは、明記されてない限り読み込まないとわからない for (int i = 0;i< files.Length;i++) {
listbox_right.Items.Add(files[i]);
}
>>16,17
これでいけました
ありがとうございます
addrangeはないみたいなので、ループしないと駄目なんですね
>>18
名前空間で判断するしかない感じですか
formと共通してるものもあれば、違うものもあるって感じで、ごっちゃになってて少し分かりづらいですね >>19
>addrangeはないみたいなので、ループしないと駄目なんですね
違うんじゃないかな。あなたが、>>16の手段使わずに、>>17の手段つかった
からじゃないの？ wpfでレイアウトしたいです
よくある、左、中央、右というペインを作りたいです
単純にグリッドを３つ並べるだけでは駄目なようですが、良いコントロールはありますか？
>>20
そうかもしれません、、、 >>21
先の質問についてだけど、データバインドを理解していないんじゃないだろうか
WPF使うんだったら、データバインド使わないと損ですよ。 >>21
レスであるように、先にバインド覚えたほうがいいよ。いっぱいコントロール自作することになるから >>21
Gridを分割するかDockPanel
境界をマウスで動かしたりしたいなら前者 >>24
gridですか
formにあったsplitcontainerみたいなのがなくなっていたんでわからなかったです
>>22,23
知らなかったので。今バインドってのをやってみました
Xamlに変数をバインドしておいて、プログラム側でそれを書き換えるというイメージでいいんですか？
<Button Content="{Binding X}" />
みたいな感じですね
解説が難しいのでなんのメリットがあるのかイマイチわかりませんが、Xaml側のX変数が複数だった場合、手作業で何箇所も書き直すより効率的だねってことですかね。または、フォームを複数作った場合、別のフォームでも数値を共有できたり。 忘れます
もともとwinformのソフトの文字がちっちゃくて、不満だったから自分でつくろうと思ってるので
あれって、拡大とか出来ないんですね Data Binding なら、Vue.js だろ >>21
レイアウト関係はパネルっていう種類のコントロールを使う
ここをGoogle翻訳につっこんで読むといい
https://wpf-tutorial.com/panels/introduction-to-wpf-panels/
そんな難しい英語じゃないからそのまま読んでもいいけど >>30
他のパネルあるのになんでグリッド使うの？ >>31
wpfだとグリッドが一般的なやり方だと思っていたからです
どういうセオリーがあるのかまだわかっていません >>33
読みました
エクスプローラのような３ペインにどれが適切かわかりませんから、今ひとつずつやってます 今stackpanelを使っていますが、エクスプローラのように左右が細長くて、
20% 60% 20%というふうに出来ますか？子要素に何を指定するといいですか？%指定は出来ないようです。
絶対値を指定すると全画面にしたときにレイアウトが崩れるから駄目ですよね 更に境界線を←→で調整したいです
チュートアレば教えてください >>38
どうも 自動で境界線にフィットしてくれるんですねこれ
<StackPanel Orientation="Horizontal">
<Button Content="hoge" />
<GridSplitter HorizontalAlignment="Stretch" Width="5"/>
<Button Content="hoge" />
<Button Content="hoge" />
</StackPanel>
でもこれやっても動作しないのはなぜでしょうか？
ボタンも画面いっぱいまで広がりません。 >>41
GridSplitterは縦分割もしくは横分割したGridで使うものだよ >>36
>%指定は出来ないようです
おいおい勝手に決めちゃうな、ちゃんとできるよ。
単に2:6:2になる値にすればいいだけ。 mvvmという概念がよくわからないのですが、
mはモデル、vはビュー、vmはビューモデルですよね
wpfのプロジェクトでいうと、ビューはxamlで、vmはmainwindow.xaml.cs
mはビューに表示する数値を処理する関数を保存しておくファイル（自分で作る？）という感じでしょうかね
超絶簡単なチュートはないでしょうか？どこも説明が難しいです。 MVVMなんて最初は意識しないでformsみたいにxaml.csにそのまま処理書くのでいいよ >>46
*.xaml.csはViewの一部。ViewModelじゃない。 >>47,48
そうします
わかわからんですし、大規模になることはないので wpf & mvvm が普及しなかったのはこの敷居の高さなんだよな… >>50
コミュニティに頼らずに自前でそこそこサポートするのが売りだったのに、この辺りから放棄し始めたんだよな wpfって将来性がないってことですか？formの代替えって他にあるんでしょうか？ 極論するとWindows上で動くアプリケーション自体が下火だからなぁ
PC上のローカルなリソースを触らない限りはJavaScriptのSPAで書いとけばWindows以外でもそのまま動くし
MVVMもVueやAngularで始めるほうが理解しやすいように思えるし 想像ですけど、jsベースだとローカルでもwebでも行けるから便利ということですよね
v 機能からgridレイアウトをやって、ある程度形はデキたんですが、縦に目一杯表示されません。
調べるとverticalalignmentをストレッチにすればいいということなんですが、駄目です
親も子もストレッチかけてるんですが、どこが駄目でしょうか。
ウインドウのサイズがデフォルトのサイズの場合は１００％までストレッチされますが、全画面表示まで拡大すると、stackpanel_innerにデフォルトのサイズが適用されます。
https://ideone.com/3RZafi >>56
stackpanel_outerはDockPanelに変更して、MenuにDockPanel.Dock="Top"追加
stackpanel_innnerは無くすか、StackPanel以外(DockPanel/Grid等)にする ↑どうもデキたです
stackpanelがなぜ駄目なんでしょうか
htmlのインライン要素のような扱いなんでしょうか。 >>52
以前は、ストアに対応していない（しない）などの方向から
WPF終了説が言われていたのだけど、それが変化してきたようで、
WPFの利用がもっと増加する可能性も出てきたみたい
ここ数か月の発表に注意してみるといいかもしれない。
デスクトップアプリが見直されてきている流れもあるので。 MSが一度見限ったプロダクトを見直した例はない
時間は有限なんだからこういうのは悪い方に考えたほうがいいよ 「見限った」「見直した」って具体的にどういうことを指しているんだろう。 見限った → メンテナンスモードに切り替えた
見直した → 再度アクティブな開発を始めた
かな そういう意味でなら、WPFはまだ見限られてはいないわけだ。 WPFはとっくの昔にメンテナンスモードに入ってる
UWPだけがアクティブ >>64
>UWPだけがアクティブ
WPFはともかく、MSのこの数か月見てた方が良いよ >>65
Build 2019でCore対応以外になんかWPF/WinFormsの新しい話題あったっけ？
MSを信じるのは勝手だけど、本当にそれが自分にとってプラスになるのかは一度立ち止まってよく考えてみた方がいいよ
君自身のキャリアの問題だ 結局、ｃ＋＋が普遍的なんでしょうか。
やったことはないですが、個人で使うものではないとか。 >>66
そのCore対応がデカいんじゃないか
どれだけ投資してると思ってんだよ >>68
そう思う？移植完了の後はロードマップ真っ白なのに？
ちなみにdotnet/wpfは4人くらいで作業していて、必要最小限の単純な移植を超える仕事は厳しく禁じられているようだ >>65
core対応でアクティブだと言えるならWPFだけじゃなくwin formsも
アクティブと言うことになるけど…
アクティブじゃないよ
もう開発してないよ 一度捨てたと思ったデスクトップの必要性が再認識されてきている。
これから夏にかけxaml islandの話題がMSより増えて行くだろうから
まずはそちらを気にした方が良い。デスクトップもUWPだけで行きま
しょうというMSの方向性が大きく変化したことは確かだから。
UWPのコントロールもそれぞれが共有できる方向に変化してきたので。
ただし、FORMに関してのxaml ilandはどうやるの？という疑問はある。
とはいえ、WPFが新たに拡張されてという話とはちょい異なる。
この数か月のマイクロソフトの発表をみましょ。 >>69
もしかしてひとつのフレームワークに4人ってのが少ないとでも思ってる？ あれだけ押してるBlazorもフルタイムは1人だもんね >>73
MSレベルっつーか人月単価100万ってそんなに優秀じゃないぞ この中でvb.net派の人いるかな....
新しいプロジェクト作成するたびににC#に移行しようと思っても、やっぱりVB選んでしまう...
おかげでC#のサンプルでも即座にVBに変換できるようになったわ 別にVB.NETでもかまわんと思うけどね
C#を推奨したい日本マイクロソフトのバイアスがずっと続いてるけど、ちゃんと他人にも分かる様なコード書けば問題無い
まあ、それがVBプログラマーの悪い所だが VB.NETでラムダを多用するようなソースコードを書くと見づらくてたまらないんだよな
まあ一人で書いてるソースであれば好きにすればいいんじゃないとも思うけど
引き継ぎや担当者アサインのことを考えるとちょっとなあ
若手・未経験者に今更VB.NETを覚えさせるのも後ろめたいというか倫理的に問題があるし
かといって「VB.NET出来ます」っていう人のスキルって大抵VisualStudio2005～2008あたりで止まってる人が多いし
新しめの(VS2015/2017あたりの)文法を使うならそれこそC#で書くほうがスマートだし 俺は基本的にはVB派だが、ラムダ式だけは何とかならんかったのかと思うわ
あとヌル合体演算子はよ マイクロソフトが好んでやりたいというより、VBで行きたいという声がスゲー多いためにそうせざるを得ないということだろな。これが人間社会ちゅうものなんだろう。 リストボックスに画像表示するにはなんの関数を使うのか教えてください
ヒントだけでいいです
String[] img = System.IO.Directory.GetFileSystemEntries(
@" C: \Users\ワイ\Desktop"
);
//Directory.GetFileSystemEntries Method
for (int i = 0;i< files.Length;i++) {
listbox_right.Items.Add(img[i]);
これだとテキスト表示になります
そもそもlistboxはテキストのみなんですかね。 >>89
WPFの場合はコードはそれでいい。
XAML側でListBoxのItemTemplateを定義し、ImageのSourceプロパティに{Binding}でバインドする。
何を言っているのかまるで意味がわからないと思うが、それがWPFなんだよね。
https://docs.microsoft.com/ja-jp/dotnet/framework/wpf/data/data-templating-overview?view=netframework-4.8
まずはこの辺りのドキュメントを完全に理解できるようにならないと話にならない。
はっきり言って、今更こんな複雑怪奇な終わったフレームワークを無理に覚える価値はない。時間を無駄にする前にWPFは止めなさい。 じゃあ代わりに何をすればいいのですか？electronはメモリ食うという噂が
vs codeは実際そうです >>91
Windowsのデスクトップアプリは迷走しまくっている
UWPも先行きが怪しくなってきて、もはやMS自身も今後どれを推奨するか明確に決まっていないという無茶苦茶な状況だ
・スキルの汎用性を重視する : いっそWebへ乗り換えるか、ElectronでWebベースの技術で作る
・学習コストを最小化する : WinForms
なるべく時間を無駄にしないためには今ならこのどちらかだろうな electronですか、rpgエディタみたいなの作れますか・ >>92
横からですが、参考になりました。
いろいろググってて数年前の情報で、「新規開発で WPF を選択しない理由はない」みたいなことが書いてあって、
調べ始めたところでした。
ざっと読んだ感じ、昔の MFC や OWL の Doc / View みたいな感じ？ >>93
そりゃ作れるけど、ゲームならUnity使ったほうがいいんじゃないか？
ゲーム用の開発スイートだからゲーム本体はもちろんだが、簡単なGUIアプリも十分に作れる
あと個人的にアドバイスさせてもらうと、ゲームはまずゲーム本体から作った方がいい
俺も初心者の頃に同じことをやろうとしたことがあるから分かるが、ツールから作ろうとすると結局後で無駄になる
エディタなんてexcelで十分 勉強も兼ねてるので１から作ろうとしています
２ｄ専用のウルフエディタみたいなものを目指してますね
electronだと重いみたいなことが言われますが、２ｄなら問題ないと思います バインディングの超簡単なサンプルってないですか？
テキストボックスに文字をバインドするという仕組みなんですが。
<TextBox Name="textbox_center" Text="{Binding x}"/>
プログラム側でのｘ変数への文字の指定方法が見つかりませンでした
また、そもそもバインドとは、タグのプロパティに変数を指定する仕組みということでしょうか？
また、set ; getみたいなやつの意味がわからないです
超簡単なサンプルのページ教えてください >>97
> set ; getみたいなやつ
自動実装プロパティのことかな WPF binding
で検索するといっぱい出てくるよ バインディングが効かなかったのはTextBoxコントロールを使っていたからですね
TextBlockにしたら効いたのですが、なぜでしょうか？
どちらも単なるテキストの表示です Electron は、Chromium(ブラウザ) + Node.js(サーバー)だから、300MB もある！
ツクールなども、Node.js か、Ruby on Rails じゃないの？ そもそもデスクトップアプリ作るのにWPFがいまいちだからElectronって、後退してるよな。 C#経験が評価されて今度ASP.NETの案件に参画するかもしれん
同じC#だが、覚えるのキツイな
だがついにデスクトップアプリマンの俺がデスクトップアプリから脱皮する時がきたわ
windowsサーバーだから個人開発では使えないし潰し効かないのが難点だがな・・・ >>105
最近はASP.NET coreがあるから個人でもLinuxサーバで使えるのでは？ >>106
そうなんだ
まだASP.NET MVCの基本しか勉強してないから知らなかったよ
個人でLinuxサーバー構築してずっとパソコンつけっぱなしで扇風機でもつけて冷やしとけば良いのか？
しかしインフラの知識が少し弱いし、それだとPC一台専用で買って常に動かしとかないといけないよな？現実的じゃないわ
あとアーキテクチャがMVCの方とどの程度違うのかによるな
アーキテクチャが全然違ったらまたかなりの勉強が必要になるし あ、違うか
linuxのレンタルサーバーに実行環境をデプロイして自分で環境構築しちゃえばいいのか
レンタルサーバーって最初からApacheとかは入ってるから自分で環境構築という発想がなかったわ
いけそうな気がするな、うん >>107-108
VMwareなりVirtualBoxとか使えばいいだけだろ
メモリー8GB程度あればCentOSの最小インストールなら普通に動くし >>109
常時起動ならレンタルサーバ借りたほうがいいよ
てかVMwareにLinux入れるくらいだったらBash on Ubuntu on Windowsでええやろ Bash on Ubuntu on Windowsはないわ～ >>110
ケースバイケースだろ
個人開発でテストだけでレンタルサーバーまで借りなくてもいいだろうし小規模ならRaspberry Piとかでもいいし >>113
個人利用ならAzureやAWSの無料枠で十分 >>112
それは実装途中の物みたいだから続きを読んでいけばいいんじゃないかな（無責任） UWPの次の将来性のあるフレームワークができるまではWEBで食ってようかな
windowsアプリなんて金にならなさそうだし hoge{get;set;}
これの意味がわからないのですが、超絶シンプルな例ってないんでしょうか？
例えばテキストボックスコントロールのTEXTにhogeという変数をバインドして、
hogeにプログラムないでhoge="文字";などと代入する
その歳の仲介というイメージなのですが、具体的にどういう動きをするんでしょうか
プログラム内で"文字"をgetして、バインドされたhogeにsetする？なんて意味ですか？ 要は通常はxamlからhogeの値は参照出来ない
それを許可するための宣言がgetということですかね？ このレベルからWPFとか素人にハーフマラソン走らせるレベル >>120
君にはプログラミングは無理
肉体労働するといい 基礎からやろう？って何週間も前からいろんな人から散々言われているのにそういうアドバイスは一切無視して延々と質問続けるだけだからね
ツールは当然一生完成しないし技術は大してつかないで終わるよ >>120
wpfはviewとviewmodelをdatacontextを介してやりとりするんや
例えばmainviewのdatacontextにmainviewmodelクラスを指定した場合、
mainviewmodelクラスのプロパティの値をバインディングすることでviewに表示することができる
c#でもJavaでもプロパティは外部への情報公開を目的としてるから
その意図をそのまま利用しとるだけ
大分ざっくりした説明だけれど、もし全く理解できないのなら前でも誰か言ってたけど、
windows formにするかコードビハインドに書くやり方でまずはやったほうがいい
JavaScriptにもMVVMの概念はあるからそっちから攻めるのもありかもしれない >>120
内部変数を省略してるだけなんよ
private の内部変数がコンパイル時に勝手に作られる >>120
自動実装プロパティっていつ使うのって話ならWPFはほぼ関係ない
自動実装プロパティは.netの機能でWPFは.netの一部
というだけの話
これは基礎からやれって話なのか？だけど
今からならwindows formsは勉強しなくていいと言う人もいるし
実際しなくていいだろう
ただWPFの解説書に.netについての解説なんかないよね
1からやる場合こういう.netの知識が曖昧になっても不思議はないと思う
.netは追加機能も多いし巨大すぎる ＞ 今からならwindows formsは勉強しなくていいと言う人もいるし
＞ 実際しなくていいだろう
何を馬鹿なことを言ってるんだｗ
最近の初心者向け本では逆にwinformsしか説明してない
WPFなんて眼中にない >>132
素人向けだからだろ？
wpfはMVVMとかxamlがくっついてくるから、winformの方が初心者向けなのは当たり前だ で、ユニバーサルプラットフォームって
何と何と何があるのかな？ UWPとWPFの区別がつかない人がドヤ顔でマウンティング 最近増えてきたガラスのような表現のフレームワークはWPFですか? xaml islandが出てきて、UWPじゃないとできないという制約が
なくなってきたね。 逆に今後の新規開発や追加開発ではWPFもういらないってことなんだけどな
既存のWPF部分に手を入れざるを得ない場合を除き、常にWindows Runtimeで作る
それが今後のWPFアプリケーションの唯一の正しい作り方だ >>140
ジョジョでいう
シルバーチャリオッツレクイエムみたいなもんか >>141
スタープラチナのザワールドだろ
通常はスタープラチナの精密で力強い攻撃で対応して無理なら時を止める Double型をバインディングしたTextboxに小数点を入力するとエラーになり問題、Extended Wpf toolkitのDoubleUpDownをTextboxの代わりに使ったらあっさり解決...
今までわざわざstring型でバインディングして数値だけ入力制限したりあれこれしてたのが無駄だったわ Windows API Code Packというのは機能を拡張するものですか？
ｃ＃で使用できるんでしょうか？ Directory.GetFileSystemEntriesで画像を取得できますか？ >>150
関数の仕様をリファレンスで調べてきて引数と戻り値と動作を読んで、それでも分からないことがあったらそこを具体的に質問すると丁寧に答えてもらえるぞ wpf関係ないじゃん
何がC#でなにがwpfかもわかってないんでしょ
散々チュートリアルやろ？って忠告を無視して延々と同じような質問繰り返してりゃ答える側も馬鹿らしくなるよ 画像ってのがサムネイルのことならWindows API Code Packで出来るんだが
もう少し自分で調べたほうが良いと思うよ Windows API Code PackはForkがいくつもあってどれを使えばいいのか分からないな。
ライセンスも元のMSのページが消えてて良く分からんし。 ただ、ファイルシステムをCodePack使わずにWin32API使うと面倒になるからな
言うほど大変なわけでもないが、独特な管理方法で面食らったわ >>156
ファイルシステムってなんのこと?
フォルダー選択ダイアログとかを出すことかな 社内業務用にpowershell+.NETで簡易GUIを表示するようなアプリケーションを作る場合、商用ライセンスとか必要なんでしょうか？ どっちの意味だろう？
・（作成するアプリケーションの）商用ライセンス
・（VisualStudioの）商用ライセンス
よく主語が抜けてるとか言われてるけど
この場合、連体修飾語が抜けてるよね（今調べた） 後者の意味にしか取れなかった、というか前者の意味がわからん
社内用に作ったアプリに商用ライセンスつけるか、って話？ 社内配布でも基本的にはVSの開発者用ライセンス必要だし、
オープンソース使ってるならライセンス違反にならんように気をつけなあかん
自分個人だけで使うなら特にライセンス気にすることはないだろう うん
前者なら上長に聞けと思った
後者について VisualStudio Community のライセンスを調べたところ、
オープンソースプロジェクトや学習・研究目的ならどんな企業も問題ないが、
相談のケースはクローズドソースと思うので、以下の条件になるはず
・一般企業なら5ユーザーまで
・大企業（250台PCを所有、または売上100万ドル）なら、使用不可 VS Express2015なら無料で使用できますね
あとVS Codeを使うことも可能だが、WPFを開発って結構苦行かもしれんね メモ帳とかでソース書いてWindowsにプリインストールのcsc.exeでコンパイルした場合はVSのライセンスっていらないのかな？
スレチだけど 質問の仕方が悪かったですね
すみません
テキストエディタでpowershellのコードを書き、その中で.NETのFormオブジェクト達を呼び出してGUIを作ります
そのときに、powershellや.NETの商用ライセンス的なものが必要なのか知りたかったです
よろしくお願いします まさかの第三
・（実行環境の）商用ライセンス
だった OSSなんだしいらないんじゃね？（適当）
社内用ならそんなシビアに調査しなくていいんじゃね？って気もするけど超大手とかだとやっぱしっかりしらべるのかね？
超大手なら周りなり法務なりに聞けで済むか >>163
小規模企業でも大企業からの委託案件だとNG http://cointoss.hatenablog.com/entry/2017/02/21/121209
上を参考にexeにdllをマージしたのですが
Prism.dll、Prism.Unity.Wpf.dll、Prism.Wpf.dllは
exeのフォルダに置いていないと起動できません。
他のdllは削除しても起動できます。
なにか不足していることがあるのでしょうか？ WPF技術者探しても一人も見つからないあるよ。保守できないあるよ。 金出しゃいくらでも居るよ
技術者を安いおちんぎんでこき使わないで core3いいじゃん
これで少し手直ししたらlinuxにwpfもっていけるってことなのかい 残念ながらWPFやWinFormsは.NET CoreでありながらWin限定
WPFは大部分がC++/CLIで書かれているしWindows APIに依存しまくってるから、
まずはそれを全てポータブルな形に再実装しなければならない
百人月クラスの壮大なプロジェクトだ 100人月で済むならやりゃいいじゃん
壮大なプロジェクトって少なくとも１桁違うやろ >>180
一桁はおろか、二桁＝1万人月くらいは必要じゃないかな… MS社員の100人月ならドカタのサグラダファミリアだな そもそもポータブルなGUIに無理がある
swingの様になりたいのか C++/CLIって久しぶりに聞きましたね
もう聞くことはないと思ってた そもそもWPFなんだからWindows限定でよくね？ WPFはフルスクラッチでUIを描画してるから、アーキテクチャ的にはむしろWin限定にするほうが不自然 >>179
そうなん…
Win専用ならCoreにしても…
C++/CLIはたまに使う Chromium+AspNetCore+Blazor
次世代の.NET系デスクトップフレームワークはこうなる 過剰なクライアントサイド志向に対する最近の揺り戻しのムードの中で、サーバーサイドBlazorだけならワンチャンあったかもね
Blazorを正式なプロダクトとして推していくと決めた時点で、クライアントBlazorは廃止してサーバーサイド一本にするべきだった
Blazorといえばwasmのオモチャというイメージを払拭できない限り普及はない SSRはもとはクライアントでしか動かないjsが鯖で動くすごいって技術
だからjs以外の言語だとSSRはなにも真新しさはない古典的な技術だ
なのでBlazorでサーバーサイドをやる意味はない(api、MVC、Pagesで十分)
クライアントで.NETを動かすことに意味がある >>191
Blectronは知らないがElectronの.NET版という意味ならまさにそうだな
ググったらもうすでに同じ発想で取り組んでるOSSユーザーが少なからず居たから
もう暫くしたらBlazorでクロスプラットフォームデスクトップアプリが実用化するんじゃないかな 新卒で入った会社（５年前）がWinFormだったな。今も多分そう。
今はWindows用のコード書くことがなくなってしまったが、
あれはあれで生産性高いと思うわ。業務アプリだとデザイン性いらないし WPFも主ターゲットは業務向けだけど、日本のITドカタが業務システムと聞いてイメージするオーダーメイドなシステムとはだいぶ違う
米国では早くからシステムのパッケージ化が進んでいて、
パッケージベンダーにとっては一つ作れば多くの客に売れるから多くの開発リソースを投資してリッチなUIを作ることができる
そういう事情を踏まえて誕生したのがWPFなんだよ
日本でも近年は脱オーダーメイドが進みつつあるけど、既にリッチクライアントの時代が終わってSaaSになっちゃったからWPFの出番は来なかった 日本の業務アプリには御託並べるWPFプログラマは不要。
黙々と作業に徹するWinformコーダーが居ればよい。 業務にアクティブ要素、動的要素なんていらないからな。
コントロール全部並べてあって使えないところは無効化されてるだけでいい。
状況によって位置が変わるのをすげー嫌がる。操作ミスが増えるだけ。 バインドしてみたけど、まったくメリットが分からん...
http://marikooota.hatenablog.com/entry/2017/05/30/002059
とか、↓の方が簡単だと思う。
-- xsml --
<StackPanel>
<TextBox x:Name="tb1"/>
<Button Click="btn_Click">Count Up!</Button>
</StackPanel>
-- cs --
int count = 0;
private void btn_Click(object sender, RoutedEventArgs e)
{
count++;
tb1.Text = count.ToString();
}
誰か、バインドのメリットをアホな俺に教えて下さい... >>198
空白文字消されるんですね; 読みにくくてすみません💦 バインドの最大なデメリットは天才と無職しか使いこなせないこと。 >>198
あなたの作りたいツールがボタン押したら
カウントアップするだけの機能だけでよいなら理解する必要はない
でもたいていはそのテキストボックスには外部ファイルを読み取ったり、
データベースからデータをとってきて、集計したり加工した値が入るはずだ
その時にはbtn_clickのコードは肥大化して容易に1,000行を超える
その時には関数に切り分けたりすることを覚えるだろう
さらに進んでいくと、画面を凝ったデザインにしたくなったりユーザーの入力値を検証したくなったりする
そうすると画面のデザインを少し変えただけなのに
うまく動かなくなったりコンパイルエラーを起こすようになってきた
そこで画面は画面だけにしたほうが改修がしやすかったり、
デザインの得意な人にそれを任せることができるようになってくる
システムは機能や役割ごとに適切に分離していたほうが将来的にメリットがあり、
バインディングはそれを実現する仕組みの一つだ バインディングは逆に手順が可視化されないのが弱点
よくわからないけど動いていればいいならバインディング
そこまでしっかり自分で制御したいなら通常のコードで 手順の管理は量が増えると難しくなってスケールしないから
そもそも手順気にしなくていいように宣言的プログラミングしようぜってなったんだよ
ちっぽけなアプリ作るだけなら好きにすればいいさ バインディングにも弱点がある
相互関係で値が決まるときにその相互関係を結局人間が追わなくてはならない場合が出てくる
その時に非常にバグが取りにくい
それでFBはMVVMを捨てた スケールと言うけど小規模ならバインディングで対応可能だろうけど
それを超えるとまあ無理だろう 手続き的だと非同期処理も非常に弱い
今の時代非同期が無いということはまずない
非同期処理ではやはり宣言的プログラミングが強い
手順すなわち処理の順番に依存すると非同期処理は急激に難しくなる 従来型はスケールしないと言うけど世間の大規模プロジェクトはほぼ100%
従来型（手続き型）で作られているだろう
手続きが書いてあればツールと人手を使えば解消のめどはつく
宣言的な組み合わせの場合はロジックをすべて脳に入れて考えなくてはならないので
大きくなればなるほど人間が追いつかないと思う
逆にバインディングで大規模プロジェクトが今現在も使われているとは思えない 人間が追い切れない場合は実行してデバッグしかないけど
それがまたバインディングの場合はやりにくい >>209
スケールしないのを金と人数に物を言わせて無理やり作った
それが従来型の大規模開発だな
スケールはしてないんだよ無理してるだけで
脳に入れなきゃいけないことが多いのは手続き的なほう
なぜなら手続==処理の順番に結果が依存するから
長い処理を扱うときに最初から最後まで手順を頭に入れてなければいけない 画面単位で独立したロジックを記述してDBのみ共有する従来のスタイルなら余裕でスケールするよ
WPFは頭のいいアーキテクトがトップダウンでスマートな設計をするスタイルには適している
MSのプロダクトは基本そうやって作られている
一方、従来のバカでもスケールするスタイルで作ろうとするとWPFはフリーダムすぎて無茶苦茶になる そういうけどできてから10年以上立つけど
そんなに大規模のプロジェクトでWPFが使われてるような形跡がない
webでもMVVMは中規模から小規模向けで大きくなると使い物にならないという評価 大規模で使い物にならなくなるのは、学習できない月収14万円のコーダーばっか集めてるからやろ 大規模な画面アプリなんてあんの？
普通サブシステム単位とかで実装別れると思うけど >>212
それは別の意味でスケールしない
DB処理にビジネスロジックが蔓延してメンテナンスコストが跳ね上がる
実行時パフォーマンスも悪い >>216
サブシステムで数百画面とかのシステムもありますので… DBとはバインドするのは良くて、画面とのバインドは良くないという論調？
大規模な画面改修を想定しない限り、画面要素のバインドは良い事無いと思う。
作り変えるのが前提のプロトタイプならメリット有るだろうね。
レジに支払い方法追加するみたいに、旧来のロジックはそのままでレイアウトが変わるならバインディングも有効だろうね。 >>219
one-way binding(射影)なら良いと思う。
個人的には当初MVVMの利点と言われていた「View(UI)のすげ替えが楽」なんてのは幻想で、
「自動テストが書きやすい（手動によるE2Eテストを減らせる）」というほうに重きをおくべきだと。 そう、だから自動テストという意味で >>198 を考えると、
btn_Click()イベント内部では"tb1"という他人のControlオブジェクトへ直接アクセスしている。
したがって"tbl1"Controlの存在無しに実行することができないから自動テストを書くのが困難になる。
これを、
・画面に表示されている値と常に一致しているカウント変数、という概念（＝データバイディング）
・実際にカウントアップする処理（＝ビジネスロジック）
・カウントアップするきっかけ（＝イベント or コマンド）
に分けて考えることでビジネスロジックの自動テストを書くのが容易になる、というのがMVVMのメリット。 >>212
WPF登場以降、MSのアプリ、ツールに一貫性がなく碌に使われずに開発が放棄され、
サポートしきれずオープンソース化される理由はそこにあるのですね。 >>223
OSS化=サポートしきれない
じゃねーだろ…どんな思考してんだよ >>224
オープンソース化の経緯も知らずに何頓珍漢なこと言ってんだよ。
プレミアサポートが碌に質問に答えれなくなってる現実まで知らないとか、
MSと契約してないか、開発してないかのどちらか。 >>226
Microsoftの中の人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!! 内容はともかく >>224の言い方も若干煽り入ってるし、ムキになる方もガキ こんなオワコン老害スレにガキなどおらん。
いるのは無職とヨコからマウンティングするだけの糞じじぃのみ。 WPFの使い勝手はともかく、使い手数に対して仕事はそれなりにあるんだからオワコンではないっしょ 60年現役のCOBOLさんを いつ消えるか分からんWPFなんぞと一緒にしないでくれたまえ笑 プログラム板にキチガイ降臨中！botに一晩も反応する異常さ
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
https://mevius.5ch.net/test/read.cgi/tech/1559872586/
142 名前：a4 ◆700L1Efzuv 投稿日：2019/06/18(火) 05:29:55 ID://qVkzO
>>141
名古屋の人な 俺ね、君の問題を大橋先生と混ぜないことにする。つまりね、
片桐孝洋のことをボコろうと思う。普通に顎の骨を折る。これくらいで警察来るか？
一般市民とかさ、普通にさ、俺らの秘密なんだけどさ、日本人なんて復活ねーから。 XAMLのデザイン要素は悪くないと思うけど
MVVMとかに関しては労力に見合ったリターンがあるか疑問
個人的にはバインドとかいろんな書き方できるのがすごくイヤ。
バインドでもx:Name=でも良いんだが、Pjによって原則どっちかでしか書けなくしてほしい。 両方じゃない？
昔の言語でgotoでスパゲッティの成果物があったとして、書いたヤツや規約も悪いしgotoオッケーの言語も悪い。 WPFで業務用アプリを作ってみたけどなかなかいいじゃない。
Material Design XAML Tool Kitのおかげでサクッと今風のUIが実現できて褒められたわ。
データバインディングしなかったからだと思うけどわりかし簡単に作れるし便利。 バインドは自分で全部やるにはまだ良いのだけど、他人のバグを解析する時のめんどくささが半端ない。 イベントがバブルがどうとかちゃんと理解できてないまま廃れ始めてしまった 言語がはやるかに、入りやすさは大事だからな。
バインドでキレーに実装したのに、メンテした奴が手続き型でやってるとスゲーがっかり。
人材確保がむずいなら、最初から手続き型でやった方がいーわ バインドのメリットとして分業しやすさが挙げられるけど、xaml と vmを別の作業者がやることなんてあんまり無いと思う。ほとんどのケースではコード量が増えてメンドイだけw MVVMはクラスの数が増えるけど画面更新が楽なのがいい
ReactivePropertyと組み合わせるのが好き テストせんやつにテストの楽さを説いても仕方ないやろ VMのテストをしてもE2Eテストをしなくていいわけじゃない
振る舞いが複雑化する傾向が強いMVVMはテストにおいてもデメリットが大きい
単純なMVCならE2Eテストも楽ちん >>256
手元のWPFアプリソースでもみればいんじゃね？ ジャ…どこかのSIerらはE2Eテストを人力でやるのが最良だとみなしてる節があるがな >>258
それは正しいよ
一度きりのテストなら自動化はコストに見合わない
SIerなら納品後はどうせあまり弄らないし、仮にメンテが必要になったとしてもは都度工数を請求できるから無問題 なんと言っても数字でレイアウト出来るのが良い
マウスでポトペタは楽だけど美しくするには可也面倒だからね 単純なMVCアプリしか作ったことない人：「MVVMは複雑だからテストが大変」
こういうこと？ >>262
事実やで
というか論理が逆で、そもそも複雑だからMVVMを使うんだよ
だから典型的なWebMVCに比べてテストが大変なのは当たり前 MVVMのテストは楽だと思う。
コーディング・テスト・バグ修正の合計時間で考えると得してるかは疑問だけど。 >というか論理が逆で、そもそも複雑だからMVVMを使うんだよ
なら原因はMVVMであることではなくてその前に複雑であることになるが、
自分が何を言っているか理解しているんだろうか。 >>266
だからそう言ってる
UIの要件が複雑だからWPFを採用し、WPFが複雑だからMVVMを採用する 少なくともUIに関しては複雑だからより、見た目的な理由でWPFだと個人的には思ってるｗ >>267 >>269
中身なしで罵倒し合うのって、ガキの喧嘩過ぎて見苦しい >>271
罵倒はしてないよ
ソース見てみたいなーって話 >>271
罵倒って>>273みたいなやつのことっしょ 上でテストの話が出てるけど
エンジニアたち「できたっぽい！」
上司「テストして」
エンジニアたち「一通り動いてます！」
上司「エージングもたのむ」
エンジニアたち「丸一日動かしっぱなしでもOKでした！」
上司「了解」
という雑な開発しかしたことない自分にはついていけない… むしろ簡単なPJの方が世の中多いし、自動テスト作らなかったら困ったであろうことは5年やってて一度しかないw 俺は自動テストは一部のモジュールの単体テストでしか使わんなぁ
プロジェクト単位で導入するんじゃなくて、個人で導入するものかと 自動テスト無いと困るよ
エクセルスクショは精神を病んでしまう
病んだら困る SIerは縦横に広がるテスト書に満足する顧客が多いからな～
金持ってる大手ほどその傾向が強い(笑 大概自動テストのシナリオ書いてる手間で打鍵した方が早かったな
シナリオが使い回せるならまた違うだろうけど 大手だとテストシナリオ書いてる人と実際にコード書いてる人は別
SEが馬鹿みたいに多くいて何か月もずっとテスト仕様書を書いてる エクセルよりコードのほうがシナリオ書きやすい
コードでシナリオ書いたら実行工数は0
1回しかテストしない場合でもコードで書いたほうがいい >>283
タウンワークで時給1600円のテスト要員募集してたな。
「コードは書きません、短期長期どちらも可。」みたいな Prism 7.1 のチュートリアルサイトないっすかね
妖精作戦さんのところは読み物としてはとても良いけどソースはGitHubな！なスタンスなので使いにくい…
公式のチュートリアルは WPF (Legacy) で 6 版のままだし
モヤモヤしながら勉強中 NVVMでは~.xaml.csには何も書かないのが理想とのことですが、例えば他のwindowを開くような処理はビューモデルに記述するのでしょうか？
根本的な疑問は、~.xaml.csに何も書かないということはモデルでできることが何もなくなり、その代わりモデルに記述するのでべきことを全てビューモデルに記述することになってしまっておかしいのでは？ということです。
私が何か勘違いしてるのは間違いなさそうなのですがそれがわかりません。。 .xaml.cs
に書くのはMODELではなくVIEWMODELでは？ >>287
あくまで自分の場合だけれど、
画面を開くとかメッセージ出すとかはそれ専用のサービスクラスを作ってる
そしてviewmodelからそのサービスを呼び出すようにしている
viewはicommandを介してviewmodelに通知するだけで、
その後どのサービスを呼び出すかはviewmodel、
実際の処理はサービスクラスに書かれている
コードビハインドに書いた方が圧倒的にシンプルになる場合はコードビハインドに書く VSMでストーリーボード動かすよりイベントハンドラから動かしたほうが圧倒的に楽なんだよな
その場合はコードビハインドに書くしか無いが 今時アニメーション？
世界で唯一の成功したWPFアプリケーションであるVSはもうアニメーションなんて全く無くなってるのに なるほどありがとうございます。
~.xaml.cs=モデルだと思い込んでました。
~.xamlと~.xaml.csはコンパイルされて一つのクラスになるってのは知ってたんですが、つまり2つ合わせてビューなんですね。
おかげでWPFのMVVMの説明がわかるようになってきました。 WPFって、直感的にはすごく簡単そうなのにいざ実現しようと思うとやたら難しいってことが多くない？
テキストの内容が変わったらその時にテキストを2回点滅させるっていうシンプルなことをしようとしたら大変だったんでそう思ったってだけだが。 >>287
ビューにはビューの処理だったら書いてもいい
無理してコードビハインドを避けても自己満足できるくらいしかメリットはない Listboxにバインドされたコレクションがあってlistboxitemを
右クリックしてコンテキストメニュー出して元のコレクションからitemを
削除するのってどういうのが一番シンプルなんだろうか >>298
http://ideone.com/HrFr9B
右クリックしたListBoxItemの内容をCommandのparameterに渡してみた
一番シンプルなのかどうかは知らん >>297
クラスを継承して機能を拡張するのはよくないと思う
理由いち 代替策があればそれを使ってクラスの肥大化を回避する
理由に 機能をビヘイビアにすれば再利用が簡単 継承じゃなくてイベントハンドラじゃね？主に
ビヘイビア化は後で別のところに使いたくなってからでも遅くない >>300
再利用するための仕組みは再利用される可能性ができてから考えればいい
再利用しないのに手間をかけるのはムダ
ちなみにここで言ってるのはメインウィンドウとかオプションダイアログの話な
メッセージボックスみたいな再利用性の高いものはWPFの機能を駆使してもいい
玄人はコードビハインドを書かないみたいな風潮があるけど、それを信じ込んでコードビハインドを避けて泥沼にはまり込むのは素人 UserForm内のDatagridが展開されるときにチラチラするんだけど、何とかならないかな...最小サイズから最大サイズに拡大するような描画がある。MainWindow直ならない現象 自分で作ったユーザーフォーム内のDataGridのItemsSourceにバインドしたコレクションに要素を追加するとチラつきます DataGridはゴミだから、WindowsFormsHostでDataGridView使ったほうがいいよ MSから新しいGUIライブラリが出たらまずDataGridを調べて絶望するまでが儀式だぞ DataGridの問題の殆どは、万単位のデータを突っ込むPG、SE,
クライアントの何れかだとは思うんだがね
実際に使う人は万もスクロースしちゃいないのに それは一見意識高いようでいて矛盾した意見だと思うね
十分に練られた優れたUIにはデータグリッドの出番はない
データグリッドはそもそもUIの作り込みに工数をかけたくないときに使うもんだ
そもそも手抜きの道具なのだから、データグリッドの使い方として、面倒だからもう全部突っ込めというのも自然な発想だろう MVVM原理主義派とカジュアルMVVM派では話が交わる事はない
どこまでMVVMの作法に則るのがベストかで線引きして適用するのがいいよね wpfをマスターしきればMVVM原理主義でいっても苦労せず実装できるので原理主義でいいと思うんだよ。
ただwpfは難しい。並大抵のエンジニアでは原理主義で押し通そうとすると実現できない機能がでてきて挫折する。
と思った。 WPFに携わってだいぶ経ったが、Adorner関連は苦手。
なんでペタっとUserControl貼れないのか すっかり忘れ去られてLivetだが、ビヘイビアが物凄く充実しているから
そこだけ引っ張って使うのもありだとは思う 更新が続いてればprismとためはるレベルでスタンダードだったんだけどな…
惜しいライブラリをなくしたもんだ MVVMやろうと思ったらフリーのライブラリを利用しないといけないと判って取り組むの止めた
MSから標準で出して欲しかったな Livetは形骸化した原理主義に陥ってコードビハインドを書かないことが目的化していた印象
コードビハインドの代わりにXAMLでプログラミングをし始めて、結局ビューとロジックの分離とは何だったのか状態になっちゃった
MVVMの根本的思想はWebにも受け継がれている優れたものだけど、ビヘイビアは明らかに失敗 >>320
jsonもフリーのライブラリが必要だから使わないの？ >>322
貴方が思っているほどjsonはスタンダードではありません
ドカタ業界ではjsonを知らない自称ITスペシャリストは決して珍しくはないのです >>324
MSのサンプルコードですらNewtonsoft.Json使ってるのに？ JSON.NETの作者もMicrosoftの人間だがな >>320
PrismはMSが作ったんじゃなかったっけ >>332
元々はMSが作ったサンプルコード
今はMSが開発やめてMSとは何の関係もないコミュニティプロジェクト jsonってただのデータフォーマットでしょ？
MVVMと何の関係が？ ReactiveProperty標準にしてくれたらいいのにな。 jsonは.net core 3で標準ライブラリが用意されるだっけか？ 設定ファイルとしてはXMLよりJSONの方が見易いんだけどコメント書けないのがなぁ でもXMLよりデータサイズがかなり小さくなるからやっぱりjson使う 復活じゃないと思う
win10ではUWP使え！から他のものも使ってもいいよになっただけ >>336
標準は既に存在するが、それでもMSの人がjson.netを使うほど
json.netの方が出来が良い >>342
最近はMicrosoftも脱Json.NETの流れだけどね
レガシーなコードの塊で、後方互換性を担保しながらパフォーマンス改善は難しいことがわかったから VS2019の横のニュース欄にjsonの新しい標準ライブラリの話が書いてあったね
みんなあんなの読んでるのかな？ >>344
一般ユーザーは知らなくても、フレームワークが裏で使っているライブラリが変わることでこっそり恩恵を受けている Visual StudioのRESTクライアント生成機能使うとJson.NETを使用するコードが生成されてたけどこれ標準ライブラリ使用に置き代わったの？ >>347
.NET Core3.0と同時リリースだから今年の9月 >>346
それはWPFじゃなくね？そのうちスレチって怒られるよ >>349
自分もjsonライブラリの話しててそんなこと言うか >>351
糞かもしれないけどわかりやすくてそこそこ早いから流行ったんでしょ？
もとからあった標準ライブラリがクソ中のクソすぎてMS内部の人から見限られてる状態だから >>353
うん、くそだけど一番人気あるのは事実。
俺の用途に全く会わなくて俺は自作したわw
だから、.ner core 3の標準ライブラリはwelcome >>355
おまえに興味の無い話なら黙ってればいいだけ >>352
マイクロソフトがjson.net離れしてるって流れなら>>346も流れに沿ってるよね 久しぶりにUWPからWPFに戻ってきたけど、FormattedTextやら、Obsoleteが多くなってるね。
しかし、IOをフルに使う身としては、WPFは快適だ。 UWPでは、FTDIチップ使うのさえ四苦八苦。 JSON.NETでもdynamicは使える
ジャップ製マイナーライブラリの出番はないよ >>368
誰か保守してるの？
まぁ Prismしか使ってないけど・・・ 亀すまん
>>301
すべてのコントロールのイベントハンドラをMainWindowに書くのか >>369
okazukiとかそのあたりだった気がするわ >>371
合ってる
ReactiveProperty作ってる人 >>373
okazukiはMSの中の人だけどLivetのメンテは趣味でやってるだけだよ >>374
あ、いや個人がメンテしているライブラリは趣味で使うんならいいけどねって話 reactivepropertyだってもとはneueccって人じゃなかったっけ？
okazukiは他人に寄生してるだけのイメージ >>375
それだとオープンソースの多くが使えなくなるぞ >>376
オリジナル製作者ではないけど、何年も積極的にコード書いてるのに酷い言い草 reactivepropertyは便利だよねぇ。 打ち込み量が減って、本来のNotifyPropertyChangedの書き方忘れちもうた。 なんでメンテナーが個人か企業かで扱いがかわるの？
ライブラリの良し悪しとかライセンスが問題ならわかるけど >>383
むしろ個人メンテナーなライブラリを避けるほうが正気か？って思うよ
メンテナーがどうのこうのより使いやすい、利用者が多いで選定すればいい >>387
業務でも一緒だよ
おかたいところでライブラリの使用許可云々が厳しいところもあるだろうがそうじゃないとこもあるよ
スマホアプリなんかだとわかりやすいと思うけど権利表記に並んでる使用ライブラリには個人メンテナのものなんて山ほどある
↑で出たreactivepropertyなんかもそうだし、unity製ゲームなら多くのアプリでunirx使われてる
任天堂が出すゲームアプリですら趣味の範囲というなら話は別だけど そういえば、Prismって今はメンテ二人だけなん？ すごいよねぇ。 Prism無しでは、何もできん身になってしもうた。
業務ユーザーも趣味ユーザーもかなり多いんとちゃう？ >>385
利用者が多いのは安心できる。
そうでない場合は便利でもバグが心配かなぁ。 WPF語るならPrismだよねえ。
WPFの、DDDとかアジャイルプロジェクトでデスマーチ一杯見てきた。
Prism使わなんだら、簡単にロジック分離できないのに、全く理解しないんだから・・・
しっかし、.NETにPrism組み込まなかったのはなぜなんだろ？ 企業がメンテナンスしてるOSSでも使い物になる保証は無いしな
金出して直させるなら話は別だけど 結局そこじゃないの
トラブった時に企業なら最悪札束でなんとかできる可能性はあるけど、個人に対してそれは無理だろう OSS GitHubにIssueして問題解決する実力無いなら使うなというだけでは？
OSSを避ける理由は実力問題以外の何物でもない。 札束使えるなりゃ不具合とかはその金で直せばいい
責任転嫁する先が欲しいって意味ならどこがメンテしてようとOSSな時点で同じ
最悪のケースを想定するならライセンスにあるとおり責任転嫁にはならん
企業ならメンツもあって真摯に対応する可能性はあるかもしれんが、そんなこと考慮してライブラリ選定するような開発環境なら始めからOSSなんか候補に入れるなよと思う >>380
それはBindableBase使ってるだけで忘れるｗ >>395
いやいや、いざ商用稼働してからバグって損害だしたら、それからissueだして対処しても無意味でしょ。
例えばmariadbなど無料のDBがあるにも関わらず企業が大金払って有料のDB使うのは実力不足とかではないと思うぞ。 >>398
>>無料DB
PostgreSQL,MySQLはそれなりに普及してる 普及してるけどそれじゃ不足するケースなら大金払うってだけでは？
システムに合わせたパフォーマンスチューニングしたいとか大規模運用ノウハウの知見を活用したいとか
そらそういう規模なり性能なりを求められる世界も山ほどあるでしょうね、としか >>398
バカ？ 395はそれなら使うなと言っている。 >>400
言い訳するためだろw
少なくとも俺はそう >>401
すまん、何を指してるのかわからんからもう少し省略せずに書き直してくれんか？ プロプラだってほとんど免責条項付いててサポートの質が違うってだけの話なのに
日本だと>>402の言うような意味合いに変わるからよく分からん まあDBでOSSを使うかどうかと、他のモジュールでOSSを使うかどうかは同じ基準ではないだろうね。
DB周りは障害が起きると金銭的に大きな損害がでる部分だから、DBの選定は間違いなくお金の話になる。実力があるからOSSとはならんだろう。 脳みそとあと目玉もだな
もしくは中央線に飛び込んで死ねゴミクズ >>405
実力以外にリスクを避ける手段があるのか？ モマエはバカか？ DBに何かあっても実力で俺が直す！
掛かる期間？知らんな >>394
動かなかったら他に入れ替えるほうが健全だし早いと思うがね
いくら金積んでも速攻で直るとは限らん まあそれなりにユーザーが居るライブラリなら普通の使い方すれば大体動くわけで
何か起こったときは、大抵他のやり方があるものだが 入れ替えるのだって手間はかかるしノーコストというわけにはいかんだろう。
というか、金積んで入れ替えられるならまだましで、OSSは下手したら全部自分で
面倒見なきゃならん可能性もあるしな。 WPF使えるはおまえのような極一部の天才だけだからな。普及しないのは当然だ。 WinFormsだと簡単にできることが
WPFだとひと手間かかったり代替できるシロモノじゃなかったのは普通にイタイ.
あと外部のライブラリの使用が前提みたいになってるのも使いづらさの象徴みたいなもん
まあライブラリ使わせるのは構わんよ.
重要なのはそこじゃないから
ただしMicrosoftが率先して作るようじゃなきゃだめだ
なんだかんだ言ってもWinFormsが未だに廃れる様子が全くないことがすべてを物語っている WinFormsでPerMonitorDPI対応とかって最新だと簡単なの？？ 簡単ならWPF使う理由もあまりないかなと思って
簡単じゃないならWPFのほうが楽そう > なんだかんだ言ってもWinFormsが未だに廃れる様子が全くないことがすべてを物語っている
>>417 みたいなお爺さんにはそう見えるんだろうねw DPI非対応の時点で新規案件でWinFormsは選択肢から外れるな
適当なテストアプリなら使うが いやいや、高DPIがWPFしかまともに対応できないとか釣りだろう？
むりに若者ぶっているが話が古くないかな？ Windowsがどうこうって時点で若者らしさはないから気にするな WPFは衰退の一途だが、WinFormsも広く見れば廃れてまくってるよ
どんどんWebへ流出してる
WPFに比べるとWinFormsの方がWebとの間の開発者スキルのギャップが大きいのと、
年季の入った比較的重要なシステムに使われていることが多いのとで、WPFに比べるとWeb移行のスピードは緩やかだけど 現実問題としてWindows Server環境でもWeb化の勢いが止まらないからなあ。クライアントがブラウザに慣れたのとクライアントPCの性能向上もあって多少操作性が落ちてもアプリのインストールが不要なWebシステムが評価されるようになったんだよね。 ユーザー側としてWebUIの業務アプリ大嫌い
滅びればいいと思ってる リッチクライアントとWebクライアント隆盛はいつも繰り返してるよな
以前よりマシになったが、WebAppで作ると
前にできた事がなぜ出来ないんだコラ
って客がおこぷんしちゃう事がままある WEB技術は流行だの古いだのと使い捨てばかりで追っかけるだけムダ。
ユーザーからすればウザい広告の技術でしかない。
いかに客を騙して金を取るかってだけ。WPFと同じ。客にメリットはなし。 Web技術というか最近の技術はサポートライフサイクルが長くて数年と短いから、作って何年かは ほそぼそと保守契約して5年後とかに改修みたいなやつには入れにくいよね
.NET Coreも長くて3年のサポートだしやりにくい 外観こだわるならWPFだし
そうでなければWinFormsでいいんじゃないの Windowsアプリ希望 → 安定体質の企業 → 大抵外観にこだわらない → 大抵WinForms 然程外観に拘らないけど、Hi-DPI対応はしておきたいからWPFだな
WinFormsでも対応出来なくもないけど面倒だ WinFormsでも対応すべき解像度が限られてるし複数解像度対応とか簡単なのにそれすらできないのは技術が無さ過ぎる。 >>435
解像度が限られてるってどういうこと
そんなんで任意の倍率のスケーリングに対応出来るの 継承とか再帰が難しくて理解できないならまあしゃあないな。 外観に拘るからwinformなんだよな。UIをコロコロ変えるなって業務じゃ当たり前の話。 >>440
滲んだりレイアウト崩れてるのはださ過ぎる FHDで作っておいてそれを6/3,5/3,4/3,2/3に拡大縮小すれば
3840*2160,3200*1800,2560*1440,1280*720になる。
画面解像度を取得して変更後解像度を決定しthis.Controlsに対してLeft, Top, Width, Height, Font.Sizeを再帰関数でまとめてリサイズしてやれば大体のことは終わる。
この時ポイントは元のレイアウトを3の倍数で作っておくことでそうすれば縮小後のレイアウトがギザギザになることはない。
後はFormの部品と特殊なcontrolを調整するだけ。
これをFormのカスタムclass化しておけばForm毎に書く必要もない。 Coreの方のWinformsだか忘れたけどソースにPerMonitorV2の処理が入ってるの見たな
動くのかは知らんけど >>443
レイアウト倍数に揃える時点で面倒だけど
Windows10の標準のスケーリングサイズは25%刻みだから4の倍数の方が都合が良い >>446
爺がFHDのノートを125%とか150%にして使ってるだろ。
そうすると仮想解像度は1536*864とか1280*720になる訳だ。
1600*900の125%も1280*720。
だから1280*720対応が必要なんだよ。 老害「継承と再帰使えばできるだろ」
若者「へー、凄いですねー（棒」 若者と老人の人形で延々と遊びたがっているやつって中身はどっちなんだろうな >>449
俺？
年は老害の方だよ
WPFは使うけどw 解像度の話なら、画面の大きさでダイナミックにレイアウト変更できるUWPが最強なんだけどね
縦置きにしたら邪魔になるパネルを下の方に移動とか自由自在 極端な例を挙げて自由自在ってことを強調したいだけだろw 業務アプリは解像度ほか動作環境を限定してしまっていい状況が多いからwinformsで十分かな WindowsPhoneで縦にも使うかも知れないだろ！ 縦置きってかウィンドウを縦長にした時とかの話じゃね
XAML上でブレークポイント設定してテンプレート切り替えるという単純なサポートはあるね 例えば、しきい値より横幅が狭くなったら上部のツールバーを縦型に変更する処理などがXamlで書けたりする >>462
時代に取り残されたことを受け入れられないまま終わった技術に固執しているという点では、
もはやWinFormsもWPFも外から見りゃ大差ないけどな
さんざんそうやってWinFormsを煽ってきて、自らも煽られる側になったということだ
受け入れ難いかもしれないが、時代の変化というのはそういうもの WPF MahAppsを調査してるんですが、HamburgerMenuコントロールにEffectをつけると、コンテンツの内容すべてに、そのEffectが継承されてしまいます。HamburgerMenuのみにEffectをつけるには、XAMLでどう指定すればいいんでしょうか?
皆様のお力をお借りしたいと思います。 無職が何かいろいろ勘違いしてるようだな。基本的な事実をおさらいしよう。
vb6 & winform 普及した。今後も保守しなきゃならないシステムがいっぱい。
wpf 普及に失敗した。保守しなきゃならないようなシステムなんてほとんどない。 VB6をVB.NETへ移行すら簡単に出来ない様にしたマイクロソフトの失策 >>468
エクセル VBA に移植すればいいだけなのでは？＜VB6 >>466
？ これからの開発案件って無いという事？ 寂しい話では？ よほどトラウマでもあるんだろうな…
まあコボラーも保守で食えてるみたいだからそういうのを目指すならいいんじゃね？ >>469
VB6でもFORM有りきのアプリだけじゃ無いぞ
ActiveXとかは無理 >>470
何を今更
保守で必要ならWinFormsも使うし、新規なら当然Webを最初に検討するよ
今時Webできないとかさすがにあり得ないでしょ Winodws10は仕事に向かない。この失敗をMSは修正する気ないみたいだから、
もう新規案件はJavaでいいやって流れかな >>Java
ライセンス云々で新規案件減ってますが >>474
その意見に対する素朴な疑問だと思うが・・・
次のPC OSは何？
WIN7とか先祖返りの話じゃないだろうな？ それ以前にガイジに開発の仕事なんかねーよ
クッキーでも捏ねてろ 更新を機にPCを減らしてタブレットを入れるということは始まっている。
特定ソフト専用マシンがPCである必要がないから。 >>465
MahAppの問題じゃなくてXamlの属性はカスケード式だからどうにもならん
素直にコンテント内に効果を打ち消すスタイルを設定するしか無い >>480
ですかー
影用のボーダー作ってシミュレートしますわ え、タブレットでいいようなものをPCでやってたって無能の話なの？ PCをタブレット用途のUIにしようとして大失敗したのがMS。 タブレットOSの競争ではマイクロソフトが勝利した。一時はiPadがシェアを拡大したが、PCとしても使えWindowsが勝利した。
スマートフォンOSの競争ではGoogleのAndroidが勝利した。
アップルはまた没落が始まった。 それにしても言っていることが10年くらい前の話で変なスレッドですね。 とこがだよ
10年前にもこのスレで語られているような世界はなかったぞ >>485
そんなパラレルワールドの話じゃなくてWPFの話をしろよ 勉強法おしえてくれなんて言う人にはそもそもWPFは無理なんじゃないの？ >>489
コードビハインドスタイルでアプリ作ったことあれば、それをPrismでドリブンドライブに書き換えていけばいいだけでは？
テスト駆動、保守堅牢のためのPrismだで、、、
WinFormsでも、アプリ一本も作ったことなければ、まずはそちらから。 ドメインドリブンのこと言ってる？わけないか言い直してるし >>489
Prism.Unityが７で思いっきり変わっていて面食らったな
AutoFacなどの別のDIと同じように扱えるようにガワを乗せた感じ
とりあえずサンプル見て適当に作ればなんとかなるよ >>491
MVVM素組みはやったことあるんで
>>494
Prism自体ちょこっとしかかじってないんですわ
何かチュートリアル的なものがあればなーって思ったんだけど
地道にやります、ありがとう >>495
Brian Lagunasがいろいろ動画upしてくれてるやろ なんでカレンダーやチャートコントロールすら未だにないんだよ >>497
カレンダーとグリッドはだいたい標準のやつが使い物にならないからな…。DataGridViewはいい線いってた気がするけど。カレンダーは自分で作った方が使い勝手がいいよ。一回作れば使いまわせるし。
>>494
俺が多用してた UnityBootstrapper はどこにいったんだ カレンダーってせめてググルのライブラリより優秀なのを用意してもらいたいな。 MSが標準として出せるようなレベルのWPFコントロールを作るのって無茶苦茶難しいんだよ
テンプレートを当ててL&Fを自由自在にカスタマイズできるようにしなきゃいけない
カレンダーのように高級なコントロールほどそのための抽象化が困難、というか事実上不可能だ
まあ典型的な「過剰な抽象化」だわな
その反省でUWPでは色々諦めたけど、今度はガチガチすぎて融通のきかないゴミになっちゃった
設計って難しいね Xaml islandでUWPの使えるんじゃないか？
UWPでカレンダーあったっけ？ グレゴリオ歴以外にも対応可能とかやりだすときりがないからなカレンダー あんま漁ったこと無いけどカレンダーやチャートってgithubに転がってないの？
そういうの漁ってれば標準化がいかに大変かわかりそうなもんだけど
どうせ無茶な要求に答えきれない代物しかでてこないのなら別にいらないかな >>504
いらないってのは標準としてはってだけでOSSでいろんな人がいろんなパターンで作ってるのは欲しいってことね カレンダーは昔のWin32の時代からコントロールあるだろ。
UWPにもあるし、WinUIでもNumberBoxが2.2でくるのかも ごめん、『カレンダー』ってスケジュールアプリつくるとき用の高度のやつか？俺が言ったの単に日付や時刻を選択するコントロールだな。 だいたいNuGetからExtended.Wpf.Toolkit使っちゃうな UWPと同じく、WPFもWinUI 3.0に飲み込まれるの？ winui 3.0でUWPの依存を排除してxaml islandなしでも動くようになるらしいが、これはクロスプラットなUIフレームワークへの布石なのか？
どうなってるのかよくわからん >>511
普通にwindows上でUWPにしか用意してなかったAPIを通常のAPIにするだけでは？ 迷走じゃなく正常化だろ
とちくるって最新の機能を誰も使ってないUWPにだけ開放してたんだぞ
上がバカだとこうなるみたいな話 もうこの際デスクトップ案件でもElectronとかでHTML5で作るようにしたほうがいいかもしれんね
個人的にはC#と.NET好きだけど最近は迷走しすぎる WPFやWinFormsの.NET Core対応も全く将来のこと考えてない必要最小限の場当たり移植で、リリースしきったら逃げる気満々だしなあ
.NET CoreならSCDが可能だから後々MSが.NETのバージョンアップに合わせてメンテしなくて済むという判断なんだろうね >>517
.NET Core当ランタイムをバイナリに同梱する供給形態。 >>515
そこでWebBrowserControlだけ貼ったWinFormsアプリの出番ですよ。
JSからC#のメソッドfooが`window.external.foo()`で呼び出せるし、
"IE7相当なのでモダンな機能が使えない"問題もHTMLに
<meta http-equiv="X-UA-Compatible" content="IE=11" />
<script src="https://cdn.jsdelivr.net/npm/babel-polyfill/dist/polyfill.min.js";>
の2行をおまじないとして入れとけば大概何とかなるし。 とちくるって最新の機能を大して使われてないWPFに開放されてもだな
上がアホだとこうなるみたいな話 SwiftUIとかバインディングできるようになるの？
ってことは時代はMVVM? WPF Prism RegionでReact.js並みにコンポーネント画面にしたらおせーー。 もっと早く描画できねぇの？ ObservableCollectionをConverterでバインドしたいけど、初期化した時ぐらいしか発火しないから使い物にならない。どうにか中身が変わっただけで発火させる方法ないですかね...？ >>525
多分リストそのものじゃなくてザムルでアイテムテンプレートを定義してその中でコンバーター指定するんじゃなかったかしら 記憶が正しければ、ObservableCollectionはT型のINotifyPropertyChangedの面倒まで見ないので、自分で実装するしかないはず
誰かNugetで配ってるかもしれない
配ってないなら配ったら喜ばれるかもしれない ObservableCollectionをそのまま使うのは面倒臭いから
ReactivePropertyのReactiveCollectionクラスのObserveElementPropertyメソッドを使うかな https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md
winui 3.0でもxamlフレームワークを共通にしてcrossplat化着々進行中。
.net core 3.0の次の.net 5も計画されてこの2年が勝負。
未来は明るい WinUIは.NETで使用できますが、.NETに依存しません：
WinUIは100％C ++であり、たとえばC ++ / WinRTを介して標準C ++ 17を使用するアンマネージWindowsアプリで使用できます。 悲報
WinUIは、毎月のプレリリースビルドで、毎年3倍の新しい安定バージョンを出荷し続けます。 WinUI 3.0は.netに依存しない
ネイティブ（c++）で開発されている
WinUI 2.0との下位互換性を目指すが.netを多用したWinUI2.0の成果は捨てられるということ？ WindowsネイティブでAPIセットが提供されるから.net 5と何の関係もないし
クロスプラットホーム化も関係ない
そのページで挙げられているクロスプラットホームの例はReacｔ Nativeの話だし それもxaml islandとやらでなんとかなんの？ windows提供のコントロールクソダサイので独自にフレームワークでクールに描画しよう→WPF
OSの進化でいろいろ新しいことができるようになったけど
WPFは独自描画なので標準提供の機能は使えず更新待ち WPFを世に出してから今までの話な
WPFにこれからなんてあるのか？ｗ 今後はWinUIというUWPのガワを.netから使えるようにするらしいね
x:Bindは良いよ。早いってのは体感しにくいが、コンパイルでバインドがミスマッチだとコンパイルエラーにしてくれるのが
その代わり型は厳密に合わせないといけないけどね >>544
WinUI 3.0はWin32からも使えるようにするらしいけど、.NET 5からだとx:bind使えるようになるの? 更に.net 5でAOTコンパイル(.net native)もUWP以外に広げるし。オプション扱いっぽいけど
未来は.netにある >>544
WinUI 3.0はc++で開発される普通のwindows API群
".netもからも" 使えるようにはなるが,netの技術じゃない
MSはもう一度c++技術者をかき集めてるようだが… >>546
ちゃんと読んでないみたいだけど、.NET5のAOTはXamarinだよ
スマホ向け ああ、>>546で俺がWPFとかでもAOTでコンパイル出来るようになると言ってると勘違いしたのか。そんな事全く意味してねぇ。
ちゃんと主語書くべきだったな。
最近、>>531でクロスプラットなUI Frameworkのsurveyしたように、
そこらへんまでの未来の道筋の話しをしただけ。 ・.NET Nativeが.NET 5に含まれるのかどうかについては今のところ特にアナウンスなし
・現在予告されている.NET 5のAOTは.NET NativeではなくMonoを利用する。スマホやタブレット、およびwasmがターゲット。
・.NET CoreがAOTをサポートする予定はない。
これが現状 >>542で放置してもOKっていってようにWPFの話をしてるつもりは全くなかった。 ・現在予告されている.NET 5のAOTは.NET NativeではなくMonoを利用する。スマホやタブレット、およびwasmがターゲット。
monoを利用するってどこにかいてある？ 後謝るのは.net nativeと言うと特定の実装になっちゃうね。そこは悪かった。ネイティブコンパイルぐらいの意味で使っちゃった。
後俺が勘違いしてたのはmonoは将来的には捨てないのか？
流れとして.net core1本に絞っていくのかと思った。 >>555
連投するなキチガイ
言いたいことは一つのレスにまとめろや WPFも放置だし、C#もオワコン臭があるし、Windows10は結局糞UIのままで
Win7ユーザは移行先もなくサポート終了して路頭に迷うし、やっぱりゲイツのいないMSはダメだな。 あれ？ .NET CoreはCoreRTでAOT実装してたんじゃ？
と思ってレポジトリ見てみたら統合という名のフェードアウトに向かっててﾜﾛﾀ >>557
C#はこれから伸びる
Blazorの生産性と品質が高すぎて衝撃を受けたよ
これから先の業務系WEBアプリはもう全部こいつでいいんじゃないかな
Java相互運用とJDK提供で旧資産も活かせる >>557
C#はそんなにオワコン臭あるかな？
むしろ破壊的変更も含めて脱皮しつつあるように感じるが C#自体は一番好きな言語だが贅肉が付きすぎで新規さんにはつらいだろう
それに構文が古い
10年以上前から行末の;なくせとかさんざん言われてたけどヘジたんはもうこれで設計されたからと拒否
javaとも文法がかなりかけ離れてきたからするっとjavaから移動はしてこないだろうな
c++みたいなゴミでも新しい改変どんどん入れるようになったけど古い部分は古いままでとっつきにくさは変わらない 新しい言語はどうやったら記述量を減らせるかと学習コストを減らせるかを重視してると思われる
バカに使える言語を目指せば自然と人気が出てくる
でもバカが書いたコードを日常的に目にしなくてはならなくなる >>564
C#は必要な記述量が多いしブロックなどで行を食うような書き方が一般的なのでコードの一覧性が低い GOはバカが書いたコードも普通の人が書いたコードでも同じように見えるような工夫がされている
俺は嫌いだがそういう考え方もあるということで そういうのは実例示してくれないと
個人的には行末記号なし＆改行OKの言語は気持ち悪くてイヤン Javaで構築するの止めてC#にする場合が増えてるらしい そりゃ拡張子じゃないかーい
って言うボケかと思ったのに… 普及させたいなら
Forms廃止して社内開発リソースをWPFに集中させるから
頑張って移行してね！
ってやればいいのに。
んでForms無くすならVB.NETも切っていいし >>580
それに近いことをやろうとしたのがUWP WPFは既存の技術すべて置き換えるために作られたはずだけど
実際はそこまでのスケールじゃなかった
HTML VB6 winforms MFC
全部生き残ってしまった XAMLそのものはそこまでわかりにくくないだろ
ややこしいのはMVVM WPFはライブラリの出来は良かったのにGUI周りの出来が悪かったのが痛かったな。
あまりに貧相であれじゃ客が納得しない。 あなたのような優秀な方には簡単かもしれませんが、
わたしのような底辺にはわかりにくいのです
つまり広まりません >>586
何のことを言ってるかわからないけどWPFは半端だったのでいろんな機能をwinformsに頼らざるを得なかった
winformsを置き換えるものとしては実装が不足してる >>586
WPFのコアな部分はレガシーなウィンドウシステムを捨てて再設計するんだってそれなりに気合い入れて作られてると思う。
だけど色々出来る分複雑になってるのに、それをラップしてユーザーがお仕着せで良いから楽に使えるようにする支援ライブラリ的なものが足りな過ぎたね。
標準のコントロールもFormにあるのは一通り押さえておけば、MVVM抜きならそれなりに簡単に使えるのに。 XAMLでわかりにくいならhtml&cssのデザインは地獄だろうな
XAMLがいかに親切か実感できるぞ
タグで囲むデザインはもう飽きたからもっとシンプルにしてほしいけど
JsonかYAMLで WPFデザインってWin7のLunaテーマのイメージ >>591
WPF標準でも一応GUIのテーマが用意されてるけど、LunaやAeroで止ってる…
正にVistaか7の時代 >>589
ほんこれ
気合いの入れ方が中途半端すぎ 一度に全部学ばないといけないからだろ。xaml,データバインディング,MVVMと。最初俺も死にかけたわ。
androidやりはじめたときはレイアウトファイルのxmlくらいだったから敷居は低かった。で、随分後にandroidもデータバインディングに標準対応して、順番にゆっくり学べるからな。 かたや、WPFは一度挫折した後に作戦変えて最初はデータバインディングとかMVVMとか無視してアプリ作ってみようとしたが、ListViewとかItemsControl系はアイテムテンプレート使わねぇと仮想化できないし、
やっぱデータバインディングとかすぐに学ぶはめになったし。 データバインディング便利でいいじゃん。
表示とロジックを分離できて見通しがいい。 MVVM便利すぎてWinFormsでもMVVM使ってしまう体になってしまったよ わかるわー、
MVVM慣れるとレガシーは面倒すぎる というより、MVVM学ぶ前は、ソフトウェアアーキテクチャ？みたいの意識しないで適当につくってたから今になってMVVM以外で作ろうとすると困りそう あんた自分が勉強嫌いなだけじゃん
MVVM以前にもMVCやらデザインパターンやら
意識しないといけないものはいくらでもあったでしょう じゃ、おまえVB6やWinForms自体にで何か意識して作ってた？ VB6やwinforms時代にどんなパターン採用してたの？ DOC-View も MVCもWinForm以前からあるんだが?
個人的問題ならマ板でしろや 早く.NETでWin32を完全にリプレイスできるように
ならないな、はあ。 無理だろ
windowsとは何かと言えばwin32のAPI群とそれで作られたコンポーネントとサービスの塊だから MVVMのライブラリーがMSから出てない事を知って真面目に取り組むのを止めた MSは今間違いなく迷走しているよね
BGM:バッドボーイブルース OSS上がりはほんとテストしない。自己満足でドヤ顔で公開して放置。 思い付いたアイディアコーティングして形になったらそれで興味は失せてしまう
品質とか興味無い >>610 >>611
githubとかVSCodeのようなここ10年にない好調な分野で
WPFの失敗を取り返した >>607
もし奇跡が起きて.NET5が大成功したら、多くの.NETアプリはWebアプリとしてクラウド上のLinuxでホストされるようになり、
デスクトップのWindowsが単なるシンクライアントに成り下がる未来は来るかもしれない
万一そうなりそうだったら、MSは.NETを事実上Azureでしか使えなくするような縛りを入れてくるだろうけど .NET5って、選択枝がそれだけという事だろ？ 失敗なんてあるの？ Blazorが天下を取るのは目に見えてるからなぁ
業務系は全部これでおk >>616
.NET5が普及することが必ずしも.NET5の成功を意味するとは限らない
みんながVSCodeやRiderでC#を書いて、AWS上のLinuxサーバーで運用するようになったら、MSから見れば大失敗だ
そうなれば当然MSは.NET5を放棄することになるだろう
MSにとって利益になる形での普及が成功の条件となると、なかなか難しいよ 放棄ってどうするのさ
態々くっつけたのをまた分割するのか？ ＞.NET5が普及することが必ずしも.NET5の成功を意味するとは限らない
.NET5の成功だろ
言いたいのはMSの成功を意味するとは限らないだろ OSSとはいえ特許があるから、MSが.NET Foundationから手を引いたら現実には開発の継続は不可能だよ
もちろん、MSは当然そんな最悪の結果にならないように技術面や政治面でコントロールするだろう
仮にそのコントロールが普及を妨げる性質のものであったとしてもね >>614
アプリケーションフレームワークとツールの類を同列に語っても意味無い >>614
GitHubはただ買収しただけだし
そもそもgitはライナスの作ったものだし…
vscodeはGitHubがatomエディタ作るために作ったエレクトロンに乗っかってるだけだし
MSはあまり貢献してない >>624
AtomとVSCodeじゃElectron部分以外ソースほぼ別物だしMSはあまり貢献してないって暴論すぎる GitHubのプライベート数無制限もMSマネー後だしな
評価すべきところはちゃんとしなきゃね
とはいえモダンなGUIに追従できるポジションのフレームワークが
悉く壊滅し続けている惨状を埋め合わせるものではない、というか関係ない blazorってviewあたりはどうなってる？reactととかならmaterialやら色んなデザインのが今や豊富にあるけど。 dartとflutterはhammingbirdでwebのフロントエンドに進出だし、desktop embeddingでデスクトップも。dartは現状クソだからmicrosoftさんには頑張ってもらいたい blazor触ったこと無いんだけどwebアプリってことはローカルファイルの操作とかは難しかったりすんの？
開発補助ツールとか作ったりすんだけど、そういうのはやっぱデスクトップアプリのほうが向いてるよね？
そういうのもblazorでできるならちょっと触ってみようかなって思うんだけど >>630
なにができないかはWebAssemblyの制約に規定されるのでは？
俺もBlazor触ったことないけど 今はviewはRazorのままだな。WPFをcanvasとwebglでエミュレートするとかできたらいいのに。 BlazorっていえばWebAssemblyだと思い込んでたけどサーバーサイドがあるのか
やば、乗り遅れてるわ
https://blog.okazuki.jp/entry/2019/06/11/135621 WPF＋XamlIslandでUWPのコントロールを使うとき
スタイルをどうやって設定するかご存じの方いますか？
WPFプロジェクトだとUWPのXAML書けないです… ちょっと古い質問かもしれないんですが、WPFのプロジェクトを新規作成して Prism.WPF、Prism.Core、Prism.Unityをヌゲットで適用したんだけど Microsoft.Expressions.Interaction が参照に入らないのです
やりたいことは Xaml で ei:PropertyChangedActtion を使って View の Xaml だけで他のコントロールのプロパティを変えたい（ElementNameとTargetPropatyとかでできた記憶があります）だけなんですが、これはどこにいったんでしょうか。 補足です。当時はヌゲットがなかったから Expression.Blend とかをインストールして参照設定の拡張アセンブリから選んで使ってたと思います >>636
Blend SDKは廃止?方向みたいで、Xaml Behaviors for WPFがそれの代わり。
そのパッケージをnugetで追加して、xmlns:i=～やxmlns:ei:=～ってあった所は、
xmlns:i="http://schemas.microsoft.com/xaml/behaviors";に直せば前と同じに使える。 >>638
名前が変わったんですね
ありがとうございますやってみます MediaElementなどを実装したUserControlを
MainWindowでItemsContrlを使用し複数表示しました。
その中の1つが選択されたときWindowいっぱいに広げたいのですがどうすればできますか？
ViewModel側で選択されたUserControlは取得できています。 >>640
UserControl(View)をViewModelから参照するのはMVVMに反してるからオススメしない。
ItemsControのSelectedItemプロパティと選択中のViewModelとがバインディングできてるなら、
選択後にViewModelで全画面表示用のプロパティに値を設定すれば良い。
そのプロパティ値が変化したときにどうやってUserControlを全画面表示するかは、純粋にView(XAML)の問題だ。 >>641
やはりViewModelでUserControlを参照するのはマズいですよね。
プレイヤなので再生中の状態がそのままコピーされるとよいのですが。
全画面用のUserControlにどのプロパティを設ければよいでしょうか？
動画パスや再生時間を渡して読込からやらせるしかないですかね？ ItemsControl上でも再生とか停止ができて、選択したらWindowいっぱいにしたい感じ？？ >>643
そうです。
何かスマートな方法ありますかね？ 拡大されてるムービーがどれかっていうのが、アプリのロジックに関係ないならクリックのイベントハンドラで書くのでいいんじゃないかな
ItemsControlから画面いっぱいにひろげる方法は知らないんだけど、そういうパネル作るののかな？ >>645
そうですね。
今はUserControlをItemsControlに重ねて配置してVisibiltyを切り替えています。 PrismでRegion使えばチョチョっとできないかね 再生中の動画が流れたままシームレスにWindow全体に表示というのは厄介そう UWPならMediaElementにIsFullWindowってプロパティーがあって問答無用でフルスクリーン表示にできる
あと、ConectedAnimationつかえるんだがな >>649
>>650
ありがとうございます。
XAML IslandでUWPのMediaElementを実装してみます。 UWPのはウィンドウいっぱいというより、全画面表示だけど大丈夫かな？ >>653
やはりそうなの？
調べたらそれっぽいこと書いてあった
Microsoft.Toolkit.Wpf.UI.ControlsのMediaPlayerElementを使ってみたのだが
Sourceにバインドしても再生されない
Xamlに直接書くと再生されるのだが… .Net Core 3.0のWPFのユーザーコントロールのデータバインディングに関して質問なんですが、
MainWindow.xaml.csのコンストラクタ内でPrice=1000と代入しているのですが
TextBoxのText(Value)の値が0から変化しないのですが、どこが間違っているのかわかる方いますか？
テキストボックス内にカーソルを合わせて上下キーを押すと1ずつ増える/減るの動作は正しく動いているようです。
DecimalBox.xaml
<UserControl x:Class="test.DecimalBox" ...>
<TextBox Text="{Binding Value}" PreviewKeyDown="TextBox_PreviewKeyDown"/>
</UserControl>
DecimalBox.xaml.cs
namespace test
{
/// <summary>
/// DecimalBox.xaml の相互作用ロジック
/// </summary>
public partial class DecimalBox : UserControl
{
public DecimalBox()
{
InitializeComponent();
DataContext = this;
}
public decimal Value { get { return (decimal)GetValue(ValueProperty); } set { SetValue(ValueProperty, value); } }
public static readonly DependencyProperty ValueProperty = DependencyProperty.Register("Value", typeof(decimal), typeof(DecimalBox));
private void TextBox_PreviewKeyDown(object sender, KeyEventArgs e)
{
if (e.Key == Key.Up ) Value += 1;
if (e.Key == Key.Down) Value -= 1;
}
}
} MainWindow.xaml
<local:DecimalBox Value="{Binding Price}"/>
MainWindow.xaml.cs
namespace test
{
/// <summary>
/// MainWindow.xaml の相互作用ロジック
/// </summary>
public partial class MainWindow : Window, INotifyPropertyChanged
{
public MainWindow()
{
InitializeComponent();
DataContext = this;
Price = 1000;
}
public decimal Price
{
get { return price; }
set { price = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs("PriceData")); }
}
public event PropertyChangedEventHandler PropertyChanged;
}
} 以下の部分コピペミスです
set { price = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs("PriceData")); }
正しくはこうなってます
set { price = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs("Price")); } ちなみに、以下の部分を
MainWindow.xaml
<local:DecimalBox Value="{Binding Price}"/>
以下のようにするとTextBoxの値は1000になります
MainWindow.xaml
<local:DecimalBox Value="1000"/> <local:DecimalBox Value="{Binding Price}"/>においてデータコンテキストは
DecimalBoxのコンストラクタで設定されてるDecimalBox自身
DecimalBoxにPriceなんてプロパティは無いのでバインディングに失敗する
ユーザコントロール自身ではなく、その直下にGridとかのパネル置いてそれのDataContextに設定するようにする >>659
以下に変更したら動作しました。ありがとうございます。
cs側
public DecimalBox()
{
InitializeComponent();
textbox.DataContext = this;
}
xaml側
<TextBox x:Name="textbox" Text="{Binding Value}" PreviewKeyDown="TextBox_PreviewKeyDown"/>
もう一つ質問なのですが、
DataContextの設定を今はcs側でやっていますが、
これをxaml側で行うことって可能なのでしょうか？ >>660
自己解決しました
RelativeSource FindAncestorでUserControlまで遡ればよかったみたいです。
<TextBox DataContext="{Binding RelativeSource={RelativeSource FindAncestor, AncestorType=UserControl}}" Text="{Binding Value}" PreviewKeyDown="TextBox_PreviewKeyDown"/> >>659
> DecimalBoxにPriceなんてプロパティは無いのでバインディングに失敗する
こう言う時は実行時でもいいから例外発生させるなりしてくれればいいのにね Binding失敗してるとデバッグログとかにメッセージ出なかったっけ？ デバッグログに出るけど他にメッセージが多いと見落としがち
WPFにもx:Bind欲しい さんざん欲しいと言われてるはずなのに追加されない
なぜだろうね ないない
なんか勘違いしてるようだが、MSがWPFをCoreに移植したのはメンテナンスをしたくないからだよ
今後.NETランタイムがアップデートされてWPFが壊れても、Coreなら開発者は自己責任で古いランタイムをずっと使い続けることができる WPFはオープンソース化したんで何か起きるかもしれん WPFは.netframework+WinUIと入れ替わる予定じゃないかな
xamlソリューションとしてはこっちのほうができが良い 引き合いに出すのがCannaかいなｗ
Struts1とかのがヤバくね WinUIは100%C++で書かれたwindows専用API winui 3.0で新規に書き起こすんだから今なら下位のレイヤー取り替えられるようにするんじゃねぇかな？つまり、windowsから簡単に切り離せるように。 もともとwindowsの機能に依存したUIにすると思う
下位を汎用にすると設計が大変だから 下位を汎用にした結果がWPFの大失敗だもんな
まあWPFが下位に抽象化レイヤを入れたのは移植性を高めることではなくて自由度を高めるためだけど、
結局出来上がったのはゲロ遅くて無駄に複雑でMSによるアップデートも遅いゴミ
WinRT以降のOS側で高レベルなUIコンポーネントを提供する戦略は少々行き過ぎてる気もするけど、
少なくとも今更WPFの黒歴史を繰り返すことはないだろう 下位を汎用ってもflutterだってやってることだしな。描画エンジンの部分と入力を汎用化するだけで、googleエンジニアが出来てMicrosoftのエンジニアができないとな？
もちろん、それなりの手間が発生するが。 でもデスクトップPCそのもののシェアが減ってる現状で下位を汎用化してマルチプラットフォームにする価値あるか？というと怪しい気がする 下位に抽象化レイヤを入れたGUIフレームワークとしては既にElectronが成功を収めている
今更作る意味はないよ WinUIはFluent Design Systemのライブラリだし、別にタッチ専用という訳じゃないけど、クロスプラットホーム化狙うなら、まずはUWP/Android/iOSでしょうに。
WinUIはただのUIライブラリだから、プラットホーム特有のAPIも簡単に呼べるようにならんだが。
https://devblogs.microsoft.com/dotnet/introducing-net-5/
.net coreにもjava/swift interopelabilityが予定されてるし。 Electron上げるくらいならflutterの方が有望だと思う まぁ、俺はflutterに乗っかりつつあるけど、Microsoftはやる気あるなら急がんと。googleのflutterへのやる気すごい。 Electronを汎用と言うのは脳がいかれてると思う Webブラウザは明らかにPALと見做せるだろ
しかも対応するする詐欺ではなく既に各プラットフォームに実装が存在する PAL (曖昧さ回避)
PAL方式 - アナログカラーテレビ規格
Pilot Activated Lighting - 飛行場の灯火に関するシステム
フィリピン航空のICAO航空会社コード
プログラマブルロジックデバイス (Programmable Array Logic)
年間熱負荷係数 (perimeter annual load) - 建物の省エネルギーの指標
パレスチナ自治区の旧FIFAコード
江釣子ショッピングセンター パル >>669
オープンソース化してなんか起きたのってなんかある？WTL？ >>322
jsonと規模が違いすぎるだろ
アホすぎる >>690
規模とか都合のいい条件後付けすんなよwwwww >>690
INotifyPropertyChangedの実装をネットで拾ってくれば数十行のコピペで行ける
嫌ならライブラリなど使わなくてもいい オープンソース化したらソースが見れるからとドキュメントを書かなくなり、
ユーザもテスト丸投げで品質が下がって
誰も使わなくなって誰も保守しなくなるパターンはいっぱい見てきた。 PrismとかReactivePropertyみたいなもんを
汎用化してフル機能で実装するのは難しいかもしんないけど
必要な範囲を作り込むだけなら現実的な工数でできるんじゃないかな 同僚のプログラマはソース見れるからドキュメント書く必要はないと？ 今回のSDK更新でUWPDESKTOP完全に逝った？ BLE等々使えなくなってるんだけど、、、 .NET Core 3.0 のリリース以降はコミットも激減してるね
順調に終了に向けて畳みに入ったようだ とにかく終了してよかった。ほんと惨い仕様だったからな。 MS自身が終わったと公式にアナウンスしていないプロダクトが半端に世に残り続けるのは
良かったどころか地獄に巻き込まれかねんがな 勝手に皆がwinforms終わった終わった言ってたけど終わってなかった wpfけなしてるのって
winformしか分からない低スキルおじさんと思ってんだけど偏見だろうか それってとても重要なこと。低スキルには使えないなんて、
フレームワークとして致命的な欠陥品、ゴミと言わざるを得ない。
馬鹿でも使える、Delphi、VB6、C#+winformのユーザを取り込めるはずがない。
キミはwpf使えるおれ高スキルと自惚れてたようだが、実はこのスレでキミが一番滑稽だったんだよ。 日本の大半のコーダーはwinformレベルしか理解できないだろ 低レベルかどうか以前に使いにくい
listboxのアイテム右クリックして操作するのが非常にめんどくさい
ancestorのbindingとか見ると非常に汚いしこんなもん使いたくないけど使ってる RelativeSource FindAncestor, AncestorType={x:Type Window}
これが汚い
これが平気で使えるのは頭おかしい
データ構造で親クラスのコレクションにアイテムがあったと言うことにだけ依存して親にアクセスするならわかるが
Type Windowと言う変な依存を作ってしまうのが汚い 元のデータ構造に依存してデータ操作するならわかるんだけど
GUIのオブジェクトの構造に依存してまたそこからDataContext参照してそこでまた型が違うかもしれないものに対して
平気でアクセスしてしまう異常性
WPFは汚いよ
仕組みを作るべきだった >>712
そこ、Windowでも動くが、大体ListBoxだよな
それなら問題ないだろ >>711
10年以上前から言われてたから普及するわけないと散々・・・ vb6でもwinformsでもwpfでもuwpでもelectronでも何でも自分の用途にあってればいいわけで、テクノロジーや、それを使う人をdisったりする理由にはならないと思う
サポート切れてるのは新規採用は自分ではしないかなというくらいで後は好きなの使えばいい
そして俺はWPF好き 俺もWPFの方が好きだなぁ
XAMLで構造が編集できるのがいい >>712-713
> RelativeSource FindAncestor, AncestorType={x:Type Window}
> これが汚い
> これが平気で使えるのは頭おかしい
それなー
> データ構造で親クラスのコレクションにアイテムがあったと言うことにだけ依存して親にアクセスするならわかるが
いやいやそれは逆にビューがデータ構造に依存しちゃうからまずいでしょ
> Type Windowと言う変な依存を作ってしまうのが汚い
型で検索すると言うのが気持ち悪い
なぜビュー内の名前で参照できるようにしなかったんだろう？ >>719
別ファイルでDataTemplate定義してたりしたら使えないけど、ElementName使って名前で参照も出来る場所もあるよ >>720-721
まじか、知らんかった…
休み明け（今日は有休）に会社で試してみよう .net coreでグラフ画像を作る方法ある？
chartコントロール使えなくなったから、新しいやり方知りたい そういうジャンルはHTMLにもう任せてしまえば楽なんだけどなあ
jsのライブラリを使えれば一番楽だしGUI操作などもインタラクティブに行える
大量の人間が常に開発を続け最新のトレンドを自分の製品に取り込める
けどWPFなんでしょ？
これからもJSと比べるとライブラリ大幅増の希望もないけどWPFなんだよね ライブラリ増に関してはWinUIがある
大幅増じゃないが これからもOSSのライブラリ依存の状況は進んでいくだろうけど
そういうプロジェクトでユーザーや開発者が多いのはjsなんだ
最先端で使いやすいものを取り入れようとするとC#+WPFは選択から外れる
ごく限られた環境で使うときにWPF＋MVVMは使いやすい
しかし実際にアプリを作ると使いたいライブラリがなくあっても貧弱で古い事が多い WPFを使うのは自分が開発しやすいからであるが特定の最新機能などを使おうとすると
OSSが無かったり貧弱であったりしてまあ思い通りのアプリが作れないことがある
そういうのは個人ではどうにもならないレベルだったりするんだよね
自分が開発しやすいから選んだはずなのに実際はしやすくない
いつか誰かが作ってくれるのを期待して待つかそこだけ他の技術に頼るか
それかあきらめるか ヘタするとWPFで開発十数年の人が作ったWPF上のグラフアプリより
入門三日目のhtml+jsの作ったグラフアプリのほうが評価が高くなるかもしれない
そしてwebアプリは3日で出来てWPFは一か月かかるかもしれない
これからどう生きていくかは自分で選択してできるだけ狭い世界に閉じこもらないようにしないと環境と一緒に死んでしまう いやjsのほうが人選ぶだろ
型なし言語をスキルない奴に触らせると地獄
これからはBlazorな！ ユーザーの目が肥えて期待される機能の完成度のハードルがあがっていくと
高機能のありものを使うしかない
WPFに限らずC#に高機能な既製品が少ない WPF理解できずに逆ギレしてる ID:TtiCw1tS w
哀れやのう 書いてる内容noどこがWPF理解できずの部分があるのか教えてくれよｗ >>731
もう夢は終わったんだよ。WPFは消える。だがキミの仕事は安泰だ。
WPFの保守案件はWPFマスターのキミが独占できる。コボラーと同じ身分だ。 自分がWPF使ってるのはGUIデザインがやりやすいからでHtml+CSSは理解できないししたくない
自分が使いやすいから使ってる
トータルで優秀だとは思えないが自分の好みで使ってる
いつか死ぬのは見えているでも使ってる
愛があるとかじゃなく今自分のレベルで使えるのがWPFだから使ってる
使える部分だけ使ってる スレチだったらすみません
グラフ(データプロット)と表を並べるGUIを作りたいんだけど、最近のGUIプログラミングって、どの言語がおすすめ？
楽に覚えられてチャラいデザインにできたら御の字です
C#、MATLAB、Pythonは扱えますが、GUIプログラミングのことはよく知らないもので…… 俺はプログラムができてオシャレな物作れるんだぞと言うのをアピールしたいなら
java scriptがおススメ 俺はデータサイエンティストだぞというのをアピールしたければpythonがおすすめ
メジャーなグラフアプリもある 俺は泥臭い仕事何でもやりますアピールしたいなら
java scriptがおススメ >>739-741
ありがとう
泥臭い+オシャレアピールしたいからjsにします。 他人が書いたWPFコードは読めたものじゃないな。保守性ゼロ。 他人が書いたWPFコードは（>>744みたいな無能には）読めたものじゃないな。（>>744みたいな無能には）保守性ゼロ。
当たり前やなw これから.net frameworkと.net coreが統一されるというが実質は.net frameworkが捨てられるだけ
皆が.net coreに移るわけじゃないから結果として.net軍団は二分される
ゲームでunityに流れ込む人は多いけどWPFに流れてくる人は大幅に減ると思う まあWpfフェードアウトしてUWPのWinUIベースになるのは予想できるね
基本的にはWpfとほぼ同じでx:Bindなどの拡張があるから良いと思うよ
WpfにできてWinUIに出来ないこともあるけど、UIタスク以外からコレクションイジられるようになればいいけどな プログラミングのモデルをがらっと変えてくるのはともかく
性能や機能面で以前より劣るものをこれからの主流で御座いと押し付けてきた挙句
そのへんロクに改善せずに開発者の移行も進まず以前のフレームワークもダラダラとサポートし続ける
WindowsのGUI方面はWin8から今まで5年以上は時間と金をドブに捨てとるわ 正しい方向へ戻っただけだと思うけどね
Windows作ってる会社自身が、Windowsの進化が遅いから箱庭方式のフルスクラッチでOSから独立したGUIフレームワークを作るわーなんて言ってたんだぞ
糖質かよ MSの誰がそんなこと言ったんだ？
だいたいこんなゴミフレームワークですら叩くと信者がワラワラ出てくるがそいつらが本当の糖質だろ。
技術的な話題には一切入ってこない低スキルなのに。 どうも、Microsoftのこれからの方向性
この1年で大きく変化しているのを理解できていない投稿が
多いように見受けられんだけど。
来週のIgniteを楽しみにしよう。 MSのこれからの方向性？
「Azure全振り」だ
デスクトップアプリなんて商売としては最早どうでもいい分野であり戦略もクソもないよ > 技術的な話題には一切入ってこない低スキルなのに。
>>751の悪口はやめなよw 相変わらず非技術的な内容だと元気なID:ViGCTZCn w 過去ログも含めてこのスレの大半はWPFの悪口だが、
このようにWPFをゴミと言うだけで信者が顔真っ赤に絡んでくるから注意な。 ん？そりゃ悪口とその反論が半々てことじゃないのか？ ID:ViGCTZCnは技術的な話についてこれないならマ板で吠えてりゃいいのにw 昔は普及したかと確認する奴もいたが今はそれすらおらず、MSも匙を投げたようだ。
GUIフレームワークの話には入らないが必死に煽るレスだけは必死の ID:7wrIz40y みたいな奴のレスが残りの半分だな。 流行らないと言うなら無視しとけばいいのに哀れな奴w >>761
だからこっちは質問してんだよ。
質問に答えれないのになんでいちいちおれを煽るかね？ まじ糖質だな。
MSの誰が言ったんだ？ ヘジか？ シノフスキか？
答えれないなら二度とおれにレスすんな、糖質野郎。 好きにすれば良いだろう。
まったく自信ない奴らだな。 WPFが復権すると勘違いしてるやつらがいるんだよ
そもそもがメインストリームとして普及したこともないのに
winformsの方がまだ普及してた まだプレビュー品質だけどReact NativeをUWPに埋め込む機能をXAML IslandsでWPFに埋め込めるから、JSでやったほうが楽なものはそっちでやれるようになる日が、そのうちくると思う JSでやったほうが楽なもんは今でもJSでやるだろう https://devblogs.microsoft.com/visualstudio/all-things-developer-tools-at-microsoft-ignite/
の
> XAML code editor pop up, merge resource dictionaries and more
> In this release there are multiple new features for desktop developers building WPF or UWP applications.
> One such feature is the ability to open the XAML code editor window separately from the XAML designer using our new “pop up” button next to XAML tab:
くらいかな
WPFの話は
あまりの注力度に腰を抜かしかけた
さすがMicrosoft >>767
wpfとかで作ってるんだけど、このuiはJSならすぐできるのになぁ…というとき用を想定してた >>769
誰やねんWPF採用したアホ、、、今更オワコン勉強したないしどないしょ、、、せや！Reactがあるやん！
こうだぞ prsim のサンプルで
using Microsoft.Practices.Unity;の部分が
型または名前空間の名前 'Practices' が名前空間 'Microsoft' に存在しません (アセンブリ参照があることを確認してください)。
アセンブリの参照追加にもそれらしい名前がない
どうしたらサンプル使えるのか誰かおしえてください チュートリアルの手順通りにやればできるよ
何かをすっ飛ばしてるか異なるバージョン環境か 最初にPrism Template Packをインストしてその後nugetでunityはいれました。
参照にprism.UnityやUnityがあるのですが
ダブルくりっっくすると
このプロジェクトは、利用不可能か、またはビルドされていないため、オブジェクト ブラウザーで表示できません。プロジェクトが利用可能でビルド済みであることを確認してください。
一応ビルドはしているけど↑のメッセージがでるのは普通なのだろうか？
最新バージョン環境だと駄目なのかな VS2019の最新で開発してるけど問題ないよ
プロジェクト作るところからprism選択するけどそのへんもちゃんとした？ >>776
prismは７で大きく変わっているから、nugetする時バージョン下げないと動かないサンプルあるかもしれんね 新しいプロジェクトの作成で
Prism Blank App(.Net Core3)
Prism Blank App(WPF)
両方試したけど同じエラーメッセージがでます
WPFはフレームワーク4.8 4.72 4.6と試してみたけど同じだった 参考にしようとしてたところがPrism6.3でやってたようなので
公式のサンプルをまず参考にしてみます なぜ人は質問時にバージョンを明記しないしチュートリアル参考時にバージョンを確認しないのか WPFのスレあったんだね
<gridpanel>
<label>タイトルバー</label>
<textbox />
<stackpanel>
<button/>
<textbox/>
</stackpanel>
</gridpanel>
みたいな構成のコントロールがあるんだけど
タイトルバーをドラッグしたらcanvas上で移動するようにするには
どうしたらいいんだろう？
何かヒントをもらえると助かります
thumbでやろうとしたけど使い方がよくわからず
上手くいきませんでした… Canvasの中に置いて、DragDrop.DoDragDropじゃいかんのか？ 動かせたとして今時点の希望の動作が通常の使用に充分な物とは感じられないと思う
canvasの中だけしか動かないのは非常に不都合だろう そういう要件なんでは？
canvas上で移動したいって書いてあるし なんとなくcanvas上で動かしたいんだろうと思う
canvasなんて狭いしスクロールとかの制御も厳しい
実際に使うとゴースト出せて動かせるほうが絶対いい VS2019で、WPFプロジェクトを作って、MainWindow.xamlに対してデザイナを開き、
ツールボックスから「すべてのWpfコントロール」からメニューというものを
ドラッグ&ドロップしてみたのですが、普通のWindowsアプリのようなメニュー項目
にはなってくれませんでした。
FormアプリだとMenuStripなどで簡単に出来たのですが、WPFだと同様には
できないのでしょうか？ 「普通のWindowsアプリ」ってのがよう分からん
スクショでも貼ってくれぃ winformsはデザイナが親切で楽に作れるんだよ
WPFは知識ないと無理
ググってやるしかない
.net core版WPFだとさらにデザイナすら整ってない WPFでは簡単にはできません。そしてこれからも改善する余地もありません。 普通のｗｐｆ使いはxamlを直接書くから気にならないんだよな
アニメーションの設定でBlend使ったりは駿河 MSの人は目玉になりそうなものでこう決まったとなれば何でもかなりかっちり作ってくる
手間暇かけても作る
（blendもVSと別ソースで作ってたらしいけど）
逆に普段使いであれば便利だなと思うものはほぼ作られない
何年たとうがかわらず作られない
上からの指示がないんだろうなと思う >>788
単刀直入に言ってしまえば、メニューという名前が付いてますが、
パソコンの世界で伝統的に「メニュー」と呼ばれているものにはならないのです。 >>793
最近はAzureの糞サービスの乱発で一概に品質が高いとは言えなくなりつつあるけど、
やっぱりスタンドアロンなソフトウェアに関してはMSの開発力は神がかってるよね
Googleと違ってゴミもそれなりに綺麗に仕上げてくるから、泥舟を回避しづらいのが難点ではある ドキュメントを碌に整備しなくなってからがMSの衰退の始まり。
昔からのルール破ってコード書かない人がプロジェクトリーダーになるようになったから
軽視するようになったんだね。 https://www.reddit.com/r/dotnet/comments/bmq1py/is_wpf_going_to_be_cross_platform_in_net_5/
6 months ago
No. The whole point is to move WPF and WinForms to be able to target .Net Core, that's it.
Just because something targets .Net Core doesn't necessarily mean it is cross platform.
There is just too much existing software using WPF and WinForms and the point is to have
a migration path to newer technologies. .Net framework is not getting any more new features
so if MS wants WPF and WinForms to live on, they need to make it work for core.
Maybe one day they will be cross platform, but right now they are just too reliant on Windows
specific features. At this time they have explicitly said they do not want PRs adding cross platform
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
capability. Maybe sometime in the future they will work on cross platform capability, or maybe
~~~~~~
a group forks it, who knows.
I'd love to see WPF being cross platform. While it has a steep learning curve, you can do
some great things with it. 6ヶ月前:
Q: Is WPF going to be cross platform in .NET 5
A: At this time they have explicitly said they do not want PRs adding cross platform
capability. 6ヶ月前の時点で「.NET 5 がクロスプラットフォーム能力を持つことになるという
PRをしたくない」ということをMSは明確に述べていたそうだ。
つまり、.NET 5 は、来年年末も、クロスプラットフォームにはなって無いという
ことらしい。似た説は、海外のサイトで何度も見た。MSがマルチプラットフォーム
に積極的になった事は無いとのことだ。 Q: WPFは.NET 5のクロスプラットフォームになりますか
A: 6か月前
これは、Windowsシェル全体とパッケージ化サブシステムをパッケージ化しないと技術的に不可能です。
これは、明らかにMicrosoftの予定リストにはありません。
Winformsは、グラフィックスデバイスインターフェイスであるGDI +に対する非常に薄い抽象化です。
アプリケーションのUIを直接描画する方法を変更できるように、非常に薄いということです。WPFは、
この抽象化を拡張し、コンポジターアプローチと新しいマークアップ言語に置き換えて、
その合成エンジンを活用します。また、グラフィックデバイスサブシステムの3D機能へのアクセス
（DirectXおよびDirectDraw経由）を提供します。これにより、WPFはWinFormsができないすべての
素晴らしいことを（とにかく多大な労力なしで）実行できます。
言うまでもなく、いいえ。今ではなく、実際にはありません。これらの技術はどちらも、Windows
コンテキスト以外では意味がありません。ターゲットプラットフォームのネイティブグラフィック
エンジンが何であれ、Quartz、Weyland、XOrgを介して両方の抽象化を再作成する必要があります。
繰り返しになりますが、これらのプラットフォームには既に独自の同等のツールがあるため、
そうすることに興味のある人はあまりいません。 すみません、>>797 から >>800 は、Xamarin スレへの誤投です。 > WPFはWinFormsができないすべての素晴らしいことを（とにかく多大な労力なしで）実行できます。
いや、まずWinformsでできることをWPFにも労力なしでできるようにしてほしいんだが。 xamlの場合はxmlに馴染みがあるかどうかが分かれ目だな。
それさえわかっていれば本当に楽。 >>794
WPF Menuでググれよ…
https://blog.okazuki.jp/entry/2014/08/12/122541
ただデザイナでやろうとするとめちゃ大変（まあ慣れてないだけかも知れんが）
素直にxaml直書きのほうが楽だと思う > WinFormsができないすべての素晴らしいこと
これに対する需要がないんだな 少なくとも画面レイアウトとテストは楽になった。
formsの方が良かったことって何かあったかな。もはや思い出せない。 WPFアプリはおれおれレイアウトが多く使いにくいよな。とにかく操作に統一感がなく不便で最悪。
MFC、winform縛りだとレイアウト、操作性に統一性があって操作に迷わない。
無能デザイナというのは独自性、おもいつきばかりで使う人のことをまったく考えてない。 >おれおれレイアウトが多く
たとえばどんな？
VSCodeとかElectronのアプリだと従来のUIガイドラインから遠いものが多い印象だが。 13年頑張っても普及しなかったゴミをMSが切り捨てられない理由はなんだろうなw
MSの中にはもう技術的な話ができる管理職がいないんだろうな。 そもそも普及に頑張ってたか？ というレベルだしなあ
まあWindowsチームにWPFに限らず.NET技術自体が嫌われたってのは
MSのなかのひと達からもよく出てくる話よね WOW64は完璧だし、x86バイナリをARMで動かしたり、LinuxバイナリをWindows上で動かしたり、MSSQLのWin32バイナリをLinuxで動かしたりといったトンデモ技術も難なく実用化してしまった
これほどネイティブコードの移植技術に長けたMSに果たして.NETが必要だったのかは激しく疑問だよね
Windowsの進歩を見限ってWPFを作ったらWindowsに背後から殴られた件もそうだけど、Javaなど他社の成功を後追いすることに躍起になるあまり、
自社の強みに目を向けず、Windowsチームに技術的チャレンジをさせてこなかった反動が来てるんだろうね .NETは成功してるだろ。
C#があのVB6のOCX地獄をどれだけ駆逐したか。 OCXはバージョニングの仕組みに問題があったが、だからといって全てを抽象化してWindowsから独立したシステムを構築しようなどというのはあまりにも暴論極論
現に.NET Coreでは.NETはWindowsの中核技術から単にアプリに組み込まれるインプロセスなランタイムに「格下げ」されたわけで、
当初の構想からすると成功と言うにはあまりにも残念な結果だ vs2017だと
1.デザイン画面でGridをDockPanelに変更する
コンテキストメニュー/レイアウトの種類の変更
2.ツールボックスからMenuをDockPanelにドロップする
3.Menuのプロパティ/レイアウト/Dock/Top
4.Menuのプロパティ/レイアウト/Width,Height,VirticalAlignmentをクリアする。
5.Menuのプロパティ/共通/Itemsのボタンを押す。
6.コレクションエディターが表示される。
7.左下のコンボボックスからMenuItemを選び、追加を押す
8.右側のプロパティ/共通/Headerに文字列を入力してOk>90
9.DockPanelにGridをドロップして、GridのWidth,Height,VirtiacalAlignmentをリセット
ドロップダウンメニューは MenuItemのプロパティ/共通/Itemsのボタン >>811
WinFormsはまだ、Win32のコントロールを使っていたそうですが、WPFは
使ってないそうですから、もっと嫌われている可能性もありますね。
しかも、WPFは書き方もWindows伝統とはかけ離れて、HTML+JSの書き方に
近いようですし。 Windows伝統ってWin32のことかねぇ？FormsやMFCだってだいぶかけ離れてるように思うが。
イベントドリブンなところは共通しているかもしれないがHTML+JSだってそうだしなぁ。 主にコア部分の性能面での問題を抱えたまま
一級開発環境としてねじ込もうとしてたのが原因なので
WinformsだのWPFだのは関係ないのだ WPFの遅さが気にならない奴はプログラマの才能がない。 昔はjavaは遅いからダメだ！って主張多かったよねー
じゃあ今のjavaは良いのか？って言われると困るけど結果的には広がりは見せたわけで
速度なんてあとからどうにでもなるんじゃね？って思う
20年前のハード性能の向上比率と今のそれは違うので比較するようなものでは無いかもしれんが JavaのGUIコンポーネントはクソ遅いしダメダメだろ
結果的に広がってませんが。 javaの代わりにspanだの今後はutf8string?とか高速化を頑張ってるc#で書けば、クラウド代金3割くらい減らせたりしないものなのか? WPFは見た目がしょぼくて客から金を取れないのがすべて バックエンドはクラウド時代になって多少遅くてもとか言えなくなっちゃったからしんどい
まあでもWPFはデスクトップだから多少遅くてもいいけど >>825
さすがにJavaとC#なら有意な差は出ない
少なくとも、書き直してる暇があったらその手間をボトルネックの最適化に注ぎ込んだほうが間違いなく速くなる
MS製のものを除けばC#はJavaに比べてOSSライブラリの品質が低い傾向があるしな >>828
SpringとASP.NET Core、みたいなFrameworkの観点で考えると圧倒的な差があるけどね javaが昔遅くてダメだって言われてたのはJVMを経由するからという部分
世界的には微妙かもしれんが国内では間違いなく相当普及してる
20年前のエンジニアに言えば卒倒するレベルには普及してる
これを普及してないと言うなら普及してる言語ってなんだよｗ Java開発してておせーしねって思ったことは数え切れないほどあるけどC#では滅多にない
ビルドも実行も速い Javaは100%完全にサーバー向けにチューニングされてるし、
MSスタックほど開発環境とランタイムが統合されてるわけじゃないから、
開発中に手元では遅く感じやすいよね >>831
昔は、ローカル変数をスタックではなくヒープで確保するアホ実装してたからだよ。
一度書けばどこでも動くなんていうJavaの理想はコードを碌に書いたことのないアホどもの夢だったのさ。
JVMの最適化が始まれば途端に処理系によって動きが違うようになって速度は速くなったが理想は捨てられ、
世界的なJavaブームは終わった。なのになぜか日本だけがずっと使い続けて今に至る。
Javaは日本ではCOBOLの代替の地位は得たが、C#は何も得てない。 仕事はJavaでwebアプリ作ってるけどめっちゃ速いぞ 速さは究極的にはプログラマの能力次第
C#erってVBの存在のお陰でJavaに比べると平均的な能力は高いけど、
上位層同士で比べるとクラウドや分散処理には強くないイメージだな Javaで優秀だった人はみんな他の言語に行っちゃって今は残りカスしかいない
C#は今も昔も高スキル人材が安定してる 親方のMSにも言えることだけど、C#の高スキル層って何でもC#のコード書いて解決しようとして
結果的に事業や開発のスケーラビリティを制約するような方法を選んでしまう傾向がある気がする
その辺、CLIツールやクラウドサービスなど出来合いの小道具をうまく使ってチョチョイとやっちゃうのはUNIX系の人のほうが遥かに上手い >>840
良いか悪いかは別にして、少なくとも「何でもC#書いて解決しようとする」は自分で心当たりあるだろ？
俺が今まで会った「C#が得意」 失礼
「C#が得意」を自称する人は例外なくそうだったわ >>842
C#が得意と言った奴がたまたまC#だけが得意だったんじゃないか？色々できる人はわざわざC#が得意だなんて言わないだけで。
そもそも自分が会っただけの狭い範囲で語られても... なんでもC#で書いて解決
CLIツールやクラウドサービスなどの小道具
これ並列に語るもんなの？
C#erだってクラウドサービスは使うやろ 今時はなんでもコンテナにして疎結合しちゃうから様々な言語やツールをそれなりに使えたほうがいい
既存資産ファーストで言語を選んでコンテナを実装することがやたら増えた
逆に言うと既存資産が無い新規開発のときは何を選んでもいいわけで
なんでもいいならC#やGoなど強力な言語が出揃ってる今、あえてJavaを選ぶ意味は殆どない
レガシーとコンテナの橋渡しが今のJavaが担ってる仕事 javaとC#比べて速さ問題を比べてもあまり意味がない
ある程度しか変わらないから
10倍速いとかじゃないからな
速さを競うならC++
ネットゲームとか激しくパフォーマンスが要求される分野はC++が強い
俺は死んでもC++はもう触りたくない unmanagedのinlineでAVXを実装すればC#でも大差ないような。 >>846
言語じゃなくてFrameworkならC#(ASP.NET Core)が圧倒的ってもう結論出てる FortunesはSpringの10倍、PlainTextは100倍…
https://www.techempower.com/benchmarks/#section=data-r18&;hw=ph&test=plaintext jqとか使えば一瞬で済むことをLINQ Pad笑で書いちゃうのはC#erあるある でも、C#は遅いプログラムが多い。
M/Bに付属のドライバや基本アプリなどのインストーラーも遅かったし、
MSのC# 製のExpression Web 4も同等のC++製のFrontPageよりだいぶ遅い。
PIXELAのテレビキャプチャーカードに付属のテレビ視聴/録画再生アプリも
極端に遅い。途中でGCが入って30秒間くらい全く何も出来なくなる事が
あるし、テレビ番組表を表示するのも数十秒掛かるし。
一番技術が分かってるはずのVisual Studioも遅い。 他のC#スレ見ても、C#信者は配列が遅い、LINQが遅い、WPFが遅いと言っても受け付けない低スキルの馬鹿が多い。
CPUに関する知識が皆無。まるで20年前のJava信者、MIPS信者のようだ。 配列遅いって言って受け付けないって人は何使うの？
linqは言ってる人居るけど配列遅いなんて人居る？ >>856
おそらく、
僕(>>855)が遅い遅いって言っているのに誰も取り合ってくれなかった！僕の話を聞かないアイツらがバカなんだ！
っ言いたいんだと思う。 C++使ってる人はあらゆることにパフォーマンス求める人がが多いからなあ
C#使ってるとそこまで気にしない
例え10倍処理が速くても自分の糞アプリにはなんのメリットがないので速さはいらない >>841
まっっっっっったくありません
で、説得力は？ 配列が遅いって言うならポインタ使えばいいだろ
C#の昔からの標準機能だ ポインタ使ったら早くなる？
配列使ったほうが最適化しやすくて早そうだけど
ケースバイケースかな？ >>862
ケースバイケース
配列のインデックスを計算で求めてるような場合は最適化が効かず境界チェックが毎回実行されて遅い
そういう場合はポインタにするとめちゃくちゃ早くなる 逆に言えばC++なら糞みたいなロジックでもよく検討されたロジックのC#より余裕で早い可能性もある
でも大体はC++プログラマの方が一段上 >>866
でも free()/delete が難しい環境では GC はありがたいですね >>867
組み込みなどの事を言ってるなら、GCの中でfree()/deleteが呼び出されるので同じ
どころか、もっと複雑になってしまう。 GCが遅いってGen0はそこまでじゃないだろ
まさかGen2前提じゃないだろうな コントロールを縮小して印刷するのにおすすめの方法を教えてください テンプレートはc++よりc#の方が早かったり
するので使い方次第だと思うのですけどね >>873
それはコンパイル時間なのではないですか？ 定期的に湧く、C++より速いとか、C#は遅くないと言ってる低スキル君が、Java信者と言ってることがいつも同じでむかつく。 >>874
同じ内容の処理でC#がC++より速くなるケースが想像できないのだが、具体的なケースを教えてくれないか？ >>877
coreclr見てみ。ネイティブからマネージドコードに置き換えてパフォーマンスとメンテナンス性向上させてるPRいっぱいあるから。 バカの自作C++コードよりC#libraryの方が当然早いだろう。
libraryの中身はC++だったりするが
C++の演算libraryも中身はアセンブラだから同じこと。 それはC++が遅いんじゃなくて呼び出しのオーバーヘッドが大きかったりOSやネイティブライブラリの機能が不必要に豪華で遅かったりするのを回避してるだけ C++/CLIでWPFをやる私は異端ですか？(*´･ω･) 昔試してみたような記憶があるが、C++/CLIでWPFってできたっけ？ もう10年以上C#使って、自前ツールはほぼC#オンリーだけど、C#が速いと思ったことないよ。
ストールしまくる配列の遅さとか致命的だからライブラリとか作るには向かないが、
むしろ使い捨て、やっつけツールを作るにはちょうどよい。ポジション的は昔のPerlの立ち位置だな。
そういう立ち位置と理解すればWPFが普及しない理由も分かる。 >>886
>ストールしまくる配列の遅さ
詳しくお願いします。
>そういう立ち位置と理解すればWPFが普及しない理由も分かる。
C#のポジションが昔のPerlの立ち位置であることが、WPFが普及しないこと
にどのように結びつくのか解説をお聞かせくだされば幸いです。 今はマシンパワーでゴリ押し出来るからねぇ
苦労してC++で組むメリットは少ない >>888
実は、C++を苦労と思わない人なら、C#で組む必要性も低いのです。つまり、
「C++が出来るなら、C#を使う必要はない」
のです。 >>887
> >ストールしまくる配列の遅さ
> 詳しくお願いします。
マジかw こんなとんでもない低スキルの馬鹿がWPFスレにいるのか。
こんな基本的なことはパソコン少年でも知ってると思うが、条件分岐はストールする。
君のようなパソコンはじめて素人君はあと5年くらいROMってろなw それもMSの経営戦略なのですが、Visual Studio は、C++ と C# で分かれて無い
ので、使われ方の比率は誰にも分からない状態になっていますね。
果たしてどっちがすかれているのかも、本当ははっきりしません。
「層」によって好みが明確に分かれている可能性も有り得ます。
また、新しいものは、時代に乗り遅れまいと試しに使う人も多いので、
その影響もあります。 「新し物好き層」なるものがあり、その人達は新しいものが素晴らしいと思います。
ネットにはそのタイプの人による新しいものを褒める記事が多く見受けられます。
逆に新しいもの、古いものに限らず、ネットでは物事の欠点や負の側面
を書く人は少数派です。何故かは分かりませんが、炎上を恐れる人が多い
からかも知れません。 C#で10年ツール作り続けていることを誇る が紛れ込んでしまった C#界隈はWebやスマホへ移行できずに時代に取り残された人達が老害化してる印象だなあ
趣味でフリーウェアやシェアウェアを作って公開してた人も一昔前には沢山いたけど、みんな今どうしてるんだろうね
俺もその一人だけど、もうクラウド開発しかやってないわ 一応てかスマホゲーは大体UnityでC#じゃね
なんならC#の最大手まである スマホゲーでは最大手ではあるだろうけどcocosも未だに強いしunrealも頑張ってる、どっちもC++
サーバー側までC#はあんま居ないはず asp.net coreって人気ないのかな？
スマホもxamarinがあるし クライアントがUnityだからサーバーにもC#を使ってるゲームはわりとあるらしい
ドカタITではASP.NET Coreは全く使われてないね 分野ちがうがxamarinとasp.net coreどっちがまだ使われてるかっていったらasp.netの方？ 最強の一人neueccとかゲームプログラマー頑張ってるし 彼はすごい人だから良いけど
大体はまだPHPかよくてruby
webソシャゲの頃の鯖エンジニア結構残ってるからね 時代とかトレンドとか言っても、スタンドアロンで十分なものをわざわざWebにしたりしないしなぁ。 いまトレンド来てるだろ
752 デフォルトの名無しさん 2019/11/04(月) 01:41:28.60 ID:uqYdx4m2
どうも、Microsoftのこれからの方向性
この1年で大きく変化しているのを理解できていない投稿が
多いように見受けられんだけど。
来週のIgniteを楽しみにしよう。 UWPのゴリ押しがうまくいかなかったからWPFもそれなりにサポートするみたいなのは見た気がする デスクトップアプリとスマホアプリに互換持たせても根本的に違うし、泥に展開出来ない時点で何の意味もない そうか？モダンアプリ使いやすいだろ
UWPがどうというより、デスクトップアプリ自体がWebのフロントエンドの一つに成り下がってしまい、
簡易なUIで十分になっちゃったんだよなあ 相談させてください。C# で
static class MyBindingHelper
{
public static bool GetModeIsTwoWay(Binding binding)
=> binding.Mode == BindingMode.TwoWay;
public static void SetModeIsTwoWay(Binding binding, bool value)
=> binding.Mode = value ? BindingMode.TwoWay : BindingMode.Default;
}
のようなクラスを作成すると XAML で
①
<TextBox>
<TextBox.Text>
<Binding Path="Hoge" local:MyBindingHelper.ModeIsTwoWay="True" />
</TextBox.Text>
</TextBox>
のような書き方ができるようになりますが、
②
<TextBox Text="{Binding Hoge, local:MyBindingHelper.ModeIsTwoWay=True}"/>
と書いても期待に反して
Markup Extension の解析時に、型 'System.Windows.Data.Binding' に対する不明なプロパティ 'BindingHelper.ModeIsTwoWay' が見つかりました。
というエラーになってしまいました。
①のような書き方は冗長に感じるのでできれば②に近い書き方をしたいのですが、
何か良い方法をご存じの方がいらっしゃればお知恵を拝借できないでしょうか。
どうぞよろしくお願いいたします。 Blazorのデスクトップアプリ流用がすごすぎて既存のデスクトップフレームワークの存在意義が完全に消滅しちゃった
何も考えなくても自動的にクロスプラットフォームになるし既存のWeb系エコシステムも使い放題だ
FormsやWPFはメンテナンスすることはあっても新規で作ることはもう無いだろう さすがにWPFはもう絶滅したと言ってもいいが、現代においても未だにWinFormsが採用されることがあるのは
どっちかというと開発者のスキルの問題だからなあ
Blazorを採用できるだけのまともなWebのスキルがあるチームならとっくの昔にWeb MVC系へ行ってる スキルの問題じゃなく慣れてるからというだけ。未だにvi使い続けてる人がいるのと同じ。
同じことするのに言語やフレームワーク、ライブラリをコロコロ変える馬鹿はいないよ。
そんなに脳みそにキャパが余ってるなら医者に職業変えたほうがいいw Blazorでデスクトップアプリって、今だとどれくらいのことができるようになってる？
WPFやMFCを置き換えられるくらいになってたら検討したいが。 webアプリは重いからユーザー視点から使いたくねぇな。wasmはどれくらい速いのかしらんが ちょっと調べてみたがUIはやっぱりまだRazorのままじゃね？デスクトップを置き換えるには程遠い。 何を今更
この期に及んでHTML書く気がないんだったら引退するかバックエンド専門に転向したほうがいいよ >>921
androidタブレットで動かしてみたが、快適に動くけど、3DCGじゃなくてもっとtwitterアプリとかそういうので動かしてみたいな。 htmlなんて書く気ないしバックエンドにも移らないな
もちろん引退なんてしない HTMLでWPFやMFC並のGUIが書けるようになってたら喜んで使うよ。
WebのフロントエンドならReactを使ってるが、あれでデスクトップアプリを書く気はしない。 主題じゃないからただの茶々入れだけど
この手のデモでGPUに仕事ぶん投げる要素入れて
なんの意味があるのだろうかと毎度思う MSオフィスのフィードバックがMFCだったけど、最近のオフィスはWPFなん？ >>929
でも、大体どんなことが出来るかと、大体どれくらい速度が出るかの目安が
出来ますね。 HTMLガーっていうけどVSCodeレベルのもんが作れんならいいんじゃないの？ Office365はReactNativeになってるね
MSがReactNativeのWindows版再実装したりMac版開発したりでそっちに熱心なご様子 色々な種類のライブラリがあることは使う側にとって良いことばかりでは無いね。 >>935
良いことばっかだと思うんだけど
なんか悪いことある？ 物も作らず、カタログ屋して偉そうな
事言う奴が出てくる。
JAVA界隈は既に腐海に飲み込まれた MFCのFeaturePackみたいにVSのWPFコンポーネント群を公開してくれることを期待していたんだが
結局それはなかったな。OfficeのReactNativeはどうなんだろう。
一般プログラマは今までどおりMeterialUIでも使ってろ、とかだとあまり食指が動かない。 昔はWPF ToolkitというものをMSが公開していたんだよ
ゴミのようなな品質でゲロ遅く、WPFのアーリーアダプター達を幻滅させる結果になった 良く知らないけどカタログ配ってお歳暮とか受注して問屋に発注して届いたのをお届けする仕事の人なら身近にいる .netは糞遅いから実装しても使ってもらえないだろ。 WPFの数倍重いElectron製アプリが増えてきてるくらいだから使ってもらえるだろ WPFよりはWebkitの方が遥かに速くて軽くてレンダリング結果も美しいけどな Officeなんかはさすがに既存のコードから書き換える意義が薄いだろうしな
最近でMSがWPF使ってる事例だと新生PIX（グラフィックデバッガ）かな >>948
いやOfficeは2010で描画周りがDirect2Dで書き直されてるんだよ
VSのように描画だけWPFにもできたはずだが、WPFは採用されなかったということだ >>949
Cの直接モードのAPIをC#かつ保持モードのフレームワークに置き換えるのはまた労力がダンチだろうね
ところでなんでVSはWPFを採用してまだそれを維持してるのかしら？ WPFでVisual Studioを作ってみせてWPFの有用性を示したはずが
同時にWPFの動作の緩慢さも示すことになってしまったという しかしWebkit遅いわー
まあ、マシン性能向上とともに。。。かな
でもそうするとWPFでいいか・・・ >>946
C++実装したNative呼ばずにC#+WPF使ってブラウザ書いてみればいいじゃない。
Java製ブラウザは遅くて誰も使ってくれなかったけど、なぜC#だと誰も書かないの？
本当は速いと本気で信じてる信者が誰もいないということだね。MSですら書かないのだから。 >>953
ちょっとC#でブラウザ書いてどんくらい重いのか見せて～ Win32APIとかDirectXを叩けるC#と使えないJavaを比較するのはアンフェアじゃないのか。 C#から Win32API や DirectX って、PythonからAIや数値計算用のCの
ライブラリを呼び出してPythonは遅くないと主張しているのと似てる
気がするのは俺だけか。
C#は、unmanagedコードでC/C++や、unsafeでC/C++のポインタも使える
けど、それまで含んでしまった場合、果たしてC#と呼べるかどうか。
それはC#の皮をかぶったC++じゃ。 DllImportやCOM interopでC/C++を呼ぶのはともかく、unsafeは普通にマネージコードの範疇 ポインタ使うことがCって意味がわからん
Cと同じような処理や記述ができるだけであってCを使ってるわけじゃないじゃん 別にjavaだろうがjniで呼び出しゃいいんじゃない そう、最後は成果物で速度競えばいいんだからやり方はどうでもいい
ただ、そのやり方をするのにどれだけ労力かかるかは考慮しないといけない
なのでCore部分をC/C++で書いて呼び出すとか言ってる奴はアホ Core部分はエロい人が作ってくれるからそれを使うだろう。 >>964
だとすれば、C#を使っていれば、そのエロい人にはなれないって事になってしまう。 WebブラウザのCoreであるエンジンを労力をかけてC++で作るのがアホだと？ >>965
それはその通り
なりたきゃC++かRustでもやりなさい
C#の人はC#に閉じ籠ろうとする傾向があるが、プロなら言語なんか必要に応じて何でも使えて当たり前だぞ >>967
そういった傾向を扱ったデータってある？ なんやC#erはすぐネイティブに逃げられてズルイ的な流れじゃないんかい
もうなんの話してんのかわからんな .NET Coreもあるとはいえ、殆どのC#erにはそもそもWindows縛りがあるから選択肢が少ないのは当たり前 むしろWindowsのコアなとこが.NETになってないから
逆にC#で完結出来ずにネイティブに下らざるを得んことの方が多いわ だからこっちでやれ
C#とC++を無理矢理戦わせたい人専用スレ
https://mevius.5ch.net/test/read.cgi/tech/1574852588/
無理矢理ここで続けるやつはWPFに嫉妬してる荒らしな >>972
だからWPFの質問しても誰も答えてくれないじゃん。
MSオフィスやIE、EdgeはWPF使ってるの？なんで使わないの？ MSはWPFをちゃんとやり遂げろよ
思想は魅力的だったのに途中で投げ出して
MS製フレームワークは信用できん staticおじさんみたいなのが住み着いちゃってるじゃん >>973
お前のガイジ行動に付き合って回答するとなんか特典あんの？ >>977
おまえみたいな煽りしかできない無知な低スキルのバカには質問してません。
スルーしてください。二度とレスしないでね、リアルガイジクンw >MSオフィスやIE、EdgeはWPF使ってるの？なんで使わないの？
これが高スキルの質問！ 別に何が何を使っていようが
自分が作りたいものが作れるフレームワークを
選べば良い話だと思うけどな MSの主要開発グループがC#+WPFを選ばなかった理由を教えてくれてありがとう。 C#が速くないって使えばすぐ分かることなのにな。
C#信者なのにDelphi使ったことなかったんかな。 GuptaのTeam Developerって今WPFと連携するのか
Delphiはいいものだったけどヘジたんが抜けてから迷走してしまったな >>986
なんでそんな初心者みたいな質問するん？
アセンブリ言語、C言語、Object Pascal(Delphi)あたりで書けばC++より速いですよ。 >>986
意外とVB６
Live2ｃｈとか触ってみると実感できる 或いは肥前山口ー肥前鹿島ー大村ー長崎のスーパー直線ルートでもいいな。 >>990
それVBっていうかWinFormsなら軽いって話でしょ とうとうVB6が何かすら知らない世代が現れたか。それともただの初心者か。 Win32のコモン・コントロールだけ使ってアニメーションとかしないのが起動も動作も一番速いよナー VB6まで入れるならDelphのほうがネイティブコードだから速いだろ VBとVB.NETの区別がつかない初心者様と
全部C++でGUI書きたい上級者様が同居してんのかここ 初心者と上級者というより
若者と老人だろ
若い子は大昔のくだらない経緯なんて気にせず最新技術を追っていけ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 207日 6時間 47分 1秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
