WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22
レス数が1000を超えています。これ以上書き込みはできません。
MediaElementのメディアの時間て
NaturalDurationに入ってくると思うのですが
ミリ秒まで入りません。
末尾までスキップとか中途半端なのですが
何かいい方法はありますか? MSは同じような枠組みを違った環境向けに少しずつ異なる実装を
バカバカ作りやがる MVVM方式で、ボタンを10個作ったら、それぞれに対応するCommandクラスを10個作らないと動かないの? senderとかで分岐しちゃダメなの?
CommandParameterとかにユニーク値いれるとか CommandParameterを利用して検討してみます。
ありがとうございます。 つか、ICommandじゃなくてPrismやReactiveProperty使うのが一般的だよな
使えない現場もあるかも知れんが DelegateCommandとReactiveCommandってどっちが使いやすい?
そんなに変わらん? >>600
new BusyNotifier().Select(x => !x).ToReactiveCommand().AddTo(Disposable);って生成すれば、何も考えずに二度押し防止出来るのがメリットで
IDisposableの実装が必要なのがデメリット
ReactiveProperty使っているならそっちで実装するから手間は変わらなくなるが >>601
なるほど二度押し防止はよく使いそう
ReactiveProperty使い始めたんだが
ReactiveCollectionのItem数によってReactiveCommandを許可するかってのをどう書いていいかわからん ReactiveCollectionのitem数によってtrue/falseに変化するReactivePropertyを作って
そこからToReactiveCommand()でReactiveCommandを作ってやればいいはず。
ReactiveCollectionの変化を直接捕まえられたかは忘れた。
ダメだったらそのReactiveCollectionに変化を引き起こし得る操作のところで
ReactivePropertyをメンテしてやる。 https://qiita.com/YSRKEN/items/5a36fb8071104a989fb8
ここ読むとReactiveProperty使っても
INotifyPropertyChangedも合わせて使わないとメモリーリーク防げないと読めて
ReactivePropertyを使うことに対するメリットがイマイチ理解できないのだけど、
やっぱり便利なの? >>603
そうそうこの直接捕まえることができるのか調べてもわからなかった
確かにitemsを操作するところでもいいんだけどね 手元のコード探してみたらそのまんまCollectionChangedAsObservable()でよかったみたい。 >>604
や、そうじゃなくてINotifyPropertyChangedインターフェースの実装がアレばいいってことだから
prismなら従来VMを書くときと同じようにBindableBaseを継承すればいいということのようだ
それを省略ならIDisposableを実装してしっかりDisposeすりゃいいってことだ >>606
ありがとう拡張メソッドでitemsの変更が拾えました
CountをReactivePropertyにしてCommandのtrue/falseも変更できました パート22だけど去年はとうとう1スレも進まなかったのね デスクトップしか使わんから勉強するモチベ的につらい
たまにこのスレ覗くくらいだわ 二年くらい前に既にピークアウトしたよ
天保山くらいのピークだったけど UserControlでマウスのクリックを
<UserControl.InputBindings>
<MouseBinding Gestus="LeftClick"・・・>
のようにして取得できるんだけど
<Grid VerticalAlignment="Bottom">
このGridはクリックを通したくない場合ってどうするのが正解なんでしょうか? >>616
正解かどうかは知らないけどPreview系のイベントでハンドリングして以降では処理しないようにするとかはどう? >>617
なるほどそういう方法があったか
PreviewだとGridに置いたButtonとかが拾えなくなるので
MouseLeftButtonDownでマスクしたところ
うまくいきました
さんきゅー >>618
あ、そうか。この場合は下に伝えたくないからPreviewじゃないほうか…。
うまくいって良かったよ。 2008年以降に始めたプログラマもWPF使わずwinform使ってんだろうな。 >>620
三年前にC#はじめたけどWPF使ってるよ
もともとHTMLさわってたからUIがXMLで書けるのが好み >>623
それって結局、JavaScriptでプログラミングになるんじゃ? Desktop Bridgeってのを試しているんだが、sqlite.interop.dllってのが実行フォルダにコピーされないんだが
対策ありますか?手動でコピーすれば大丈夫のようだが(パッケージ化はこれから) Windowsアプリケーションパッケージングプロジェクトだつけ?それ使うといいよ >>628
残念ながら、そいつ使っているんだが上手く行っていません
sqliteのパッケージはsqlite.interop.dllがx86とx64の切り替えをやっていて
.netのbinフォルダでx64,x86のサブフォルダ上にインストールされるんだが、
そのフォルダが「Windowsアプリケーションパッケージングプロジェクト」のbinにコピーされません >>629
苦肉の策としてはWindowsアプリケーションパッケージプロジェクトのコンテンツとしてsqliteまわりのdllを入れておくとかかな
プロジェクト内でのフォルダ構造そのままコピーされるからWPFプロジェクト名のフォルダを切って、その下にsqliteのdllを配置してほしいレイアウトで置く感じ
ストアに出すならもう少し頑張らないといけないけどサイドローディングならそれだけで行けると思う WPFかあ、もはやそんなのあったなあ、って感じだな。
たぶんもう日本の業務アプリは、もはや21世紀中はWindows Formsが主流のままだよ。
事務ソフトでアニメーションなんかあっても、ウザいだけ。 >>631
べつにアニメーションがWPFの特徴なわけじゃないと思うが >>632
メトロUIという非常にユーザから嫌われたUIを使えるのが特徴だな。 >>632
でもWimdowsフォームとWPFの違いって、ユーザーから見たらアニメーションぐらいじゃね?
>>633
ASP.NETも枯れてていい感じだね! でも俺は、ブラウザ アプリは遅いので好きじゃないんだ。
マルチ プラットフォーム環境の、不特定多数へのサービスならブラウザ最高! だけどね。 >>634
WPFとMetroは無関係だが
なんでそんな程度の知識しかしない煽り虫がこのスレに棲息してんだ? >>636
横からだけど、Windows 8が出たときに、メトロUIのWindows Store アプリを作ることが
WPFの目的だった時代があったような。。。それでみんな、ちょっとかじってやめていった。
もう6年前の話なので、あのわずかな期間を、どれほどの人が覚えているか知らないが。 4Kモニターユーザーとしては、WPFアプリは標準で高DPIに対応してるのが良い。
何もしなくてもSystem DPI Awareで、Per monitor DPI Awareにするのも簡単。 >>635
ユーザーから見たら同じとか言い出したら中身がC++でWINAPIベタ書きでもPythonかなんかでTcl/Tkで書いても全部一緒ってことになるだろうが
作り手にとって違うなら十分違うんだよ >>637
> 時代があったような
ないです
そんなわけのわからん記憶をどこでねつ造してきたの… WPF登場から13年。
Windows95発売からWindows7が発売されるまでが14年。
こんだけ経って普及してないんならもう普及は無理だわ。 メトロUIこそWPFの真骨頂なのに何言ってんだか。WPF開発者がそう言ってるだろ。 普及するとか普及しないとかいうより、新しいWindowsアプリなんてほとんど登場してないだけだろ。WPFとかWinFormsとかあんま関係ない。
マウス入力のUIの既存ので間に合ってて誰も新しく作らない。 マウス入力に最適化されたUIのアプリは既存のデスクトップアプリで間に合っててほとんど誰も新しく作らない。
だからWinFormsとかWPFとかそれ以前の問題。社内アプリとかでぼそぼそ作ってるところとかもあるかもしれんが。 タブレットと同じソースが使える筈だったザマリンを
自分達で潰したから普及する訳無いでしょうな >>630
WAPのバイナリに手動コピーするとしっかり配置してくれているようだから
当座はそれで凌げそうです
sqliteかVSかどちらかのバグだろうから、そのうち解消されるまで待つことにします
しかしWAPでX64選択しても店子のWPFプロジェクトはAnyCPUが選択されるため
WAPのバイナリは32bitのwpfバイナリイメージになっていたのはびっくりしたわ
(構成マネージャーで手動修正可能だが) >>644
MetroStyleしようと思ったらOSS入れないと駄目なくらいWPFでは組み込みサポートないよ
Windows8ではWindows Runtime上で動くWindows Store Appが追加されてたけど、それと勘違いしてる? そうではなくてWPFとXAMLを勘違いしてるんではないですか??? あの不人気なフラットデザインをメトロって言うんだよ。
VSで言えば、VS2010から採用された悪評高いのっぺりデザイン。 windows95から24年も代わり映えのしないデザインより遥かにマシじゃね? >>653
> メトロって言うんだよ
> VS2010から採用された
言いません >>654
進化してればいいんだが、見た目が変わっただけというのは害悪しかない 僕のアダナを 知ってるかい メトロUIと いうんだぜ
デマを流して もう三月 雨や嵐にゃ 慣れたけど〜 WPFがメトロUIだと言いだす馬鹿はほっとけばいい >>664 ←十分条件と必要条件が理解できない典型的馬鹿文系の例 >>661
ここにこう書いてあるとソース貼れば良いのでは? >>666 ←ところで誰でも知ってることを必死にID代えながら全否定してる馬鹿は何者? >>667
ソースを貼れば黙らせられるんじゃない?
俺もグラデとボーダー抑えただけのフラットデザインをメトロと呼んでいたなんて初耳だけど ID:sLZ546NU\
ノ)人(\ フ
人(へニフ )人 )
へ ( 〈●) ヘ)ノイ
Y Y /// ̄ (●/ノ
ヽノ _ノ~|
_ノ / ̄\ / <ボクが一番WPFに詳しいんだ!!!
――、_\二ノ /
/ / イ/ ̄/ >>669
イヤそちらの方が詳しいから主張しているのでは もしかしてwikipediaのこれをみてWPF=メトロって解釈したの?
ttps://ja.m.wikipedia.org/wiki/Windows_Presentation_Foundation
>Windowsストアアプリ
>Windows 8/Windows RTにおいて導入されたWindowsストアアプリ(WinRTアプリ、Modern UIアプリケーション)はWPF同様XAMLによって
>ユーザインタフェース要素を記述し、WPFに類似したプログラミングモデルを提供する。Windows 10においてWindowsストアアプリの後継として導入された、ユニバーサルWindowsプラットフォーム??(Universal Windows Platform, UWP) アプリケーションも基本は同様である。 Windows8の開発には普通vs2012がいるからねぇ
その時点で駄法螺でしょうな VS2010って急に重くなってヘルプが使い物にならなくなったバージョンだな。
そしてドキュメントも整備されなくなった。そして記念すべき.net4というアホバージョンが登場。
以後の.netの仕様は互換性は皆無、仕様は右往左往、排他仕様、切捨ての嵐となった。
サポートには苦情の嵐でどうにもならず、多くをオープンソース化してユーザに丸投げ。
この辺りだな、MSの技術力が急低下したのは。 ホラVS2010がメトロとかわけわからんこと言うから
おじいちゃんが発作起こしちゃったでしょう >>678
そんなに騒ぎになった記憶がないから該当レス書いた人の個人的なお気持ちだと思う >>652
同一視してる可能性は否めない。
WPFもWin8アプリもWin10アプリもXAML使ってるが、ライブラリもランタイムも違う別物。 結局WPF is Metroさんは勘違い以前のただの釣りだったのけ?
煽りにしても意味わからんしもともとMetroの定義も曖昧だから
なんか説明してくれると思ったのになあ RenderTargetBitmapをpngやbmpファイルに落とすと
1920*1080とかになると一秒くらい掛かってしまうんですが
もっと速くする方法はないでしょうか? >>683
WPFではなくSystem.Drawingを使う >>684
ありがとうございます。
調べてみます。 VS2010のデザインをメトロだと言い張る無知なバカはもう消えたのか? そういやパスの長さ260文字の呪いは解消されては居るが、
都合で隠し機能になってレジストリ弄らないよ有効にならないんだよな MSの中ですらもう粗大ゴミ、時代遅れのガラクタWPFはどうするんだろ? WPFスレがまだあったか。こんなもの普及しないと思ってたけどまさかPart22まで伸びてるなんて。
随分と普及してたんだなw 普及はしていない。
ただWPFに手を出してしまった馬鹿の移行先をMSが出してくれないだけ。
もはや蟻地獄。抜け出せない。 「民主主義は最悪の政治体制だ。民主主義以外のあらゆる政治体制を除けばだが。」ってやつか。 >>697
騙された連中は置き去りにしてMS自身はElectronへ完全移行したね どうしてなの――ッ!!
どうしてエレクトロンしないのよーッ!! >>698
例えばMSのoffice2019は何で書かれてるのかな? MFCをはじめGUIライブラリは昔はOfficeチームが牽引してたけど、リボンUIで失敗してからはグダグダ
失敗の始まりはUIデザイナーなるものがプログラマに横槍を入れるようになったから。 クールバー(Ie4)ぐらいからおかしかったけどなぁ VS2017インストールしたけど、とうとうWCF Data Serviceのテンプレも無くなったか。
RIA Serviceも無くなってクラウドDBのアクセスがどんどん退化していくな。
WPFからのクラウドDBへのアクセスは実質WebAPIしかないんだろうか?
クロスプラットフォームを意識しすぎて、開発コストが上がる方向に何故
行くんだろうな。。。Azureとか流行るの? VS2017インストールしたけど、とうとうWCF Data Serviceのテンプレも無くなったか。
RIA Serviceも無くなってクラウドDBのアクセスがどんどん退化していくな。
WPFからのクラウドDBへのアクセスは実質WebAPIしかないんだろうか?
クロスプラットフォームを意識しすぎて、開発コストが上がる方向に何故
行くんだろうな。。。Azureとか流行るの? VS2017インストールしたけど、とうとうWCF Data Serviceのテンプレも無くなったか。
RIA Serviceも無くなってクラウドDBのアクセスがどんどん退化していくな。
WPFからのクラウドDBへのアクセスは実質WebAPIしかないんだろうか?
クロスプラットフォームを意識しすぎて、開発コストが上がる方向に何故
行くんだろうな。。。Azureとか流行るの? 君もそろそろアップデートしてはどうか
チャタってますよ >>706
システムソフトの開発会社であれば、OSなどの違いにより別作りを
避けられるので大きく負荷低減になる。
ユーザー企業であれば、システムの変更が必要になった際に作り直しを
する負荷が減る。この場合同じ環境を使い続けられるとすると余計な
作業と思われるが、企業合併なので約束できないのが実際なので。
一般の開発会社やSI'erは、言われるがままに作るだけ。 WPFとUWP、xaml部分は共通な部分が多いと考えていいのかな。
PCをWin10に移行するんだが、社内で多用しているるツールが
独自のGUIを持っていてWin10でも動くのだが、作り変えたいという
希望がある。その際にクライアント(PC)上のGUIはWPFでどうかな
と思っているんだよね。これに関係ないアプリはUWPだったりとかに
なるだろうけど。
どう思います? xamlだけ見ると、UWPはイベントをバインディング出来るのが特徴でWPFだとビヘイビアを実装しないとアクセスできない処理をVMで処理できる
あと、Prism.Unityの仕様がだいぶ違っていてUWPのほうが簡潔に書けるし強力だ
問題になるのは現状UWPでDB弄るときはRestAPI実装しないといけない(SqLite以外)ところかもな
Core3でEF6サポートだからどうなるか分からんが ありがとう、
使用するツールがデータIOや管理はするので、WPFでもUWPの場合でも
DBは一切直接弄らない。イベントバインドってどんなモノだろう。
普段WPFは使っているがUWPは使用していないもので。
ちなみにクライアントの画面コントロールは、PowerShell+WPFで考えて
いる。私自体は普段それで使っているので。
将来的に他のアプリでは、UWPの利用があり得るので技術習得として
FormよりWPFで感覚をつかんでもらうのもいいかなという発想がある
んだけど。
どんなもんでしょう。 >>714
イベントハンドラをViewのコードビハインドに書く要領でVM上に書いたイベントハンドラにバインドする
書き方はViewに書くものをPublicにしたものでOK
書き忘れたけど、x:Bindという新しい書き方のバインドはコンパイル前に解決するので
バインド異常をコンパイラーが検知してエラーを出してくれる
それとListBox系のテンプレートの癖が若干違っていて、これは簡単に説明できないけど
そのまんま移植って訳にはいかない データバインドはいつも使うが、イベントのバインド分んないな
調べてみて共通な部分を使うような感じで考えてみようかと思う。
今まで利用していたものの差し替えなので、今回は高度なインターフェースは
期待していないので、いけそうな気がしているので。 >>714
.NET Standard 2.0対応したバージョン以降はSqlConnectionあるからSQL Serverつなぎに行けるよ。
その場合は配布方法はサイドローディングになるけど。一般公開ストア審査は多分通らない。テスト用DBサーバーをインターネットに晒して審査員にアクセス出来るようにしていたら可能性はあるけど…。
Microsoft Store for Businessの業務アプリとして出すのは平気 >>717
ありがとう。
>SqlConnectionあるからSQL Serverつなぎに行けるよ
残念ながらそれは使わないので >>720
知ってる風だがsilver lightやRIA service使ったことないだろ?
実情は復旧しなかっただけで、もともとクロスプラットフォーム目指してたし。
世の中がhtml5に流れたから使われなかった。
だが、一部の開発者は開発コストの大幅な削減でマニアが多かった。
なぜ、サーバ側の処理書いて、cl側はjson.netでわざわざ解析して展開しなきゃならんのかと、いままで自動でバインドするだけだったのに。
っていうただの愚痴です。 >>719
MySQLのNuGetパッケージも動くかはわからないけど.NET Standardだよ .NET CoreのWPFでcorertビルドできるか試してみたら? 幸いなことに普及しなかったから切捨ては簡単なのにMSは何でいつまでも引っ張ってるんだろうか。 >>727 ←MSの内部はこんな感じなんだと思う。みんなで失敗を認めなければいいみたいな 普及しなかったってのはFormsからの移行が進んでいないって意味かな?
それが事実かはともかくとして、仮にそうだとしてもMS的には別に困らんような。 VisualStudioもWPFみたいだし、なくなったらMS自身も困るからだろ WPFで作ってるアプリあるから捨てられたら困るんだが なんだもうそんなに負の遺産があるのかw ますますドツボだな、MSw ドンマイw UWPでない新しめのデスクトップツールだとまたMS自身もちょくちょくWPFを使うようになってんね
MS自身はホントどうしたいのって感じだがまあ部署間で足並み揃えようとしねえのは昔からか WPFが普及しないというより、新しくWindowsアプリを作る需要がないだけ。
昔はパソコンしかなかったからどんなアプリでもWinアプリにせざるを得なかったけど大多数である参照系のアプリはandroid、iosに取られちゃったからな。
残ったマウス、キーボード使う生産系のアプリは元からそんな種類ねぇし成熟してたから新しくWPFで開発する需要がほとんどないだけじゃねぇかな そもそもWPFが普及するとかしないとかの以前の問題で、新しくWindowsデスクトップアプリを作る需要がそもそもない その数少ないデスクトップアプリもUWPに傾倒してたから尚更やね
開発方面だとまだ需要はあるんだろうけど
最近のMS製だとWinDbg Preview、MSIX Package Tool、新生PIXかな、WPF使ってるの
大人気のVSCodeはElectronだがw 「WPFはオワコン」
「じゃあ今なら何なの」
「いや、デスクトップアプリ自体がオワコン」
このパターン飽きた。 HTML5アプリは書くの面倒だからデスクトップアプリできるだけ長生きしてほしいけど
あと20年もしたら絶滅してそうでつらい HTMLベースの方が楽に開発できる環境にでもならなけりゃそうそう絶滅なんてしないと思うが、
そうなったらなったでそのときに乗り換えればいいような。 >>738
オワコン言いたいだけでまともに議論する気無いからな。
デスクトップアプリの需要は下がったけど、無くなったわけでは無いのに。 デスクトップアプリがオワコンなのは、どうしてでしょうか?
私には資金回収が難しいなだけで、それさえ対策できれば、実行コストの低い、まだまだやっていけるものだと思うのですが? オワコンというか、今後の発展が見込めない、が正確な表現では >>743
デスクトップアプリのどのような特質が「発展の見込めない」という評価につながるのでしょうか? てか、オワコンとか発展が望めないと思ってるのになんでこんなスレ見てるんだろう… >>744
MSがUWPに傾倒していたせいでWinFormもWPFも最近数年間はほぼ放置状態だったからかな。
最近、若干方針が変わる兆しがあるけど。
変わるWindowsのアプリ戦略 UWPからデスクトップアプリに原点回帰か
http://ascii.jp/elem/000/001/770/1770229/ >>746
UWP のことをよくわかっていない私からすると、なぜ UWP に傾注してしまったのか?その理由は知りたいですね
古き良き WinForm/win32api も、その効率のよさから捨てたものではない、と思っているんですが 早くWindowsを移行させたいんだろ。
新しいプログラムはWin10でしか動作しませんて誘導したいんだよ。
プログラム組む側からすると、動作環境を広く取ろうとしてWin formsに戻ってしまう。 今新規にデスクトップアプリを作るなら、消去法でWPFで作るな
UWP→制限多すぎ
WinForms→見た目が少し古臭い、高DPI対応が面倒 >>744
主語が足りなかったな
今後の見込みがないのはデスクトップアプリではなくWPFの話 >>745
思ってるが、自分では(不便だと思いつつ代替もないから)使っているし
ごくまれに聞きたいこともある、だけだよ
なんでこう、デジタルな考え方しかしないのかな
脳のビット数が不足しているのではないか >>752
> なんでこう、デジタルな考え方しかしないのかな
> 脳のビット数が不足しているのではないか
それオワコンとか言ってる奴に言ってやれよw >>748
UIがそのままなら簡単に移行してくれたのにな >>753
オワコンなんて言ってねえだろが
ガイジは死ね 老害はいつまでもしがみつくだろうけど、もう設計が古いから仕方がない。 WPFは、最悪消えてしまってもいい。
ただ、DataBinding(MVVM)だけは消えないでくれ。
画面を直接触るのだけは、本当にもうゴメンだから。 とろくさいDataBindingがガンでしょ
パフォーマンスでないのをデフォにしたから子供のおもちゃ程度の代物になった >>748
Win Formsだと動作環境が広いってどういう意味?
それだとWPFでも一緒じゃん。 WinRTのx:bindのコンパイル時バインディングってどれぐらい速くなるの? >>764
binding単体では3桁ほど早くなるらしいが、元々そこまでボトルネックでもなかったから
体感するほどの改善ともならない
ただコンパイル時にエラーが出ることとイベントをバインディング出来るのが素晴らしい >>765
そっか>>762がbindingとろくさいって言うから、コンパイル時バインディングならどれくらい改善されるのかなぁと思って。
まぁ、確かにatomレベルのCPUでスクロールとかすると、それだけでCPU使用率50%ぐらいまでいって、おぉいって思ったりするけど。 糞遅いのが致命的だな。
速度を犠牲にしてまで設計の自由度なんて誰も求めてなかった。これがすべて。
しかも、自由にして生まれたのは一貫性のない糞UIばかりだし・・・ >>766
WPFはbindingがトロいんじゃなくて、その結果発生するレイアウト処理がトロい
WindowsRuntimeではそこが全部C++で書き直されて速くなった
まあ元々C#が遅かったというよりは設計が悪かったんだけどね アクセスの連帳フォームみたいなのをデータバインドでサクッと作るにはどうすればいいですか? WindowsFormsHostでDataGridViewをホストする
あとはWinFormsのバインディングと全く同じ
WPFのDataGridはパフォーマンスも品質も劣悪であり、全くお勧めできない あ、連帳フォームというのはサブフォームが繰り返し縦に並んで表示されるイメージです
ユーザーコントロールというのを作ってデータグリッドに入れればいいのかなぁ…
よくわからん >>771
それならItemsControlじゃね。 >>768
不自然にWindowsRuntime持ち上げるやついるけど何なの? 774「俺ほど生きていると昨日も十日前も変わらん」 4Kモニタにしたら画像でWindowを切り抜いてる自作アプリが150%拡大されてぼけてるから切ろうと調べて
manifestでdpiAwarenessとか弄ったけど拡大されたままだった・・・
exeのプロパティから切ってみてもダメだった
imageだと何かやらないといけないことあります? なんだ、言語仕様も読んでない馬鹿がいるのか。
こんなのどう実装仕様しようと速くはならない。 ゆとりにプログラミングは無理。
仕様を読まないから。 ガイジってなんだ? ゆとりは意味不明な造語が多くてコミュニケーションが取れないな。
少しは社会に出ろよ、無職のゆとり君。 インタープリターがオーバーヘッドの大きいオブジェクト指向ライブラリをドライブするんだから、
ネイティブコードでAPI叩くアプリに速度で敵うはずがない。
開発速度では逆なんだろうけどね。 何の話?受信機が反応しちゃったかな?
博士に調整してもらってね テンプレートの速度でC++が勝てるとは思えないが
本当に使った事あるのかな? WPFってC#プログラマのステップアップにいいかな?
案件数少ないし微妙か?
C,C++,C#とやってきて、今後のステップアップの方向性が見えない
WPFもUWPもxamarinもこけてるイメージしかない
一応WPFは基本はある程度習得したが、このまま勉強続けていいものか迷うわ
ずっとWindowsで食ってきて今更javaとかPHPとかに移行するのもアレだし、Windowsのプログラマはマジで今後どうしたらいいの? XAML技術自体は、何か1つくらい覚えておくに越した事は無いと思う
ヒマがあるならね C#は一時機は先端を走る言語だったけどもう古い言語でいまいち
どうしても記述量が多くなるので最近の新しい流れとは相いれない 自分は20年近くC#使ってて慣れてるからほぼC#でしか書かないけど他の人にC#は薦めない
新しい言語で書いたほうが楽だし先の見通しも良い >>794
コードが短くなるような仕組みがあったり、不必要な記号を記述しないように文法が決められている
C#は伝統があるのでそういう仕組みを全面的に取り入れられない
文末の;やforの( )などは新しい言語ではどんどん削られてきている
ガイジという言葉を使う人間は人間のクズなので相手にしなくていい >>797
何を言い出すかと思ったらセミコロンと()かよwww 人間のリソースは限られている
一度に表示できるコード量を多くしてタイピング量などを減らしていくべき
それを考慮してない言語は徐々に廃れていく ある言語で10行で書けるものが他の言語で20行必要なら
もう比較すらする必要がない >コードが短くなるような仕組みがあったり、不必要な記号を記述しないように文法が決められている
でもお前らラムダ式を使いまくると怒るじゃん? 見てると何か勉強するときのスタンスが短絡的というか。
確かに将来性あるUIツールキットの方がいいが、俺が勉強したときはもっとWPFというより言語などに依存しないMVVMの概念とか具体的な実装方法とかそっちを目的にWPF,UWP勉強したな。
おかげでandroidでもデータバインディング+MVVMを簡単に利用できたし あたらしいげんごってなんですかー?
ぐたいてきにおしえてくださーい(笑) >>803
それなら、その経験を悩んでるやつに伝えてあげて
その方がためになるはず > 人間のリソースは限られている
> 一度に表示できるコード量を多くしてタイピング量などを減らしていくべき
> それを考慮してない言語は徐々に廃れていく
典型的なコーダーの思考回路やんw 求められているのは見て理解しやすく、間違いが入りにくいものであり、コードが少ないものではない。
実際、今はテキストエディタでさえコード補完ができる。 >>807
だったらXAMLは最悪最低だよなwww April Update for WPF on .NET Core 3.0
https://github.com/dotnet/wpf/issues/607
相変わらずやる気があるのかねえのかわからんなあ 読んだけどただのCore移植作業の進捗報告だな
やる気もクソも、決まったことをやりきるために最低限必要なことをやっているだけ 後3週間待て。新しいロードマップ発表されるだろうし。 xamlって難しいからできる人少ないと思うんだよな
あとは需要がもっと増えてくれれば嬉しいのに
できる人が少ないから案件が出てこないんだよな 画像関係はスピード重視の設計でないと生き残れない
WPFは力を入れるところを間違ってる >>821
はは。お前は一生MS絡んだ製品使うなや マイクロソフトは俺を雇えよ
xamlもできる俺は天才だぞ マイクロソフトに転職した元同僚から誘われた事あったけど
「外から文句言ってた方が楽だから」って断った WPFに未来はあるのかないのか
WPFで覚えた知識はUWPやxamarinでどのくらい使えるのか
これだけ教えてくれ
xamlは共通だからある程度同じ感じで使えるのかな >>828
WPFに未来はない。というか現時点で既に死んでいる。
で知識をUWPに活かせるかだが、基本的にあまり期待すべきではない。
WPFは従来型のクラサバを指向したフレームワークであり、クライアント側で深く作り込むような開発スタイルが一般的だ。
当然、数少ない書籍やWebの資料もそれを前提にしており、WPFを学べば自然とそういう開発スタイルが身に付く。
一方でUWPは裏側にWebサービスが存在することが大前提のフレームワークであり、クライアントは非常に薄い窓口に過ぎない。
従ってWPFのような高度なバインディングなどは必要とされず、少ない労力でバックエンドといかにシームレスに繋ぐかが肝となってくる。 データバインディングやMVVMの仕組みは他に流用できる気がする WPFは職人的な作り込みが必要とされるから
山ほどいるVBあがりのwinform要員のコーダーには広まらなかったね
結局はブロガーとMSのエヴァンジェリストの飯の種で終わった >>828
WPFだけでなくUWPやxamarinにも未来はない ユーザー視点からみたWebアプリの使いにくさ最強レベル まぁ、作り次第でWebアプリをネイティブアプリに見た目似せて作れるけどでもやっぱwebアプリはウンコ多すぎ まあフロントをHTMLにするかはともかく今時完全にオフラインなアプリなんてゲームや電卓を除けばほとんどあり得ないから、
最初に学ぶならまずはWebがいいだろうね。
UWPは>>837のような子を満足させるためのベターなオプションに過ぎないから、最初に手を出すものではない。 速度重視にしたらプログラミングめんどくさくても普及する
みんな使うから
プログラミングしやすさアピールしても速度犠牲にしてたら生き残れない
結局他のものもつかわないといけなくなるから
バインディングが速いっていってるのはどーせしょぼい小規模なプログラムだけ WebアプリはHTMLはいいんだけどJavaScriptがクソすぎて困る じゃあC++とC#のwinforms使えるwindowsのデスクトップアプリ開発界隈では俺はWPFとかUWPなんかやらなくても当分安泰ってこと?
web側勉強した方がいいのかな
webになるとクライアント側はブラウザになるから言語も必然的にhtml/cssにJavaScriptとかになるから、c++とかc#のデスクトップアプリ開発で磨いた俺の力が役に立たないよな
だからASP.NETとかやっても微妙かなと思ってるんだが、c++やc#でクライアントサイド作ったらサーバサイドも必然的にc++やC#になんのかな
ソケットとか使うから
javaで作ったサーバアプリと連携とかできんのかな
何勉強したらいいんだホントに 勉強なんて楽しそうなやつやりゃいいじゃん
仕事で必要になったらググりゃいい そもそもデスクトップアプリ自体に将来性がないからね
時代はウェブ、クロスプラットフォーム。MSはもう何年もWPFに力を入れてない
俺も年内にはそっち方面に移る予定 >>833
もう開発されていない
もともとの開発チームはずいぶん昔に解散して今はメンテナンスモード >>844
WPFに限った話じゃなく、UWP以外WinFormsもMFCもメンテナンスモード
デスクトップアプリ全般にやる気が感じられない
WinFormsやWPFの移植作業中の.NET Coreはどこまで本気なんだろ さすがにUWPとWPFを同じ扱いするのは技術者として無知でしょ。 もう10年以上前から「デスクトップはオワコン、これからはWeb」とか言われているけど
いまだにWeb技術でスタンドアロン並みに使いやすいGUIを実現するのって聖杯探しだよな。
WPFもオープンソース化されたことだし、ここはひとつBlazorで動くようにしてくれないかな。 >Web技術でスタンドアロン並みに使いやすいGUIを実現する
Silverlightが死んでなけりゃな…… >>848
BlazorとWPFは全くべつもんやろ… そりゃ別物だろうけど。RazorあってのBlazorだからWPFとは排他だ、と言いたいのかな? >>848
企業内で使うシステムでデスクトップオンリーの見たことないわ
もう全部ブラウザ経由だよ >>852
全部ってすげえな
Chrome OSでも使ってんの? ツールとシステムを一緒にするバカは置いといて、うちも社内システムは全部ブラウザだな 勤怠チェック
給料計算
顧客管理
生産管理
最近100社以上のシステム見たけどほぼすべてブラウザ経由
どこの会社のどれをとっても最近はデスクトップアプリなんてどこにもない
今はwebの時代というのはあってる なんで勤怠管理とかでブラウザを経由する必要があるんだ?
全く意味がわからん
極端な話そんなもんエクセルVBAでも作れるし、そっちの方が安いよな
いちいちjava scriptに仕事させてブラウザで結果見るの?
それともサーバ構築までしてサーバ側のjavaとかに仕事させてるの?
わざわざそんなことする必要性がどこにあって、なぜそんなことをしてるんだ?意味がわからんな
流行りだからってことか?
まぁ流行りには乗りたいし俺もwebに移ろうかなぁ・・・
俺のC++、C#がほとんどの開発経験でweb側で高単価で雇ってくれるならすぐにでも移りたいわ 端末に依存せず、更新管理も楽であり、どこからでもアクセス可能
これがその環境において多くのメリットをもたらすなら、検討の価値がある
開発者としては何より経験値を積めることがおいしい >>855
勤怠システムに含まれる打刻ツールはデスクトップアプリやな いろんなシステムのバックエンドで動くバッチやワーカーもWebじゃないね >>859
未経験なわけないじゃん
デスクトップアプリに比べたら業務での経験がめちゃくちゃ経験が短いってだけ
でもwebも簡単だし普通にできる
そもそもWPFまでやる人間がなんでhtmlみたいなバカでもできるマークアップ言語とスタイルシートと簡単なスクリプト言語が理解できないのよ、そんなわけないわ
xamlの方が遥かに難しいマークアップ言語なわけだし、C#の方がJavaScriptより難しいだろ
いくらwebに移るといっても安単価じゃ受けませんよ、私のようなプロがね 100人やそこらの自社のみで使う勤怠管理なんて何でもいいよ
もっと利用者が多かったり複数企業で流用したりとか考えたらブラウザさえあれば済むwebアプリがどんだけ有用なことか
スマホ対応、mac/win対応もwebならコスト減らしやすい
インストール不要、ドキュメントもwebで対応できる、アップデートも利用者を気にしなくて実施しやすい
チャットワークやサイボウズがどんだけの企業で採用されてると思ってんの
開発者ツールでみてもBTSやCIもだいたいwebじゃないか >>863
>開発者ツール
Visual Studio 会社に入ったころは残業時間は表に手書きで自己申告してた
上司がチェックしてハンコ押して部長に回ってた
それをまた手計算してタイムカードと比べてチェックして給料に反映されてた
無駄だけどそれしかなかった
そのうちそれがexcelの表に記入して共有サーバに提出に変わって今はブラウザから申請になった
専用アプリを作ってメンテナンスしたり各PCに必ずエクセル入れたりという状況から抜け出せて良かったのではないかなあ >>865
ブラウザからの申請を記録するものは専用アプリとは違うんかい?
用途を無視してシステムを語るやつは脳内環境だから何言っても無駄か・・・ >>860
> 勤怠システムに含まれる打刻ツール
なにそれ? 自分の狭い観測範囲だけで能書きたれたがる低脳が多いんだよ さすがにクラサバはWebに置き換わったけど、ツール類はいくらでもあるなぁ。 >>866
デスクトップアプリの話をしてるんじゃないの? 今度仕事でWPF触らなくちゃいけなくなって初めてマークアップ言語に触れたんだけどとにかく読みにくい
for文だって入れ子減らせ読みにくいってのは当たり前に言われるというのに
どこからどこまでがどう入れ子になってるのが掴むの大変なんだけど慣れると読めるようになるもんなの?
あとそれと上の方でWPFに未来が無いとか書かれててがっかりしました
だよねー……日本語の参考書全然無くて海外のサイトばっか見てるもん…… >慣れると読めるようになるもんなの?
まあインデントさえしっかりしてれば >>872
どんな環境で開発してるのよ
ちょっとまともなエディタならXMLの中身を畳んだりタグの入れ子間違いを指摘することぐらいはできるぞ そうは言ってもXAMLは読みにくい。途中でコメントはさめないのとかほんとしんどい
VS2019使ってて拡張機能でXAML Stylerを入れてるけど、他にいいのあったら教えて下さい xaml stylerって拡張入れたらなんとかなる なんで最近スレ伸びてんのよ・・・
やっとWPFに普及期がきたか。 >>875
> そうは言ってもXAMLは読みにくい。途中でコメントはさめないのとかほんとしんどい
途中がどこなのかにもよるけどコメントは入れられるでしょ XMLをマークアップの標準にしたのはコンピュータ業界の最大の失敗 Blend for Visual Studioってまさにxaml編集用に作られてると思うんだけど…
あと、xamlというかxmlをそもそもよく分かってないんじゃないのっていうレスがちらほらある
あれダメならhtmlとかも理解できないでしょうに namespaceさえ理解すればあとはhtmlと大して変わらんよね。 >>879
例えば、
<Grid
<!--こことか-->
Property1="a" <!--ここに入れたい-->
Property2="b"
..... /> >>883
普通に
<!--
□□の設定
Property1 は〇〇
Property2 は△△
-->
<Grid
Property1="a"
Property2="b"
..... />
ってやれば良いだけだろ >>884
いや、それはそうなんだけど…
まずプロパティが多いと縦に伸びるし、目移りも無駄、
プロパティ名の入力も面倒だし、重要な情報を見落とす恐れもある
それに部分的にプロパティを抜いたり、別の値でテストしたい時とか、
プロパティをその位置でコメントアウト出来れば凄い楽
>>885
その辺は分からないけど、どうにかならんかったのかなといつも思うんだよね >>886
そんなに多くのプロパティを設定するのってどういうとき?
今までの経験だとせいぜい3〜4だと思うんだが・・・ 自分の思う通りに出来ないのは仕様がおかしい
って思っちゃうタイプなんでしょ
プログラマーにはあまり向いてないと思う >>888
例え3つでもコメント行が上に複数行も乗っかるのは嫌だわ
ただでさえxamlは縦に伸びるからね。フォーマットの仕方にもよるけど
プロパティの設定は大体4つ以内に収まるね
多いのだと例えばGridViewの設定かな。イベントの登録だけで4つ使ってたりする
>>889
コードビハインドでViewを構築しろってこと?ちょっとそれは頂けない
>>890
仕様がおかしいなどとは一言もいっとらんが
そもそもプログラマーで言語に不満を持ったことない人なんているんか >>891
なんで全てのプロパティにコメント残す必要があるの?
内容変更するのにコメントで残すってやつも、その項目全部をコピペしてコメント書いておけばいいじゃん。
つか、今時前のコードを残すのはバージョン管理に任せろよ。
条件に合わせて柔軟に対応できないとプロとしてやっていけないよ。 >>892
ちょっと待ってくれ。全てのプロパティにコメントを残したいとは言ってないぞ
例えばいくつかのプロパティについて、メモ書きや注意事項を残したいことってないの?
俺はただそのプロパティの上や横に書けたらいいのにな、と言ってるだけなんだが。
あとは行をその位置でコメントアウト出来れば、テストとか楽だし
一応プロとしてやってますよ
というか不満持ってる人って少ないのかな。長年不満を抱いてたから意外だったわ そもそもWinFormsだってプロパティーにコメント振らない 一応確認なんだけど、viewmodel使ってるのかな?
本来バインディングされるプロパティがあるのだからそっちにコメント入れれば良いと思うけど
viewにヅラヅラ説明を入れる状態が想像できない xmlの属性レベルのコメントができないのを仕様の欠陥扱いしてる人は結構いるよ
今回はマークアップ言語の話だけど、
既存のプログラミング言語に不満持ってるプログラマーが新しい言語を作るんだし
不満を持つことと対応できないこととは関係ないよね
んで、 Holy Hell!! な解法
https://stackoverflow.com/questions/2073140/why-cant-i-comment-attributes-in-xaml > xmlの属性レベルのコメントができないのを仕様の欠陥
ほんとこれ不便 未経験者から質問するけど、XAMLって独自プロパティ追加できないの?
HTMLなら勝手プロパティでコメント書いたりしたけど。 そもそもxaml(xml)を手で編集すんなってことにしたいんじゃない?
jsonなんかも大きくなると手編集向いてないし
とはいえ現状じゃそういうわけにはいかないけど
xaml自体を分割して見通しをよくするとかくらいかね >>893
そういう欲求はある。あると便利だよねえ 思う通りに出来ないなら出来るように作っちゃえばいいじゃない コメント振れないことと言うより
デバッグしているときにプロパティーをコメントアウトしにくいのが辛い
ブロック終わらせてコメントアウトっすりゃいいんだが面倒だ >>902
属性名変えればいいだけじゃん
Property1="a"
↓
xProperty1="a"
とか
応用力なさすぎ >>904
存在しないプロパティ名にリネームすれば無視されるから
コメントアウトの代わりに使える <a>
<a.b>
<c d="d">
</a.b>
</a>
でそれぞれa,b,c,dをコメントアウトするのに最適な方法は? >>907
今時コメントアウトなんぞ要らん
gitを信じて消せ >>907
お前日本語下手そうだからコメントアウトした結果を書け 正直この先何年もXML引きずるのかと思うと憂鬱だわ >>896
>xmlの属性レベルのコメントができないのを仕様の欠陥扱いしてる人は結構いるよ
XMLに関してはそうだが、XAMLに関してはプロパティ要素構文が使えるんだから
プロパティ要素構文にして、その後ろにコメント付ければいい デスクトップアプリマンってWPFできようがUWPできようが時代遅れなんかな
7年くらいずっとデスクトップアプリばっかやってきたわ
あとはせいぜいゲームとか
WEBは半年もやってない
ASP.NETマンになればブレイクスルーできるのか?
.NETに全てを託すしかねーわもう
WPFが死のうがUWPが死のうが.NETだけは共通の技術だから食ってけるよな? .NET Coreが迷走してるからわからんよ
今んとこASP.NET開発者の移行はさっぱり進んんでない
苦し紛れのWinForms&WPF対応という奇策もスルーされたら.NET Coreは3が最後のバージョンになるだろうな
そしたら.NETは終わりだ >>914
electronのデスクトップマンになれば延命できるぞ .NET Core 3の苦し紛れ感はSilverlight3の悲劇を彷彿とさせるね >>917
Silverlight3の顛末をググってきたらいいんじゃないかな
今の.NET Coreと状況がそっくりだから
だから失敗すると言いたいわけじゃないが、MS社内のプロジェクトのライフサイクル的に見切りを付ける時期が迫ってきているんだろう 「終わり」ってどういう状態を言っているのかにもよるな。
MFCは既に「終わり」のような気もするが、使えなくなったわけじゃないしな。 >>922
MSはプロダクトを見捨てる前にきっちり完成させるからね
WPFは例外だが WPFはファイルダイアログとかの仕組みをまともに作らなかったよね
みんなが欲しがるものをあえてスルーしてたのはなぜなんだろう? デスクトップアプリの肩身はどんどん狭くなる
今の元号変更にしたってアプリがweb化されていたらサーバサイドを変更するだけでいい
これからデスクトップだったもののweb化(html化)は加速するだろう >>924
ファイルダイアログはあるだろ
無いのはフォルダーダイアログ Windows API CodePackが事実上のオフィシャルリリースだろうに >>926
Webくんは妄想性人格障害なだけで現代っ子だよ フォルダ選択ダイアログってファイルダイアログに統合されただけだよな。
もともとあれは使いにくかったし。 >>930
人格障害だけでなくガイジも患ってるみたいだね…
ママさん仕事して〜
生ゴミはコンポストに捨てといてね NumericUpDownがないのは作り忘れなの? ちょいちょいそれ出してくる人いるけど、そんなに重要なコントロールか?
あればあったでいいけど、作れよそんくらい。 wpfに足りないのは洒落たtoolkitだと思うんだがな
JavaFXみたいでいいからcss使えたら大分変わっただろうが WPF Toolkitがあっただろ
MS謹製にもかかわらず悲惨な品質で、WPFにおけるコントロールの作りづらさを露呈した 取るに足らないコンポーネントなんだろうけど、そういうのが積み重なった結果が
オレのUIかっこいいだろ系の残念UIのアプリが蔓延してWPF忌避の一因になったような気がする
特にWPF出始めは
ゴテゴテしてる感じのボタン群とか、パネルごとにグラデーションがかかった背景とか
WPFならではのUIにしてみましたって感じの機能に振り回されてるデザインのアプリ多かった
既存のUIと違いすぎて「このツールはWPFアプリかー(使いづらいな)」って思ってた
アプリのコンポーネントごとに極僅かだけどバッドノウハウ的なコツが必要なの時間の無駄に感じる >>931
API的には統合されたけど、WPFのはモード指定が出来なくてファイル専用
APIを直接呼び出せば使えるけど、面倒くさい グラデなしでピクトグラムでいいやんの流行りになったしな MSのWPF開発担当がアスペルガー症候群か何かだったんじゃないの?
全然ユーザーの意見取り入れなかった MSのWPF開発担当がアスペルガー症候群か何かだったんじゃないの?
全然ユーザーの意見取り入れなかった >>941
MS製コントロールがバグ放置のwinformsよりはずっといい
(自前で拡張するかどっかから買えと?) 親コンテナにDropShadowEffectを適用すると子コントロールにも反映されます。親要素にのみ反映させるにはどうすればよいでしょうか webの方が簡単で面白いことに気づいてしまった
プログラミングってやっぱだるいわ
クソコードひたすら追いかけないといかんし >>945
俺ももうプログラミングやめたい
ソリューションアーキテクト()とか名乗って偉そうなこと言ってトンズラするだけの仕事したい 風呂敷広げる仕事ばかりやって畳む経験積まないとロクな人間にならないよ >>946
ソリューションアーキテクトってやたらかっこいいな
それで仕事取れてまかり通るなら迷わずやればいいよ
ぶっちゃけ俺もそれやりてーわ VS2019 previewでWPFの.NET Coreのデザイナーの対応が来たな .net coreベースでWPFアプリが作れるだけだろ
何が嬉しいのかさっぱりわからない .netcoreベースでWPFアプリが作れるけど動くのはwin7sp1以降のwindowsのみ 思考停止してるのか?
実際に何かいいことあるのか?
ないだろ? .Net Coreは .NET Framework よりも性能が良いって聞くけど、どうなんだろうね。
後、アプリに .NET Core自体を含められるから、 .NET Frameworkが
インストールされている必要が無いってのもメリットと言えばメリット。 .netcoreに移行するとすでにあるWPFライブラリなどは使いまわしできなくなる visual studioはWPFで作ってあるけど再実装しなおすのかな? >>962
Webサーバーのために極度に最適化されてるから、デスクトップアプリに求められる性能が出るかは期待薄だろう
今更真面目にデスクトップアプリ向けのパフォーマンス改善なんかやってくれるとも思えない
しかもデスクトップアプリなら.NETランタイムごとアプリに同梱して配るのがデフォになるだろうから、
.NET Frameworkと比較してファイルサイズサイズは激増し、その分起動時間も相当長くなるはず >>966
Webサーバーに極度に最適化の具体的な内容を知りたい
ソースお願いします https://devblogs.microsoft.com/dotnet/introducing-net-5/
だいぶのんびりやってるけどそのへんはAOT対応に期待だねえ
今までの.NETアプリの鈍重ぶりからしてシステムランタイム依存が
実際どれだけスタートアップ速度に貢献してたかなんてのも疑問だし 将来Coreは.NET5に移行することになるから、Frameworkでの開発がレガシー化するのは時間の問題でしかない
Visual Sutidioはオンライン版が発表されたし、デスクトップアプリの開発はもう死に体になろうとしてる
新しい開発フレームワークがこれまでより求められてきているが、Blazorは本命なのだろうか レガシー化してもいいから.netcoreから変更なしで使えるようにしてくれたら何も問題ない
それを全部使えなくして再実装しなおすんだから馬鹿なんじゃないかと思う サーバ用途はしらんけどデスクトップのWindows向けならほぼ間違いなく.Net Frameworkインストール済みだし
.Net Coreに移行してどんなメリットがあるのかわからん SCDを選択すれば今回みたいにWUでWinformsのレイアウトが崩れたりしない!!!
イヤあれ根本的な原因がフレームワークのコードに起因するのかWin32APIの変更に引っ張られたのか知らんけど >>975
ストアアプリ専用じゃない?
いずれデスクトップも検討すると言ってたけど
今になっても噂もないってことは見送りになったんだろうね? 今回のアナウンス見てもそれじゃあ噂がない以前に元々興味が無いだけでは VS onlineってexeもローカルに出力できんの?
クラウド上でビルドしてアウトプットを別途ダウンロードするみたいな感じ?
後者だとは思うけど >>977がちゃんと読んでないだけだねえ
.NET CoreがAOTに対応するとはどこにも書いてないよ
・CoreFX (クラスライブラリ) がAOTに対応する
・CoreCLR はJITを活用して長時間実行するアプリケーションでの高スループットと高生産性を提供する
・.NET Nativeが.NET 5ファミリーに含まれるのかどうかは言及なし
・起動時間や iOS, Blazor 等プラットフォームの制約のためAOTが必要なケースには、MonoのAOTを利用して対応する >>978
リモート操作も含めて全てクラウドの仮想環境上で実行できるに一票
Onlineは定額制になり、Azureの利用範囲に応じてプランがある感じになるんじゃないだろうか
ビルドされたものがzipでパックされて、都度DLしてっていうのはちょっとないよね GoogleがFlutter for Webを発表したな
界隈のウェブ化の波が凄い。絶賛乗り遅れ中ですよ >>980
やっぱクラウドなんだろうねー
ローカルでちょくちょく使うちょっとしたツール類が使いづらくなるのがなー >>982
Dartやだー
どうせだったらTypeScriptでPWA作るほうがいい DartってC#に似てたような気がする
async awaitがc#より良い出来のシンタックスシュガーに包まれてた気がする
気がするばかりで済まぬ Livechartsのツールチップをカスタムしたくて色々XAMLいじってたら、ツールチップ表示時にブレークモードで落ちるようになった。問題なかった時と同じ状態まで戻してもダメ。どうしたらいいのか... >>989
なんかのタイミングでどっかのコンポーネントが
再コンパイルされちゃって固定したんだろね?
(始める前にイメージバックアップで全部戻せるようにしたほうがとは思うけどいまさらだろうから)
Livechartsの環境構築やり直すしか思いつかない >>980
VScodeベースだし
.NET言語はRoslynコンパイラもWebAssemblyにしてローカルで動かすかもよ?
(C++はVS on windows使ってねでサポート外?) >>992
C#のコンパイルしたことある?(JAVAでもいいけど)
VMオブジェクト指向言語はかなり実行時に投げてるからコンパイル自体は軽い
スマホでも重くならないと思われ なおWPFはCoreでもWindowsでしか使えません。残念! このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 518日 8時間 17分 28秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。