記事"グラフィカルインタフェースX: Timeコントロール、チェックボックスコントロールのリストとテーブルのソート(ビルド6)"についてのディスカッション - ページ 4

新しいコメント
 
Anatoli Kazharski:

このようなケースをすべて再現した。これは、他の要素のコンポーネントとして使用されるすべての要素に適用されます。GUI作成 時のフォームの初期絶対座標が(1,1)より大きい場合に検出される。

次回のビルドで修正される予定です。一時的なクイックフィックスとして、(1) あなたの例か、(2) フォームを座標(1,1)で初期設定するだけでも動作します。(2)の方が、他の要素位置決めモードが散見されるかもしれないので、ベターです。

まあ、私はまだ他の位置決めモードは使っていませんが、フォームは他のフォームの座標に対して相対的に開きます。だから、このままにしておいて、あなたのアップデートを待つことにするよ。時間がかかるだろうけどね（そして、そこにはとても必要なものがあって、それがないと今は不便なんだ）。
 
任意の場所に任意のテキストを追加する要素が必要です（情報マーカーとして）。
 
Pavel Kolchin:
任意の場所に任意のテキストを追加する要素が必要です（情報マーカーとして）。

おそらくCTextLabelの ような要素が適しているのではないでしょうか？

例として、GUI X: Text Input Box, Picture Slider and Simple Controls (build 5) をご覧ください。

 

アナトリー、あなたの仕事は壮大で、私も実践してみたいと思っているのだが、いろいろなことが足かせになっている。原則的には、自分のニーズに合わせてコードを修正することは可能だが、自分でコードを作成したほうがいいだろう。

例えば、こんな悩ましいことがある。動的ウィンドウ・リサイズという考え方が生まれた。つまり、多くのウィンドウGUIインターフェースでは、ウィンドウ・サイズを変更できるようになっている。

原則として次のようなスタイルで、ウィンドウの右下隅でマウスをクリックすると、ウィンドウが希望のサイズに引っ張られ、ウィンドウが拡大縮小される。

まず試したのはウィンドウのサイズ変更である。



その結果、TAB1とTAB2についてはスケーラビリティがない。


 
Yuriy Zaytsev:

...

一般的には、ウィンドウの右下隅でマウスをクリックすると、ウィンドウが希望のサイズに引っ張られ、ウィンドウが拡大縮小されるというスタイルが発展してきた。

これについては計画があるが、いつになるかはまだ言えない。

ライブラリに提示されているすべてのコントロールを「指揮」し始めるには、まず一定のレベルまで上げなければならないということだ。現在、それらの多くは中間段階にあり、中には一時的な変形に過ぎないものもある。

ユーリイ・ザイツェフ

...

原則的には、あなたのニーズに合わせてコードを修正することができますが、おそらく自分で作ったほうがいいでしょう。

もちろん、もしあなたがライブラリーを公開したら、あなたのバージョンを見るのは面白いでしょう。

P.S.： 大きな目標は、共同作業によってより早く達成されます。)
 
Anatoli Kazharski:

計画にはあるが、いつになるかはまだ言えない。

ライブラリーに提示されているすべてのコントロールを "指揮 "し始めるには、まず一定のレベルまで引き上げなければならないということだ。今はその多くが中間段階にあり、中には一時的なオプションとして一般的なものもある。

もちろん、もし公開するのであれば、あなたのバージョンのライブラリを見てみるのも面白いだろう。

P.S. 大きな目標は、共同作業によって より早く達成される。)

これは、チームが目標を持って、結果のために働き、クールな真のリーダー（マネージャー）を必要とする場合である。

 
Yuriy Zaytsev:

チームが目標を持ち、結果を出すために働き、優れた真のリーダー（マネージャー）を必要としている場合だ。

...

マネージャーがいなくてもできる。全員が、まだ手をつけていない課題の解決に少しでも貢献すれば。

もし私が、物事を進めるためにリーダーが必要だと考えていたら、少なくともこの開発レベルでは、このライブラリーはまだ存在していなかっただろう。これでもまだ十分とは言い難いことを実感している。)

 
こんにちは。
コロンビアからよろしく。

グラフィックインターフェイスライブラリに関するあなたの仕事に対して、改めてお礼を言いたい。

正確には、それについて、私はあなたに大きなお願いをしたいのです：

ライブラリのアップデートに基づいて、私はあえていくつかのグループに分けました。
グループ1：
記事1から10-1まで、ビルド2を配信
それはまた、"古い構造 "を持つ "古いライブラリ "です。

グループ2：
それらはグループ1のライブラリへのアップデートであり、まだ "古いライブラリ "だが、"中間構造 "と呼ぶことを思いついた。
このグループ2の中には、Build3（第10-2条）、Build4（第10-3条）、Build5（第10-4条）、Build6（第10-5条）がある。

グループ3：
それらは、その「古いライブラリ」に対するより多くの更新であるが、「新しい構造」を持っている。
このグループ3には、Build7 (第10-6条)、Build8 (第10-7条)、Build9 (第10-8条)、Build10 (第10-9条と第10-10条)、Build11 (第10-11条)、Build12 (第10-12条)、Build13 (第10-13条)がある。

グループ4
ここからは、ライブラリのコアを更新したことになるので、「新ライブラリ」と呼びますが、「旧構造」です。
この中にBuild14.1と14.2（第10-14条）とBuild15（第11-15条）があります。

第5グループ
これは、"新しいライブラリ "であるが、"新しい構造 "でもあると言う更新です。
これはBuild16です (第11-16条)

グループ2以外は、それぞれのグループが独自の記事をサポートしているので、私はこの全体の要約を行いました、
Build5 (Article 10-4)に更新すると、Article 10-2をコンパイルすることができません。Build6 (Article 10-5)に更新すると、Article 10-2も、10-3も、10-4もコンパイルすることができません。

互換性がないのはおかしいと思います。そのグループには構造の変更の話はありませんし、(グループ1やグループ3にも対応していません)

どなたかファイルを「調整」して、少なくともグループ2ではすべての記事をコンパイルできるようにした方はいらっしゃいますか？
ありがとうございました。
1234
新しいコメント