WPF(.NET, WinUI) GUIプログラミング Part30

**デフォルトの名無しさん** · 2022/10/29(土) 11:34:34.12

WPF(Windows Presentation Foundation)について語るスレ。

前スレ
WPF(.NET, WinUI) GUIプログラミング Part29
http://mevius.5ch.net/test/read.cgi/tech/1649621434/

関連スレ
Windows 10 UWPアプリ開発Part 3
https://mevius.5ch.net/test/read.cgi/tech/1627556967/

コードを貼る場合は以下のサイトの利用をお勧め。
https://ideone.com/

**デフォルトの名無しさん** · 2022/12/31(土) 16:39:06.26

じゃあお前らが言うにはこれからもXAMLデザイナはいらんわけだ
廃れるだけだと思うがなあ…

**デフォルトの名無しさん** · 2022/12/31(土) 16:44:09.08

>>625
とりあえず何度かアンカー飛ばしておこう

**デフォルトの名無しさん** · 2022/12/31(土) 16:45:34.57

もう一度　>>625

**デフォルトの名無しさん** · 2022/12/31(土) 17:08:27.58

とあるプロパティにxamlで値が設定されてるかどうかをコード上から判定したいんだけど、方法ありますか？
なんでそんなことをしたいかと言うと
xamlで値やBindingが設定されて無ければコード上で特定の値を設定するため
WPFのプロいない？

**デフォルトの名無しさん** · 2022/12/31(土) 17:15:15.93

xmlとして解析するしかない

**デフォルトの名無しさん** · 2022/12/31(土) 17:19:07.51

デザイナーいらんよ

**デフォルトの名無しさん** · 2022/12/31(土) 18:49:56.12

今ってポトペタでデザインするフレームワークあるの？
Windows以外で

**デフォルトの名無しさん** · 2022/12/31(土) 19:31:50.04

むしろandroidもxcodeも過去のwinformwpfですら対応してるというのに

**デフォルトの名無しさん** · 2022/12/31(土) 19:49:12.81

>>638
csコードのままポトペタ実現してたWinFormsという実例があるのに何ってんだ？

**デフォルトの名無しさん** · 2022/12/31(土) 19:51:49.26

>>641
哀れだねぇ

**デフォルトの名無しさん** · 2022/12/31(土) 20:18:00.32

>>648
現実を見ようよｗ

各陣営どうやって開発者を増やしていくかと言うのが一番の課題なのに
俺が使えるからデザイナいらねえって言ってる馬鹿がお前なんだけど

**デフォルトの名無しさん** · 2022/12/31(土) 20:42:16.08

デザイナで調整することなんてあるのか？
XAML触ったほうがよくないか？

**デフォルトの名無しさん** · 2022/12/31(土) 20:55:46.70

WinUIってデザイナはBlend使うんじゃないの？

**デフォルトの名無しさん** · 2022/12/31(土) 21:11:00.04

>>647
WinFormsのデザイナは手書きに対応していないし自動生成コードを手で弄ったら壊れる
あれはソースコードの形を取ってはいるが実質的に専用の設定ファイルと変わらん
しょうもない揚げ足取りはやめろ

**デフォルトの名無しさん** · 2022/12/31(土) 22:57:39.02

>>652
向いてるかどうかは別にして
デザイナのコードを手修正しても、一から手で作成しても
正しく作ればそれでデザイナが壊れるなんてことはない

実際ちょっとした修正ならデザイナ開かず直接コード修正とかよくやる
専用の設定ファイルとかじゃなくて、まさに正しいソースコードだけど

**デフォルトの名無しさん** · 2023/01/01(日) 00:42:07.84

ホットリドードは FontSize=""で堕ちるバグ修正してくれ
判っていたもついやっちまうんだよな

**デフォルトの名無しさん** · 2023/01/01(日) 08:46:50.91

>>652
>あれはソースコードの形を取ってはいるが実質的に専用の設定ファイルと変わらん

そういう扱いでいいわけだからわざわざXAMLにする理由になってないということなんだが。

**デフォルトの名無しさん** · 2023/01/01(日) 09:23:08.25

>>655
•プログラミング言語非依存
•デザイナと手書きや手修正の両立
を実現しようとしたんだよ
結果、デザイナにも手書きにも適さない中途半端なものが出来上がったというわけだ

**デフォルトの名無しさん** · 2023/01/01(日) 10:23:43.73

android studioみたいなデザイナーないの？

**デフォルトの名無しさん** · 2023/01/01(日) 10:43:36.47

>結果、デザイナにも手書きにも適さない中途半端なものが出来上がったというわけだ

手書きはすごく便利になったと思うが。
このへんやっぱりXMLアレルギーの人とは意見が合わないんだよなぁ。

**デフォルトの名無しさん** · 2023/01/01(日) 11:37:16.20

XMLで書けない人が騒いでるだけだろ
ざっくりレイアウトする時にデザイナー使うことあるけど最終的にはXMLで修正するし慣れればスクラッチからでもXMLの方が楽

**デフォルトの名無しさん** · 2023/01/01(日) 12:14:37.41

xmlだからだめじゃなくてxmlとしての公開の仕方がね

各コンポーネントをググらずに作り切れるやついるのかな
リストでちょっといじりたいときにcelltemlateとかdatatemplateを自力で導き出せるのかというね
機能競合してて動作しないバインディングとかイベントとか
こんなもんポチポチして勝手に生成したり警告してほしいんだ
UI書きたいんじゃなくてロジック書きたいんだ

**デフォルトの名無しさん** · 2023/01/01(日) 12:53:10.91

10年以上XAMLは手書きのインテリセンスがまともじゃなかったけど最近はかなりまとも

**デフォルトの名無しさん** · 2023/01/01(日) 13:22:26.85

デザイナ不要は暴論だと思うけどな
winui3だっけ?にデザイナがないなら絶対触らない

**デフォルトの名無しさん** · 2023/01/01(日) 13:28:23.88

microsoftがデザイナ廃止する移行だからしょうがない

**デフォルトの名無しさん** · 2023/01/01(日) 13:31:24.51

でたよUIにロジックを組み込もうとするやつ
こういう関心の分離に従わないやつがゴミコードを書くんだよな>>660

**デフォルトの名無しさん** · 2023/01/01(日) 13:37:55.88

htmlやcssだってデザイナなくてもあれだけリッチな画面作れるのにデザイナなんかいらんだろ

**デフォルトの名無しさん** · 2023/01/01(日) 13:40:46.67

>>665
CSSはホットリロードで作ってくから
デザイナーいらんのよ

**デフォルトの名無しさん** · 2023/01/01(日) 13:42:58.51

XAMLをデザイナーなしでとか効率悪すぎ

**デフォルトの名無しさん** · 2023/01/01(日) 13:44:36.70

>>665
デザイナ業務の人たちはデザイナ使ってるよ

**デフォルトの名無しさん** · 2023/01/01(日) 13:46:57.06

デザイナ業務　→　デザイン業務
レスポンシブなどの概念が広まった後は商用でcss手打ちしてる人はほぼいないと思う

**デフォルトの名無しさん** · 2023/01/01(日) 13:50:01.48

>>664
分離してるからuiの表現に力使いたくないって言ってるのに

**デフォルトの名無しさん** · 2023/01/01(日) 13:53:03.67

一つ理解したのはこのスレの人たちは理解力が低く勝手に勘違いして攻撃しあってる

**デフォルトの名無しさん** · 2023/01/01(日) 14:13:21.74

草

**デフォルトの名無しさん** · 2023/01/01(日) 14:17:33.26

xml系が嫌なら宣言的ui使えるプラットフォームに移行すればいいだけでは？
考えの押し売りはキモい

**デフォルトの名無しさん** · 2023/01/01(日) 14:34:58.15

>>669
どのデザイナ使ってんの？具体的に教えてくれ

**デフォルトの名無しさん** · 2023/01/01(日) 14:37:29.49

そこで、猫だ。と言えれば格好いいんだろうなぁ

**デフォルトの名無しさん** · 2023/01/01(日) 15:20:22.34

>>671
はいはいすごいでちゅね～

**デフォルトの名無しさん** · 2023/01/01(日) 22:22:13.58

UWP/WinUI 2 アプリは、いつ WinUI 3 に移行すればよいですか?
UWP 開発者は、UWP とその機能セットに満足しているのであれば、アプリを Windows App SDK へ移行する必要はないはずです。

WPF は非推奨ですか?
いいえ。 WPF はまだサポートされていて、いくつかの機能アップデートを受けることもできます。

WinForms は非推奨ですか?
いいえ。 WinForms はまだサポートされていて、いくつかの機能アップデートを受けることもできます

Windows ランタイム (WinRT) は非推奨ですか?
いいえ。 WinRT とは、複数の言語間での相互運用を可能にするアプリケーションバイナリインターフェイス (ABI) を指します。
WinRT は COM の進化系です。
Windows App SDK は、その機能のほとんどを WinRT API を通じて提供します。

**デフォルトの名無しさん** · 2023/01/02(月) 09:35:36.77

＞　WinRT は COM の進化系です

**デフォルトの名無しさん** · 2023/01/02(月) 09:51:00.68

プレビュー自体はホットリロードでもいいけど、連動していたドキュメントアウトラインからのスタイルテンプレ取得の機能をなんとかして欲しい
今のところgeneral.xaml開いて拾ってくるしか無い

**デフォルトの名無しさん** · 2023/01/02(月) 13:39:08.45

お前らはやくMAUIに移行しろよ

**デフォルトの名無しさん** · 2023/01/02(月) 14:16:13.90

>>584
MAUIといいWinUIといいバグだらけ
時間の無駄

**デフォルトの名無しさん** · 2023/01/02(月) 20:23:38.94

貴方には人脈作りが足りないわ

**デフォルトの名無しさん** · 2023/01/02(月) 21:04:04.57

WPFを真っ当に発展させていけばいいものをUWPだのMAUIだのWinUIだの同じようで異なるものをポンポンと

**デフォルトの名無しさん** · 2023/01/02(月) 21:12:47.63

WPFアニメーションで質問
コントロールがぬる～っと動くアニメーションxamlで作ってて
DoubleAnimationコントロールのToプロパティにBindingすると
「スレッド間で使用するために、この Storyboard タイムラインツリーを固定することはできません。」
とかいう謎の実行時エラー出るんだけどxamlで完結出来る解決策教えて
要はToプロパティを動的に計算する手段が欲しい
コードビハインドは無しで

**デフォルトの名無しさん** · 2023/01/02(月) 21:21:23.14

>>683
しかもどいつもこいつもバグだらけで無意味に制約が増えるだけというw

**デフォルトの名無しさん** · 2023/01/03(火) 15:00:31.60

>>684
まずこういう初心者から脱しよう
>コードビハインドは無しで

**デフォルトの名無しさん** · 2023/01/03(火) 15:27:36.05

要は動きゃいいんだよ。コードビハインドでもなんでも。

**デフォルトの名無しさん** · 2023/01/03(火) 20:42:50.43

どうでもいいけどGridが内部のコントロールによってでかくなるのむかつくな
ツリービューにスクロール要素つけることが出来なかった。（Gridの高さを小さめに設定すれば行けるんだがAutoや*だと無理だった）

**デフォルトの名無しさん** · 2023/01/03(火) 21:54:45.82

>>686
解決策も示せない上級者(笑)には聞いてねえよ
そらコードビハインドで書きゃなんだって出来るわな
専用スレだってのに少しは建設的なレスできるやついないの？

**デフォルトの名無しさん** · 2023/01/04(水) 18:02:44.38

WPF で Data Binding と Command を使ったアプリケーションをシンプルに書きたかった話

**デフォルトの名無しさん** · 2023/01/04(水) 18:33:50.34

Bindingは遅い

**デフォルトの名無しさん** · 2023/01/04(水) 19:39:31.67

>>684
ビヘイビア

**デフォルトの名無しさん** · 2023/01/04(水) 19:54:43.54

コードビハインドでいいよな
周りに非コードビハインド(?)でできる人が
いればその人に聞く。
いないなら自分のやりたい手法で良い。

**デフォルトの名無しさん** · 2023/01/05(木) 00:20:37.46

コードビハインド=悪

やっぱり、この思想が世の中に蔓延ってるんだよな
WPF普及の足枷よ

**デフォルトの名無しさん** · 2023/01/05(木) 07:17:48.73

WPFの高DPI(Winformsでもできるが) 画面構築とコードビハインドでも
無問題。

**デフォルトの名無しさん** · 2023/01/07(土) 19:00:12.83

添付ビヘイビアを使うときの注意点ってありますか？
なんか検索するとイベントが残るとか、メモリリークの原因になるとか不穏な情報が出てきて…

**デフォルトの名無しさん** · 2023/01/07(土) 19:04:12.35

そうならないためにどこに注意しろというところまで書いてあるから読めや
なぜそれを読み飛ばしてここでまた聞いて読み飛ばすんだ
時間の無駄だろ

**デフォルトの名無しさん** · 2023/01/07(土) 21:26:26.92

つべこべ言わずさっさと教えろや
粗チンが

**デフォルトの名無しさん** · 2023/01/07(土) 22:19:27.33

コードビハインドが悪とかそもそも誰が言い出したんだっけ？
WPF初期から使ってるがMVVMはじめてみんなコードビハインドが悪だと信じ込まされて苦しんでたの草生えたわ
そもそもユーザー定義コントロール作ろうと思ったら継承必須だからコードビハインドせざるを得ないしConverterもBehaviorもおもっくそコードビハインドなのだが当時はMVP持ってる奴等が荒唐無稽な妄想で喚き散らしてて呆れたもんだわ

**デフォルトの名無しさん** · 2023/01/07(土) 22:23:24.11

xamlの中にC#書けばコードビハインドじゃなくなるのに
誰も推奨しないのは何故だ？

**デフォルトの名無しさん** · 2023/01/08(日) 02:43:01.75

>>699
MVP野郎たちだね
一方コントロールの内部実装では
バインディング全く使われて無かった

**デフォルトの名無しさん** · 2023/01/08(日) 11:23:34.32

コントロールはバインディング提供する側だろ

**デフォルトの名無しさん** · 2023/01/08(日) 14:13:40.53

結局フレームワークが新しいものに移り気だからぜんぜん成熟しないんだよね

バインディングサポート謳うなら
view作ったらviewmodelのテンプレート生成して
標準で提供しているコントロールぐらいどのプロパティもどのイベントのコマンドもお手軽バインドできるようにして
xamlにバインド記述したとき対応してない型なら自動でconverterコード生成するぐらいしてくれないと

**デフォルトの名無しさん** · 2023/01/08(日) 14:19:29.23

C#という言語としてはしっかり進化してるだけにもったいない

**デフォルトの名無しさん** · 2023/01/08(日) 14:35:32.75

マウイキチのせいで変なやつしか残ってねえ

**デフォルトの名無しさん** · 2023/01/08(日) 14:37:21.85

おちんぽ様があればなんでもいいや🥰

**デフォルトの名無しさん** · 2023/01/08(日) 14:48:32.64

xamlが別言語並に独特すぎて覚えるのクソダルいクセにまともに使えない機能多過ぎるのがマジで終わってる
>>700が言うようにC#スクリプトでも埋め込めりゃまだマシなのにそれすら無いせいで使う側が死ぬほど面倒なコード書かなきゃならん
コードビハインドだのViewModelだのビヘイビアだの依存関係プロパティだのカスタムコントロールだの
こんな面倒なコード量産しなきゃならん時点で流行るわけねーんだわ
使えば使うほどムカついてくる素晴らしいフレームワークだよ

**デフォルトの名無しさん** · 2023/01/08(日) 15:04:32.93

Windows向けのアプリ開発するならWinFormsが一番楽なのがな

**デフォルトの名無しさん** · 2023/01/08(日) 17:58:15.70

Winforms派だけどテキトーに作っても画面が最適化されるXAMLはいい。
縦モニタあるんだが最大化したら普通にうまく表示されたし。
逆に言うとこの辺しか利点がないと思った

**デフォルトの名無しさん** · 2023/01/08(日) 19:35:19.77

>>708
それな
しかもWinUI3.0は結局WinFormsだけでUWPを切り捨てて先祖返りしてるのマジでMSが行き当たりばったりで戦略性やビジョンが皆無なのが露呈してしまった
そもそもUWPはGlobal Hook使えなかったり.NETのサブシステムで機能が足りなかったりと欠陥すぎてあえなくMS Storeが死亡してそうだ！AndroidアプリをWSAで動かせばええんや！(ピコーン)とか斜め上の解決策なのも草
俺ならとりあえずXAML捨ててUIをWinFormsだけにするけどなもうHTML5+JS(TS)に慣れた開発者がXAMLに乗り換えてくれることはワンチャンすらねーよノーチャン

**デフォルトの名無しさん** · 2023/01/08(日) 21:06:53.22

この荒ぶっている彼はxamlをあまり解っていないようだね
最近使ったこと無いのがよく分かるよ

**デフォルトの名無しさん** · 2023/01/08(日) 21:47:08.89

お前より100億倍XAMLに詳しいよｗｗｗ
そしてお前がReactもVueも触ったことないのがよく分かるｗｗｗ

**デフォルトの名無しさん** · 2023/01/08(日) 21:51:15.67

実際のところどうなのかは知らないけど

>お前より100億倍XAMLに詳しいよｗｗｗ

こんなこと書いている奴はそれだけで頭悪そうに見えるよな

**デフォルトの名無しさん** · 2023/01/08(日) 22:09:38.16

5chでよくある光景だけど人のレッテル貼りしか出来ない奴よりは
言葉悪くても具体的な意見とか主張書ける奴のが有能だよ
それでもマウイくんはちょっとどうかと思うけど

**デフォルトの名無しさん** · 2023/01/09(月) 00:05:14.55

すみません。
Viewのイベントハンドラーをコマンドで呼び出したいのですがいい方法ありますでしょうか。

以下のTreeViewがあります。このツリービューのアイテムを選択した時に発火させるためのEventHandlerがItemInvokedなのですが普段のMVVMの通り{Binding 〇〇Command}とViewModelのコマンドを呼び出すことができません。
ViewModelのコマンドを呼び出すためにはどうすればよいでしょうか。
<TreeView x:Name="boardTree"
ItemsSource="{Binding BoardSource}"
SelectedItem="{Binding SelectBoardList}"
SelectionMode="Single"
ItemInvoked="boardTree_ItemInvoked">
<TreeView.ItemTemplate>
<DataTemplate x:DataType="model:BoardList">
<TreeViewItem ItemsSource="{x:Bind Children}"
Content="{x:Bind BoardTitle}"/>
</DataTemplate>
</TreeView.ItemTemplate>
</TreeView>

因みにItemInvoked="{Binding 〇〇Command}"としたところ以下のエラーが表示されました。
XLS0523 イベント ItemInvoked はデリゲート型 TypedEventHandler`2 のプロパティのみにバインドできます。

**デフォルトの名無しさん** · 2023/01/09(月) 00:43:59.11

>> 715
Biindできるのは
TypedEventHandler<TreeView, TreeViewItemInvokedEventArgs>型のみ
Commandインターフェースは持っていない

**デフォルトの名無しさん** · 2023/01/09(月) 00:57:04.65

Trigger使えよ常識だろ
このスレはド素人しかおらんのか？ｗｗｗ

**デフォルトの名無しさん** · 2023/01/09(月) 01:24:32.51

BoardListとか書いてるからこれ作ってる5chBrowserの事でMAUI君だろこれ
初めての実践とはいえひどいなww

**.NET MAUI HighSchool** · 2023/01/09(月) 02:46:28.31

>>718
酷いと言われてもまだ経験年数6ヶ月なのですが…

**.NET MAUI HighSchool** · 2023/01/09(月) 02:47:02.73

>>717
常識なのですね
MAUIではTrigger使ったことなかったので知りませんでした

**デフォルトの名無しさん** · 2023/01/09(月) 05:15:33.29

Triggerは古いんだってWinUIで切り捨てたのに
Xamarinからの流れでMAUIで復活したような形になっちゃってる
設計思想ェ…

**デフォルトの名無しさん** · 2023/01/09(月) 05:34:49.69

コテ隠して投稿したのに一瞬でバレてるのほんま草

**デフォルトの名無しさん** · 2023/01/09(月) 09:08:07.33

マジでまともにXAML書いたことないド素人しかおらんの草ｗｗｗ
俺は大企業で数多のカスタムコントロールを作ってきたからわかるが圧倒的にHTML5+CSS+JS or JSX or Vue or Svelteの方が優れてるからXAMLを採用し続ける限りMSの言語や開発環境が人気が出て盛り上がることは100%ない

**デフォルトの名無しさん** · 2023/01/09(月) 10:05:34.91

>>709
>Winforms派だけどテキトーに作っても画面が最適化されるXAMLはいい。
「画面(GUI)が勝手に最適化」はまず不可能だと思うけどね。
そもそも、Windowsアプリは最低、1024*768の解像度が有る環境が必須と
されていた。それより狭い画面だとまともに動かない。だから、スマホだと
無理が出る。XAMLで書いてもその制限は越えられない。
スマホのタッチパネル付きの狭い縦画面(?)には、それに配慮したGUIが
必要となる。XAMLなどで自動化しようとしても完全に自動化はまず不可能。

**デフォルトの名無しさん** · 2023/01/09(月) 11:13:58.50

709だが、

>>724
そりゃ全ての環境においてうまく最適化は
されないでしょう。
高い解像度もってると意外とうまく程度。

**デフォルトの名無しさん** · 2023/01/09(月) 11:18:17.95

スマホだと、ボタンが二つ以上横に並ぶようなインターフェースは無理が有るみたいだ。
ボタンは1つずつ縦に並べる必要があるらしい。
チェックボックスのようなものも同様。
しかも、デスクトップだと
項目名1[x]　項目名2 [x]
なのに対し、スマホだと、
項目名1
　　[o-]
項目名2
　　[o-]
みたいに項目とチェックの箱を二行に分けないと画面に入らないことがある。
こんなもんまでXAMLで共通化は難しいだろう。
もしかしたらできるかもしれないが、想像力と実機での確認が必要となるだろう。

**デフォルトの名無しさん** · 2023/01/09(月) 11:27:12.03

>>724
そんな制限はないしアダプティブにもできる。

**デフォルトの名無しさん** · 2023/01/09(月) 11:29:43.14

>>727
どのみち人間が考えないと駄目だろうて。
特に、デスクトップでは1画面内に出来るだけ多くの情報があった方が便利だったり
する。それが仕事の効率を高める。
ところが、スマホだと画面が小さいから不便であろうが「認識」できることが重要となる。

**デフォルトの名無しさん** · 2023/01/09(月) 11:37:36.93

なんというか、スマホだとある意味、項目を全て一個ずつ縦に並べるという
インターフェースにしか出来ないのに対し、デスクトップは作成者の判断で
何でも出来る。
一方は1通り、他方は無限種類(作者次第)。
そういうものはXAMLで共通化しにくいだろう。

**デフォルトの名無しさん** · 2023/01/09(月) 11:41:26.32

>>729
スマホの場合、画面上での並べ方は1通りでも、タップしたときにサブ項目を出したり
するようなことが必要になるかもしれない。
それはプログラミングで行なうことになると思う。
デスクトップだとそれは不要だから、プログラムもスマホとデスクトップで
場合分けが必要になるため、XAMLで共通化なんてできそうにない。

**デフォルトの名無しさん** · 2023/01/09(月) 11:43:56.57

Windows用のamazonのKindleアプリはなんか使いにくい。
それはマウスを前提にして無いからだと思う。特に右クリックやダブルクリックに。
AdobeのPDFリーダーも、どうも、Mac風に右クリック無しに設計されているように
思える。だから使いにくい。
結局、XAMLで共通化しようとしてもこのような不便さを乗り越えることは出来ない
だろう。

**デフォルトの名無しさん** · 2023/01/09(月) 14:26:00.62

>>719
その割にはえらいマウント取ってんじゃん

**デフォルトの名無しさん** · 2023/01/09(月) 14:32:56.60

>>726
WrapPanelに全部放り込めばいい
見栄えは悪いがウィンドウサイズに応じて勝手に折り返してくれる

**デフォルトの名無しさん** · 2023/01/09(月) 14:59:33.67

>>733
見栄えが悪い段階で競争力低下につながる。
中小企業は大企業に機能の量では勝負できないので、インターフェースの
良さで勝負するしかない。

**デフォルトの名無しさん** · 2023/01/09(月) 15:04:05.50

>>726
androidだと広いタブレットとスマホの2種類用意するけどなあ。

**デフォルトの名無しさん** · 2023/01/09(月) 15:08:47.01

スマホ・タブレット・デスクトップでUIを1本化しようとしたWin8はクレイジーだなw

**デフォルトの名無しさん** · 2023/01/09(月) 15:12:42.08

そもそも論として、マイクロソフトやGoogleが用意したフレームワークのXAML
で自動化できる範囲では、彼らのソフトを上回れないだろう。
彼らは大量の予算で大量の機能を盛り込んでいるから、そこでは勝負は出来ないわけで
せめてUIだけでは上回らないと。

**デフォルトの名無しさん** · 2023/01/09(月) 15:25:12.15

>>734
必要な機能の量なんて実務で違うだけで
小・大企業は無関係。