WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22
■ このスレッドは過去ログ倉庫に格納されています
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/ デザイナ画面で、現在作業しているプロジェクトファイルのパスが取得したいのですが、方法ありますでしょうか？
AssemblyやGetCurrentDirectoryを使ってもXDesProcのパスが返ってきて取得できません ComputeFirstItemInViewportIndexAndOffsetがFloorをつかっている件か datagridにおいて、以下のようなキーボード操作はXAMLだけで記述できますでしょうか？
・セルのtab移動を止める
・enterキーで次の行に移動するのを止める（矢印キーのみで移動） DataGridは未完成糞品質のまま開発打ち切られて放置されたままのゴミだから使っちゃダメ
WinFormsのをホストして使うかサードのを買うかListViewでスクラッチするかWPFを捨てよう >>163
行数少なければ十分使えるから、数百行表示させないようにプログラムすればいいだけですね 2ヶ月ちょいjs/javaやったけど
Eclipseはポトペタできへんから面倒くさすぎる
いやワイが知らんだけかもしらんけど
しかしIDE落ちまくるし同期とらんと時々嘘くさい表示しよるし何なんやこれ
隣の席のやつ(javaﾏﾝ)はWPFやらされててワカランワカランいうてるし
ちゃんと履歴書読んどんのかここの会社逆やろｗ そう思うんなら便所に落書きするより上司に相談しろ
喜んで入れ替えてくれるだろ
その程度の交渉や調整もできないカスなら何やらせたってダメだし、会社もお前に何も期待しないよ 替わりたくないんやが
ちな会社は赤字垂れ流して潰れそうやでw 嘘みたいな話だけどeclipse大好きっこているんだぞ
一個も共感できないeclipse自慢話してくるよ eclipseはモダンemacs的な開発者のオープンプラットフォームとして、
今でいうVSCodeに近いポジションを占めてたから、そういう面ではわりと根強いファンはいた
今ではJavaはIntelliJに取られemacs的な用途はVSCodeに取られ完全にオワコン GridSplitter を挟んだUIを作成中です
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="1*"/>
<ColumnDefinition Width="Auto"/>
<ColumnDefinition Width="3*"/>
</Grid.ColumnDefinitions>
...
上記のように Columnの幅を1:3などの割合のまま、
Properties.Settings のメンバに Bind するにはどのようにしたらよいですか？
下記のように書いてみましたが、いくつか問題にぶち当たりました
<ColumnDefinition Width="{Binding Source={x:Static p:Settings.Default}, Path=ColumnSplitterSize, Mode=TwoWay}"/>
・Column の幅を変更して、Settings.Default.Save() しても Settings に反映されない（Settings の他の値の変更は確認済み）
・Settings の要素の型に GridLength を指定した場合、3* などを指定できない（数値かアスタリスクのみ）
・1:3 などの割合を指定したまま、サイズを保存、復元する方法があるのか不明
グリッド幅の保存は基本だと思うので簡易な方法があると思うのですが…… >>173
はい、GridLength 構造体です
Settings の要素の型を GridLength にしても反映されないので質問しました
何か基本的なことを見落としてるような気がします GridLength GridUnitType.Starでぐぐる >>169
マルチプラットフォーム的なのが少なかったんで
選択肢がそこに居ちゃっていたってことじゃないんかな？ >>172
１：３なのに、なんでAUTOが入ってるの？ 試行錯誤しつつ、あれから冷却期間を入れて試したところ 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の書き方になってます あああ、typo です
「ただ、Settings で指定は可能なのですが、Grid.Width プロパティは実際のサイズに連動しておらず〜」
ColumnDefinition.Width プロパティの間違いです 175は忘れてください
Value+GridUnitType <--> 文字列 相互変換できてました
フォルダー <UserName>\AppData\Local\<アプリケーション名>
の下のほうの user.configに書き込まれているはず splitterの幅をバリアブルにしている理由はなんなの？ 質問させてください。
以下の画像のようにウィンドウの表示が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> >>184
SizeToContent paints an unwanted border
https://stackoverflow.com/questions/16356507/sizetocontent-paints-an-unwanted-border
<Window UseLayoutRounding="True" />
でとりあえずその線は消えた >>185
レスありがとうございます！私の方でも線が消えることを確認しました。
Webで検索しても答えを見つけられなかったので質問させていただいたのですが、
恥ずかしいことに紹介していただいたページは見落としてしまっていたようです。
何はともあれ、お答えいただきどうもありがとうございました。 >>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);
}
}
（続く） （続き）
原因はほとんど分かっていて、
・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 したつもりが順番が逆転してしまうなど
思わぬバグの原因となりかねないためできれば避けたいと考えています。どうぞよろしくお願いいたします。 Windowsでしか動かない.NET Coreアプリw
一体何の意味があるのか せっかく.NET Coreが盛り上がってきてたところだったのに、水を差すことになりそうで心配だな
Linuxサーバーで運用してる人達からしたら、結局梯子外してWinに誘導するいつものMSがまた正体を現したかと疑念を持たれるよこれ >>193
Windowsにインストールされた.NET Frameworkに縛られなくなる >>194
そもそもWindowsでしか動かなかったもののランタイムが変わるだけだし、corefx自体に追加されるわけじゃない
むしろ.NET Coreの普及を後押しする 実質何も発表なかったこと一緒ってこと?
.NETは完全にWinプラトフォーム環境限定ということでオワコン サーバーサイドはクロスだけど微妙にしか人気ねぇし、Xamarin捨てる勇気なかったのか >>197
どこをどう読んだらそうなるんだよｗｗｗ .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ツールキットの拡張とモダン化である。 .NET Coreが全然注目されないからいろいろやりだしたんだな
いままでの.NET Coreって誰から見たら魅力があるのかわからない微妙な物だから
積極的に使いたいと言う人は少なかった 日本は全体的に低レベルなエンジニアが多い
なのでUIとその他のロジックがガッツリ結合して分離できない
なのでそう簡単には.Net Coreに移植できなかった
そうする必要のないあらゆるものまでがdnfやwindowsインフラに依存してしまっていたんだ
そりゃ移植して使えないものに魅力は感じないだろう
海外では設計が綺麗なので細かいコンポーネント事に移植の可能性を検討することができた
移植可能なものはすぐに移植する動きが広まってあっという間にCore対応が進んだ
彼らは高パフォーマンス、セルフコンテインドデプロイ、マルチプラットフォーム対応といった様々な収穫を殆どタダで得ることができた
.NET Coreはとても魅力的でエキサイティングなアップデートだった .NET Coreは既存の環境から乗り換えたいと思わせるだけの魅力がない
windowsで,.net frameworkから乗り換える人は少ない
linuxで他の言語から乗り換える人も少ない
利点をはっきり打ち出せてない
ただ作りました使ってくださいじゃ使わない コンパイルして起動時間が一桁早くなるってのは十分な魅力だと思うが >>203
>>202でも書いたけど日本ではスパゲティシステムだらけで移植のコストが高すぎたから受け入れられなかった
海外では日頃から品質を高める努力をしていたので移植が容易にできた
そして様々なメリットを享受することができた
利点を示せなかったのではなく
利点を示したけど日本だけが利点を受け入れる下地ができてなかっただけ
つまり日本はハブられたんだよ
いじめられっ子がリア充の生き方なんつまらないと負け惜しみを言うようなもの
キツネとすっぱい葡萄の心理というやつだ >>204
起動は確実にクソ遅くなるよ
今までは共有ライブラリとしてシステムにインストされいて自然にメモリにキャッシュされてた大量のDLL達を、
ローカルにバンドルしていちいちディスクからロードするんだから >>206
.net nativeはスタティックリンクだから、ライブラリの中で使っている部分だけ切り取って本体に取り込んでリンクするんだわ
通常はファイルサイズが激減します >>207
勘違いしてるようだけど、.NET CoreのSCDと.NET Nativeは別物だよ
SCDは.NET Coreランタイムと依存DLLを全部バンドルするだけ >>208
一番要望の多いnative取り入れないとは思えないが、情報あるの？ 体感的にわからない程度に起動が遅くなるかもしれない
デメリットってそれだけ？ >>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よりは結果的にロードするサイズが小さくなる可能性はあるよ >>211
将来はともかく、最初はこの程度なんかね よく分かんないけど
動作環境の.NETバージョンに影響されずに済むって話じゃないの >>210
全部バンドルしちまえってのは今時の流行りで基本的には良いものだけど、あえて挙げるならこんなとこかな
・配布サイズがクソ大きくなる
・DLLのディスクキャッシュが共有されないのでメモリを食うかも
・.NETに重大な脆弱性や不具合が見つかってもユーザーの裁量で.NETを更新できない
・NuGet必須なのでインターネット環境がないとビルドすらできない
・NuGet必須なのでキャッシュなしの状態だとビルドがクソ遅い ・.NET Coreは(NuGetのせいでもあるが)デバッグが遅い
も追加で >>214
RuntimeStoreも知らないようだし、NuGetがインターネット必須ってのも大嘘
ユーザーの裁量でRuntimeを更新できないってのも嘘 >>217
最近はずっと.NET Core&C#&Azureやってるよ
一般的な常識に基づく推論と俺の個人的経験で書いただけだから、間違いがあるなら具体的に指摘してるれると助かる corefxやcoreclrも知らないからユーザーの裁量でランタイムを更新できないって発想になるんか？ >>216
そちらは新規開発案件の1割以上がc#を使ってる世界ですか？
不思議な世界ですね
こちらの世界は全ソフトウエア開発者で.Net Coreを知ってる人が
1%以上いるかどうか怪しいです >>219
配布サイズが大きいのは、RuntimeStoreのない時代かもしくはランタイム自体をアプリに同梱する場合ね >>223
いい加減に空想の世界から出て来いよ
.Net Coreなんてほとんど誰も知らない
C#使ってる中でも知られてない
みんな跨いでいく デスクトップでCore使うメリットはSCDで、当然それは大前提だと思ってたんだけど
システムにCore入れるならそれこそ何の意味もなくね？ サーバサイドでも使われてない
デスクトップでも使われてない
業務でも使われてない
趣味で使うのがちょうどいい
C#大大大大好きだけど.Net CoreやAsp.net CoreやUWPは早く消えてほしい >>224
Stackoverflowのreportでも見て現実を直視しろよｗｗｗ >>225
どうも思い込みが激しいようだ
どっちかって言うとSCDこそ特殊な場合で、SideBySideでランタイムをインストールする方が良い >>228
だからそれFull .NETのサイドバイサイドと比べて何のメリットがあるの？ >>230
たとえば.NET4.5.2と4.6.1はSideBySideでインストールできないっしょ？ >>232
結局システムに.NETを入れさせなきゃいけないのは同じだよね
.NET Coreなんか頻繁にアップデートされてるから事実上はほとんど特定のアプリと一対一になるだろうし、
アプリ側で.NETのバージョンを上げたくなったらまたそのアプリのためだけにまた特定バージョンのCoreをインストールさせるのか?
そのとき前のバージョンを安全に削除できるかどうか誰がわかる？
開発環境でのテストくらいにしか使えないよこんなの まだ実用化されていない技術のブログ記事上げてドヤってる
それは既存の.Net Coreの利点じゃないだろ？ コアのアーキテクトの戦略がフラフラしてる
魅力のないロードマップがそれを物語ってる >>230
こいつSideBySideなんて知らんのやろ >>236-237
.NET CoreのSideBySideを利用したデスクトップアプリの正しいデプロイサイクルを具体的に説明してくれ ちなみに.NET Coreって月一くらいのペースでバージョン上がってるんだが、それ全部SideBySideするってことだぞ？
アプリとは別にシステムの.NETのバージョン管理の余計な手間が増える以外になんかSCDと比較してメリットある？ >>214
NuGetって言葉覚えたてかな？嘘ばっかｗｗｗ >>240
結局アプリごとに必要とするバージョンが違うケースが多いはずだからSCDでいいだろと言ってるんだけど、これだけ言っても伝わらない？ >>242
>アプリごとに必要とするバージョンが違うケースが多い
なんで？ >>244
そりゃ.NET CoreかつFDDのアプリ自体が(WinFormsやWPFがサポートされてもなお)稀だろうし、
フレームワークの方も月一で更新されてるとなれば共有できるケースは現実にはほとんど無いでしょ もちろんデスクトップアプリに限った話な
サーバーだと一括で複数のアプリをデプロイしたりすることは普通にあるからもちろん意味はあるよ WPFってグラボの違いでどれくらい速度変わってくるものなの？
ハイスペックグラボ使う意味ある？ 大変そうだな。予防線はりまくりマウント取ろうと形だけは前傾で デスクトップ対応はありがたい
業務系でウェブアプリはめんどくさいだけなんだよね >>211
https://github.com/dotnet/corert
corertとかあるけどこれちゃうの？
ちょくちょく試すけど相変わらずx86がうまく生成されなかったりIssue多すぎて
比較的アクティブとはいえ使い物になるのかよくわからん状況だけど
VCランタイムすら不要の単体PEファイルになってdnSpyとかじゃなんも見れなくなるし
こういうのがプロジェクト単位でざっくりと組み込み検討できそうだから
デスクトップ向けの.NET Coreも結構期待してたりするんだけどね
WinformsとWPFのポーティングは朗報だけどどうせ改良する気はないんだろうし
クロスプラットーム化は無理でもせめてReference Source下じゃなくOSSにまでして提供してほしいもんだぬ なんでDateTimePickerすら入ってねえんだこのゴミは
こんなんだから普及しねえんだよ オープンソース化もあり得るって話だぜ
なんであれが無いんだーじゃなくてなければ作ってプルリクが当たり前になるのかな
数年後には有料サードパーティライブラリのような高級コンポートが標準化されるかもね 標準でnumericupdownすらないWPFに何を言っても無駄 欲しいものは自分で書いてプルリクを出せばいい
同じことをみんなやりだすからすぐにリッチコントロールが整備される そういえば標準じゃフォルダー選択ダイアログもないな WPFって正しく作法に従った汎用コンポーネント作るの結構難しいから、外野がプルリク投げてもなかなかマージされないと思うぞ
MS謹製のToolkitですら悲惨な品質でWPF本体にさっぱり採用されないまま潰れちゃったし ■ このスレッドは過去ログ倉庫に格納されています
