WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22

■ このスレッドは過去ログ倉庫に格納されています
2017/12/13(水) 23:35:47.18ID:muTUiD7C
Windows Presentation Frameworkについて語るスレ。

前スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part21
http://mevius.2ch.net/test/read.cgi/tech/1494288553/

関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.net/test/read.cgi/tech/1499658092/

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/
176デフォルトの名無しさん
垢版 |
2018/05/05(土) 08:55:29.93ID:GHjIUW8T
>>169
マルチプラットフォーム的なのが少なかったんで
選択肢がそこに居ちゃっていたってことじゃないんかな？
177デフォルトの名無しさん
垢版 |
2018/05/05(土) 09:01:31.10ID:GHjIUW8T
>>172
１：３なのに、なんでAUTOが入ってるの？
178デフォルトの名無しさん
垢版 |
2018/05/05(土) 09:04:56.56ID:nVs07IkD
>>177
GridSplitter
179172
垢版 |
2018/05/05(土) 11:44:18.82ID:+6BF6Qlx
試行錯誤しつつ、あれから冷却期間を入れて試したところ 2番目の問題は設定できるようになりました

>>175
> 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に保存する？）

>>178
はい、GridSplitter を挟んでGridの列を 1:3 にするXAMLの書き方になってます
180172
垢版 |
2018/05/05(土) 11:48:02.94ID:+6BF6Qlx
あああ、typo です
「ただ、Settings で指定は可能なのですが、Grid.Width プロパティは実際のサイズに連動しておらず〜」
ColumnDefinition.Width プロパティの間違いです
181175
垢版 |
2018/05/05(土) 17:52:13.05ID:Lbg9iiKd
175は忘れてください　
Value+GridUnitType　<--> 文字列 相互変換できてました
フォルダー　<UserName>\AppData\Local\<アプリケーション名>
の下のほうの user.configに書き込まれているはず
182デフォルトの名無しさん
垢版 |
2018/05/05(土) 23:52:00.74ID:enzOGVxg
splitterの幅をバリアブルにしている理由はなんなの？
183デフォルトの名無しさん
垢版 |
2018/05/05(土) 23:53:18.47ID:enzOGVxg
ま、いいか理由はあるんでしょうから。
2018/05/06(日) 15:47:40.64ID:Z7mEypo0
質問させてください。
以下の画像のようにウィンドウの表示が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>
2018/05/06(日) 16:36:46.08ID:JnKw6YEv
>>184
SizeToContent paints an unwanted border
https://stackoverflow.com/questions/16356507/sizetocontent-paints-an-unwanted-border

<Window UseLayoutRounding="True" />
でとりあえずその線は消えた
2018/05/06(日) 17:21:51.43ID:Z7mEypo0
>>185
レスありがとうございます！私の方でも線が消えることを確認しました。
Webで検索しても答えを見つけられなかったので質問させていただいたのですが、
恥ずかしいことに紹介していただいたページは見落としてしまっていたようです。

何はともあれ、お答えいただきどうもありがとうございました。
2018/05/06(日) 18:14:56.23ID:Z7mEypo0
>>184-186で自分の検索の不十分さを反省して以前から抱えていた別の問題も改めて検索してみたのですが、
やはり私の力ではどうしようもありませんでした。
立て続けに申し訳ないのですが、こちらについてもお力を貸していただけないでしょうか。

以下のような 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);
　　}
}

（続く）
2018/05/06(日) 18:15:23.63ID:Z7mEypo0
（続き）

原因はほとんど分かっていて、

・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 したつもりが順番が逆転してしまうなど
思わぬバグの原因となりかねないためできれば避けたいと考えています。どうぞよろしくお願いいたします。
2018/05/08(火) 00:48:26.70ID:wFWfdcvC
良かったなお前ら
https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/
2018/05/08(火) 01:18:46.99ID:8/Cw9iIa
YATTA!
2018/05/08(火) 01:50:46.69ID:vwdvRU81
やるやん
2018/05/08(火) 01:56:55.14ID:8PlXTSnU
日本語でOK
2018/05/08(火) 01:58:48.97ID:3Tr8AiF6
Windowsでしか動かない.NET Coreアプリw
一体何の意味があるのか
2018/05/08(火) 02:05:19.36ID:I+Jt0Kav
せっかく.NET Coreが盛り上がってきてたところだったのに、水を差すことになりそうで心配だな
Linuxサーバーで運用してる人達からしたら、結局梯子外してWinに誘導するいつものMSがまた正体を現したかと疑念を持たれるよこれ
2018/05/08(火) 02:37:14.81ID:wFWfdcvC
>>193
Windowsにインストールされた.NET Frameworkに縛られなくなる
2018/05/08(火) 02:39:25.29ID:u/n9hYSm
>>194
そもそもWindowsでしか動かなかったもののランタイムが変わるだけだし、corefx自体に追加されるわけじゃない
むしろ.NET Coreの普及を後押しする
2018/05/08(火) 17:52:26.19ID:xyA4XcJo
実質何も発表なかったこと一緒ってこと?
.NETは完全にWinプラトフォーム環境限定ということでオワコン
2018/05/08(火) 18:10:18.00ID:xyA4XcJo
サーバーサイドはクロスだけど微妙にしか人気ねぇし、Xamarin捨てる勇気なかったのか
2018/05/08(火) 18:17:27.20ID:kbsHCLUb
>>197
どこをどう読んだらそうなるんだよｗｗｗ
2018/05/10(木) 14:57:37.18ID:1UHxaKzf
.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ツールキットの拡張とモダン化である。
2018/05/13(日) 10:02:27.03ID:JffwGpoG
.NET Coreが全然注目されないからいろいろやりだしたんだな

いままでの.NET Coreって誰から見たら魅力があるのかわからない微妙な物だから
積極的に使いたいと言う人は少なかった
2018/05/13(日) 10:28:33.00ID:i7PAGBqe
日本は全体的に低レベルなエンジニアが多い
なのでUIとその他のロジックがガッツリ結合して分離できない
なのでそう簡単には.Net Coreに移植できなかった
そうする必要のないあらゆるものまでがdnfやwindowsインフラに依存してしまっていたんだ
そりゃ移植して使えないものに魅力は感じないだろう

海外では設計が綺麗なので細かいコンポーネント事に移植の可能性を検討することができた
移植可能なものはすぐに移植する動きが広まってあっという間にCore対応が進んだ
彼らは高パフォーマンス、セルフコンテインドデプロイ、マルチプラットフォーム対応といった様々な収穫を殆どタダで得ることができた
.NET Coreはとても魅力的でエキサイティングなアップデートだった
2018/05/13(日) 10:43:11.44ID:hwu0eulf
.NET Coreは既存の環境から乗り換えたいと思わせるだけの魅力がない
windowsで,.net frameworkから乗り換える人は少ない
linuxで他の言語から乗り換える人も少ない

利点をはっきり打ち出せてない
ただ作りました使ってくださいじゃ使わない
2018/05/13(日) 10:48:35.00ID:nDD5wzJU
コンパイルして起動時間が一桁早くなるってのは十分な魅力だと思うが
2018/05/13(日) 10:49:14.92ID:i7PAGBqe
>>203
>>202でも書いたけど日本ではスパゲティシステムだらけで移植のコストが高すぎたから受け入れられなかった

海外では日頃から品質を高める努力をしていたので移植が容易にできた
そして様々なメリットを享受することができた

利点を示せなかったのではなく
利点を示したけど日本だけが利点を受け入れる下地ができてなかっただけ

つまり日本はハブられたんだよ
いじめられっ子がリア充の生き方なんつまらないと負け惜しみを言うようなもの
キツネとすっぱい葡萄の心理というやつだ
2018/05/13(日) 10:52:56.28ID:VCvSTJHc
>>204
起動は確実にクソ遅くなるよ
今までは共有ライブラリとしてシステムにインストされいて自然にメモリにキャッシュされてた大量のDLL達を、
ローカルにバンドルしていちいちディスクからロードするんだから
2018/05/13(日) 11:03:04.42ID:nDD5wzJU
>>206
.net nativeはスタティックリンクだから、ライブラリの中で使っている部分だけ切り取って本体に取り込んでリンクするんだわ
通常はファイルサイズが激減します
2018/05/13(日) 11:06:50.54ID:VCvSTJHc
>>207
勘違いしてるようだけど、.NET CoreのSCDと.NET Nativeは別物だよ
SCDは.NET Coreランタイムと依存DLLを全部バンドルするだけ
2018/05/13(日) 11:15:03.29ID:nDD5wzJU
>>208

一番要望の多いnative取り入れないとは思えないが、情報あるの？
2018/05/13(日) 11:22:25.15ID:i7PAGBqe
体感的にわからない程度に起動が遅くなるかもしれない

デメリットってそれだけ？
2018/05/13(日) 11:23:47.84ID:VCvSTJHc
>>209
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よりは結果的にロードするサイズが小さくなる可能性はあるよ
2018/05/13(日) 11:34:23.20ID:nDD5wzJU
>>211
将来はともかく、最初はこの程度なんかね
2018/05/13(日) 11:39:17.10ID:QSiC/kkG
よく分かんないけど
動作環境の.NETバージョンに影響されずに済むって話じゃないの
2018/05/13(日) 11:44:29.93ID:VCvSTJHc
>>210
全部バンドルしちまえってのは今時の流行りで基本的には良いものだけど、あえて挙げるならこんなとこかな
・配布サイズがクソ大きくなる
・DLLのディスクキャッシュが共有されないのでメモリを食うかも
・.NETに重大な脆弱性や不具合が見つかってもユーザーの裁量で.NETを更新できない
・NuGet必須なのでインターネット環境がないとビルドすらできない
・NuGet必須なのでキャッシュなしの状態だとビルドがクソ遅い
2018/05/13(日) 11:46:21.62ID:VCvSTJHc
・.NET Coreは(NuGetのせいでもあるが)デバッグが遅い
も追加で
2018/05/13(日) 11:56:03.56ID:gN1ETgni
>>201
どうやら違う世界に生きてるようだ
2018/05/13(日) 12:00:18.98ID:olmzHM0E
>>214
こいつC#使ったことないやろ…
2018/05/13(日) 12:05:59.25ID:vAxwPzXD
>>214
RuntimeStoreも知らないようだし、NuGetがインターネット必須ってのも大嘘
ユーザーの裁量でRuntimeを更新できないってのも嘘
2018/05/13(日) 12:06:45.67ID:VCvSTJHc
>>217
最近はずっと.NET Core&C#&Azureやってるよ
一般的な常識に基づく推論と俺の個人的経験で書いただけだから、間違いがあるなら具体的に指摘してるれると助かる
2018/05/13(日) 12:07:59.36ID:FNCE059f
corefxやcoreclrも知らないからユーザーの裁量でランタイムを更新できないって発想になるんか？
2018/05/13(日) 12:08:12.97ID:hwu0eulf
>>216
そちらは新規開発案件の1割以上がc#を使ってる世界ですか？
不思議な世界ですね

こちらの世界は全ソフトウエア開発者で.Net Coreを知ってる人が
1%以上いるかどうか怪しいです
2018/05/13(日) 12:09:07.71ID:FNCE059f
>>219
配布サイズが大きいのは、RuntimeStoreのない時代かもしくはランタイム自体をアプリに同梱する場合ね
2018/05/13(日) 12:09:52.99ID:dLXOPcbs
>>221
ああ奴隷の世界ねごめんよ
2018/05/13(日) 12:11:36.53ID:hwu0eulf
>>223
いい加減に空想の世界から出て来いよ

.Net Coreなんてほとんど誰も知らない
C#使ってる中でも知られてない
みんな跨いでいく
225214
垢版 |
2018/05/13(日) 12:11:45.00ID:VCvSTJHc
デスクトップでCore使うメリットはSCDで、当然それは大前提だと思ってたんだけど
システムにCore入れるならそれこそ何の意味もなくね？
2018/05/13(日) 12:14:31.02ID:hwu0eulf
サーバサイドでも使われてない
デスクトップでも使われてない
業務でも使われてない

趣味で使うのがちょうどいい
C#大大大大好きだけど.Net CoreやAsp.net CoreやUWPは早く消えてほしい
2018/05/13(日) 12:17:23.58ID:dLXOPcbs
>>224
Stackoverflowのreportでも見て現実を直視しろよｗｗｗ
2018/05/13(日) 12:19:44.68ID:dLXOPcbs
>>225
どうも思い込みが激しいようだ
どっちかって言うとSCDこそ特殊な場合で、SideBySideでランタイムをインストールする方が良い
2018/05/13(日) 12:21:24.73ID:LtcW78m3
>>225
Microsoftのブログくらい読めよ
https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/
2018/05/13(日) 12:26:39.99ID:VCvSTJHc
>>228
だからそれFull .NETのサイドバイサイドと比べて何のメリットがあるの？
2018/05/13(日) 12:29:17.88ID:LtcW78m3
>>230
>>229
2018/05/13(日) 12:31:43.28ID:ENNgICED
>>230
たとえば.NET4.5.2と4.6.1はSideBySideでインストールできないっしょ？
2018/05/13(日) 12:37:57.79ID:VCvSTJHc
>>232
結局システムに.NETを入れさせなきゃいけないのは同じだよね
.NET Coreなんか頻繁にアップデートされてるから事実上はほとんど特定のアプリと一対一になるだろうし、
アプリ側で.NETのバージョンを上げたくなったらまたそのアプリのためだけにまた特定バージョンのCoreをインストールさせるのか?
そのとき前のバージョンを安全に削除できるかどうか誰がわかる？
開発環境でのテストくらいにしか使えないよこんなの
2018/05/13(日) 13:04:22.39ID:kjz8UZqt
まだ実用化されていない技術のブログ記事上げてドヤってる
それは既存の.Net Coreの利点じゃないだろ？
2018/05/13(日) 13:05:48.16ID:kjz8UZqt
コアのアーキテクトの戦略がフラフラしてる
魅力のないロードマップがそれを物語ってる
2018/05/13(日) 22:00:07.98ID:ENNgICED
>>233
前のバージョンを削除ｗｗｗ
2018/05/13(日) 22:01:26.62ID:RTDdDgUS
>>230
こいつSideBySideなんて知らんのやろ
2018/05/13(日) 22:07:34.73ID:yk+U0xvA
>>236-237
.NET CoreのSideBySideを利用したデスクトップアプリの正しいデプロイサイクルを具体的に説明してくれ
2018/05/13(日) 22:24:25.44ID:yk+U0xvA
ちなみに.NET Coreって月一くらいのペースでバージョン上がってるんだが、それ全部SideBySideするってことだぞ？
アプリとは別にシステムの.NETのバージョン管理の余計な手間が増える以外になんかSCDと比較してメリットある？
2018/05/13(日) 22:27:27.84ID:F2hiJGIV
>>239
全部とかただのキチガイか
2018/05/13(日) 22:30:48.25ID:F2hiJGIV
>>214
NuGetって言葉覚えたてかな？嘘ばっかｗｗｗ
2018/05/13(日) 22:55:13.58ID:yk+U0xvA
>>240
結局アプリごとに必要とするバージョンが違うケースが多いはずだからSCDでいいだろと言ってるんだけど、これだけ言っても伝わらない？
2018/05/13(日) 22:57:05.68ID:F2hiJGIV
>>242
RuntimeStore
2018/05/13(日) 22:59:58.25ID:9k6A64Mq
>>242
>アプリごとに必要とするバージョンが違うケースが多い
なんで？
2018/05/13(日) 23:21:18.21ID:yk+U0xvA
>>244
そりゃ.NET CoreかつFDDのアプリ自体が(WinFormsやWPFがサポートされてもなお)稀だろうし、
フレームワークの方も月一で更新されてるとなれば共有できるケースは現実にはほとんど無いでしょ
246245
垢版 |
2018/05/13(日) 23:23:46.38ID:yk+U0xvA
もちろんデスクトップアプリに限った話な
サーバーだと一括で複数のアプリをデプロイしたりすることは普通にあるからもちろん意味はあるよ
2018/05/13(日) 23:46:18.97ID:vj3G+EXI
WPFってグラボの違いでどれくらい速度変わってくるものなの？
ハイスペックグラボ使う意味ある？
2018/05/13(日) 23:55:08.61ID:F2hiJGIV
>>245
妄想おつ
2018/05/14(月) 02:28:15.65ID:tinSsmGQ
大変そうだな。予防線はりまくりマウント取ろうと形だけは前傾で
2018/05/14(月) 19:24:27.32ID:wio42IgJ
デスクトップ対応はありがたい
業務系でウェブアプリはめんどくさいだけなんだよね
2018/05/16(水) 17:32:30.01ID:39uyimjr
>>211
https://github.com/dotnet/corert

corertとかあるけどこれちゃうの？

ちょくちょく試すけど相変わらずx86がうまく生成されなかったりIssue多すぎて
比較的アクティブとはいえ使い物になるのかよくわからん状況だけど

VCランタイムすら不要の単体PEファイルになってdnSpyとかじゃなんも見れなくなるし
こういうのがプロジェクト単位でざっくりと組み込み検討できそうだから
デスクトップ向けの.NET Coreも結構期待してたりするんだけどね

WinformsとWPFのポーティングは朗報だけどどうせ改良する気はないんだろうし
クロスプラットーム化は無理でもせめてReference Source下じゃなくOSSにまでして提供してほしいもんだぬ
2018/05/19(土) 08:24:35.34ID:sLNELaog
なんでDateTimePickerすら入ってねえんだこのゴミは
こんなんだから普及しねえんだよ
2018/05/19(土) 09:37:09.80ID:z3BmCHYg
オープンソース化もあり得るって話だぜ
なんであれが無いんだーじゃなくてなければ作ってプルリクが当たり前になるのかな
数年後には有料サードパーティライブラリのような高級コンポートが標準化されるかもね
2018/05/19(土) 18:26:15.09ID:F+BrwfqW
標準でnumericupdownすらないWPFに何を言っても無駄
2018/05/19(土) 18:30:55.35ID:m/ZPa8pN
欲しいものは自分で書いてプルリクを出せばいい
同じことをみんなやりだすからすぐにリッチコントロールが整備される
2018/05/19(土) 18:39:08.87ID:F+BrwfqW
そういえば標準じゃフォルダー選択ダイアログもないな
2018/05/19(土) 18:39:33.95ID:JYjAGOT8
WPFって正しく作法に従った汎用コンポーネント作るの結構難しいから、外野がプルリク投げてもなかなかマージされないと思うぞ
MS謹製のToolkitですら悲惨な品質でWPF本体にさっぱり採用されないまま潰れちゃったし
2018/05/19(土) 20:17:50.91ID:NGcY8HAA
Material Design In XAML ToolkKit　使えばいいじゃん
259デフォルトの名無しさん
垢版 |
2018/05/23(水) 19:30:21.93ID:Au5e7VGg
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

204GM
2018/05/23(水) 19:52:37.44ID:zdZwe3wq
FormsとWPFはUIテスト自動化への対応具合どうなの？
UIテスト自動化が快適にならないと躊躇してしまうよね
いちおうappiumのドライバは見つけたけど業務で使いこんでるぜって類の記事が全然出てこない
2018/05/23(水) 20:26:37.25ID:aEBJ6EJ+
>>260
https://github.com/Microsoft/WinAppDriver
2018/05/23(水) 20:29:25.96ID:aEBJ6EJ+
1.0.0が出たのは去年の10月だからね
263デフォルトの名無しさん
垢版 |
2018/05/24(木) 23:37:42.82ID:tm7qGCzu
prismってmessengerパターンするならEventAggregator使うようになったの？
InteractionRequestは過去のも？
2018/05/25(金) 00:20:28.41ID:n6q2Xjj/
今のprismってMSの手を離れて単なるコミュニティプロジェクトの一つだからなあ
開発者の好みが反映された寄せ集めのツールキット集に過ぎず、もはやリファレンスでもなんでもないよ
2018/05/25(金) 00:30:47.36ID:N3c6aWbU
>>263がInteractionRequestが好みなら自分でプロジェクトにコントリビュートすればいい
EventAggregatorよりも充実させればInteractionRequestがPrismの主流に見えるようになるだろう
今のPrismってそういうもんで、トレンドを追っても何の意味もない
2018/06/06(水) 21:19:46.59ID:3palNJuH
Datagrid内comboboxのdatatemplateのバインディングがどうやってもできないw
2018/06/08(金) 06:20:36.50ID:y7GGIwCz
>>266
サンプル見ると、スタティックなオブジェクトリンクしている
268デフォルトの名無しさん
垢版 |
2018/06/14(木) 10:39:07.09ID:LFx88o2A
Prism6.3でInteractionRequestのRaiseAsync使おうとしたらないんだけど
問題あってなくなったの？
2018/06/14(木) 23:50:25.85ID:rYhQU2t8
>>268
どこの馬の骨とも知れないメンテナの気まぐれ
君が復活させてもいいんだぞ
2018/06/15(金) 10:37:05.30ID:uIGrLsPa
共同ツール 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/
271デフォルトの名無しさん
垢版 |
2018/06/19(火) 20:48:04.40ID:CqYMFqFG
>>252
>>254
いつかはWPFって思ってたのに移行できねーよそれじゃ

まあ、趣味ではWebサイトの方で忙しいから最近はC#あんまできないんだが
2018/06/19(火) 21:58:45.18ID:TcCdudwM
UWPにもnumericuodownないんだよな。死ねよと思う。
2018/06/20(水) 00:56:27.15ID:iNKqsiVm
タッチデバイスのためとはいえ、ほんと実用軽視には反吐が出るな。UI統一は大失敗。
2018/06/21(木) 06:23:26.72ID:EAKDFUEl
>266
俺はこんな感じでやってるけど
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>
2018/07/03(火) 13:58:21.59ID:hHP/xN4T
質問失礼します

以下の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"という記述が受け入れられたり
この記述を行うときに入力補完が働いたりする仕組みが全く想像できないのですが、
そのような仕組みを新しく定義した型で使うことは可能でしょうか

もしご存知の方がいらっしゃれば教えていただけると嬉しいです
よろしくお願いします
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況