★クライアントサイド最強の Delphi に物申す★

Delphi を使ってみて、ここがダメ、この方が使い易い、あるいは今後こういう機能が必要、
等々何でもいいから日頃あなたの思っていることを正直にカキコして頂戴。（初心者歓迎）
なお、Delphi 未使用者の冷やかし発言は御遠慮願います。

・JSP, ASP, PHP みたいにＨＴＭＬ埋め込み対応希望（サーバサイド開発機能の強化）
・Java のようなパッケージ仕様にしてもらいたい。
・作ったソースそのまま Kylix に持っていってもコンパイルできるように SJIS, EUCJ
　の両エンコーディング対応にしてほしい。
ちょっと大雑把で失礼。まだ他にもたくさんあるけど睡魔が．．．

Delphi.NETがあればいいんでないの。

大野さんは見ているの？

>>1の存在そのものが冷やかしなんじゃないの？

>>5
うるせーよ。氏ね。
おもしろいと思ってんの？

6=大野元久

釣れた！！！

7=安藤由男

大野って誰？

Delphi関係の人って、どうしてこうポコポコとスレ立てたがるの？

>>11
だって<以下自粛>

スレがたくさんあると、どこにレスつけたか忘れるぽこ〜。

Delphiの付くスレッド全部消去してはどう？

>2 ＨＴＭＬ埋め込み対応希望

欲しけりゃ作ればいいじゃん　Pascalスタイルのスクリプトソースは
ごろごろ転がってるだろに

＞Java のようなパッケージ仕様
　DLLでいいんじゃないの？

.NETに統合されることで最強になると思うんですが。

＞無意味な長文投稿や仕切り屋が

　　　　　　　　　　∧ ∧
　　　　　　　　 Σ(,,ﾟДﾟ)
　　　　　　　　　　/　｜ 　　ｿﾚ ｵﾚ ﾉ ｺﾄ ｼﾞｬﾝ
　　　　　　,, ,,,, 　（＿,ﾉ　,,, ,　,,
　　　　　　　　　　ノ ,,

　　　　9末の決算前でみんな忙しいかも。

>>11
Delphi厨つぶし野郎の陰謀だよ。
VBがどうのこうのってスレ立ててるやつとたぶん一緒・・・

　　　　　　昇天
　　∩　　　∩＿ 　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
〜⊂￣￣ (｡Д｡)⊃ ＜　誤爆りました・・・
　￣￣￣￣∨∨￣￣|＼＿＿＿＿＿＿＿＿＿＿＿＿＿

　　ｱ・ｱﾎﾞｰﾝ ｼﾃｵｲﾃ ﾁｮｰﾀﾞｲ

Delphi.NETはまだですか？

C#に改名しましたが？

Java&C# メモリの解放はコンパイラが自動化する。
C++ メモリの解放はプログラマ次第で自動化できる。
Delphi メモリの解放を自動化することは不可能。

Delphi UNIT
Modula-2 モジュール
JAVA　パッケージ

って同じようなもんじゃないのかな？

>>22
それってマジ？
Delphi.NETが最後の希望の光だと思うんだけど・・・

不可能じゃないと思うよ。

　どっちにしてもスクリプト的（動的にコンパイルするかインタプリタになるかは判らんけど）
に使いたいという事なら
.Create スタイルの生成は禁止して　interfaceスタイルにすりゃいいんじゃないの？

関連レス↓
http://mentai.2ch.net/test/read.cgi?bbs=bsoft&key=998629435&st=30&to=31

一人の天才がすべてを作っていると？

TurboPascal は Pascal では書かれていないし（フルアセンブラ）
カーンはアセンブラは書けない。
カーンはコンセプトマンで、それは「すべてオンメモリで処理しろ」
ただそれだけ。

ヘジは最後まで Windows と UNIX が嫌いだった。
Wizard C の開発部隊ごとカーンが買って TurboC が大好評の裏に
干されかけた Pascal 部隊の起死回生の一発が Delphi。

厳密にはノベルの Netware 用開発ツールだったんだが、ノベルからいろんな
技術を分捕って形作ったのが旧称 AppBuilder / Delphi 1.0 だ。

Delphi がヒットしたのは VB が慢心していたから。というのが社内の評価。
特に日本では、VB 3 - 4 のころ MS の方がごたごたしていてうまいこと
くらいつけたという部分がある。

TVision の経験から OWL で発明された、ウィンドウハンドルにオブジェクトの
ハンドルを関連付け、VMT インデックスにウィンドウメッセージを直接マップする
という MFC にも影響を与えた技法を作ったのはヘジでもカーンでもない。

ほんとの天才は表には出てこない。アメリカなら特にヘッドハンターに狙われちゃうもんね。
カーンはしょうがないけどヘジが表に出てきた。ってのは彼がボーランドに
いづらくなった。ということなんだよ。どんな天才にも得意/不得意はあるしね。
人間関係もかかわるし。日本でインタビュー受けるような状態になったら終わり。
彼は結局 TurboPascal のヘジでしかなかった。

それが証拠に、C# はどこまでも Delphi/ObjectPASCAL だろ？

あれが似ているということが、彼の能力の限界があそこなのだ。ということだ。

>それってマジ？ Delphi.NETが最後の希望の光だと思うんだけど・・・

↑ブビ坊の意見かもしれんが、逆。MSにとって、.Netが最後の希望の光。

.NET非依存の C#開発ツール出してくれ＞某

>>15

>>2 ＨＴＭＬ埋め込み対応希望
>欲しけりゃ作ればいいじゃん　Pascalスタイルのスクリプトソースは
>ごろごろ転がってるだろに
おれが今まで作ったライブラリ資産使えないだろう。
そもそも JBuilder のようにＩＤＥ内でデバッグできないとだめだ。

埋め込みDelphi(Pascal)って合いそうじゃない。
コンパイル激速だし、おまけにネイティブコードで実行できるから。

>＞Java のようなパッケージ仕様
>　DLLでいいんじゃないの？
DLL とか jar とかの問題じゃなくてクラス名とかがぶつからないように
名前空間機構を導入してほしいということ。
よくコンポーネント登録するときとか同じ名前のやつが既に登録されてると
登録できないじゃない。わざわざ名前変えたりしてさめんどうじゃーないの。

>>22
またまたあ（藁

>.NET非依存の C#開発ツール出してくれ＞某

こんな中途半端なものより、Kylix for 「オープンソース版.Netクローン」のが良いじゃん。

VC++のエディタみたいに自動で段落がずれるようになってほしい。

>>22
Stringってどうしてんだよ。

.NET 好きが多いけどみんなはＭＳ派かい？
おれは Delphi の .NET化に興味なし。
.NET したければ C# 使えばいいことだよ。

>.NET 好きが多いけどみんなはＭＳ派かい？

このスレはブビ坊のネタスレ。必死にDelの悪いところを探してこういう話題になってる。
でもブビ坊は触ったことない.NETをほんとに好きかもしれない。

　　　 ∧ ∧　　　／>>22
　　∩(,,ﾟДﾟ)　＜　　ガベコレのことでしょ？C++で出来るの？
⊂,,⌒　,,つつ.　　＼Javaでもガベコレに頼ると
　　￣￣ 　　　　　　　　　　　　結局動作が遅くてｲﾔだという噂もありますが…
　　　 ∧ ∧　　　／￣
　　∩(,,ﾟДﾟ)　＜　　確かにDelphiスクリプトは標準であったらﾍﾞﾝﾘ。
⊂,,⌒　,,つつ.　　＼　是非に。Borlandに真剣になってもらいたー
　　￣￣ 　
　　　∧∧　　　／＞名前空間機構を導入してほしいということ。
〜''~（,,ﾟДﾟ）　＜　欲しい欲しい
　 UU'UU　　　 ＼
　　　∧∧　　　／＞.NET したければ C# 使えばいいことだよ。
〜''~（,,ﾟДﾟ）　＜　つまりJavaを使えと・・・
　 UU'UU　　　 ＼いうことですか....

>>38
確かにC++にはガベコレはない。
しかしプログラマに実力さえあれば、粘着質のように究極の安全性を追求できる。

ところがDelphiではそれはできない。
C++Builderではどんな巨大なプログラムでもdeleteを使わずに済むよう配慮する余地がある。
（もし使う場面があっても、完全に隠蔽して表の世界から遮断できる）
だからC++の実力者は__finallyなんて使わない（後かたづけするものがないから）。
しかしDelphiでFreeを使わないようにすることはできない。
finallyが必要なのは、オブジェクトパスカルの完成度の低さを証明している。
例えば、例外発生時にfinallyで処理する必要がないようにクラスを整理する方法がない。

>>22
アセンブラで書かれているようだけど？

>>22ではなく>>35の間違い。

>確かにC++にはガベコレはない。
>しかしプログラマに実力さえあれば、粘着質のように究極の安全性を追求できる。

finallyの方が究極の安全性がある。オブジェクトの開放順番も自由。
さらにC++ではコンストラクタ、デストラクタのオーバーライドも不自由である。

念のためだけど、deleteがあること位知ってるからね。

C++では、finallyの記述が一貫してないから非常に困るな。
WinとLinuxとクロス出来ないね。出来るんだったら方法教えて欲しい。

>>41
>finallyの方が究極の安全性がある。

function TImage.GetCanvas: TCanvas;
var
　Bitmap: TBitmap;
begin
if Picture.Graphic = nil then
begin
Bitmap := TBitmap.Create;
try
Bitmap.Width := Width;
Bitmap.Height := Height;
Picture.Graphic := Bitmap;
finally
Bitmap.Free;
end;
end;
end;

TCanvas TImage::GetCanvas()
{
　if (!Picture->Graphic)
　{
　　auto_ptr<TBitmap> Bitmap(new TBitmap);
　　Bitmap->Width = Width;
　　Bitmap->Height = Height;
　　Picture->Graphic = Bitmap.get();
　}
}

どっちのほうが安全だと思う？

配慮といういうは、使う側の人間がするより、用意する側の人間がする方がいいに決まっている。
コンパイラが配慮するのが最も優れており、次に優れているのはライブラリ制作者が配慮すること。
ライブラリのユーザーが配慮しなければならないのは優れているとは言えない。

finallyはユーザーが安全性を与えなければならない。
C++は、クラスの使用者がfinallyを書かなくて済むように配慮できる。

でも俺がVCLの作者なら、以下のように書けるようにするけどね。

TCanvas TImage::GetCanvas()
{
　if (!Picture->Graphic)
　{
　　TBitmap Bitmap;
　　Bitmap.Width = Width;
　　Bitmap.Height = Height;
　　Picture->Graphic = Bitmap;
　}
}

http://www2.big.or.jp/~osamu/Delphi/delphi-browse.cgi?index=041720
　 ∧ ∧　 　 ／
　 (,,ﾟДﾟ)　 ＜　　ﾅｶﾑﾗ先生ﾀﾝもがんばっておられるようです。
　 |⊃ ,⊃　　 ＼　解決してるのかな。このスレッド…
＠|　　| 　　　　　　ﾀﾞﾚｶ(奥)サマリーつくってくれ
　 ∪∪
　　これだけガベコレが流行るんだから。Delもなんとかして欲しい。

>>39
interface知らない？

あとはそうだね、やろうと思えばコンポーネント風に
クラスの開放を全部アプリケーションにまかせるとか。

他にauto_ptrもどきの実装もできるし、手段はいろいろあるよ。

勉強不足を言語のせいにするのはハズかしいぞ。

よく考えたらコンポーネントは自分で開放してないね。

>>44
これもおもしろいな
http://leed.issp.u-tokyo.ac.jp/~takeuchi/delphi/browse.cgi?index=041732

BDE はもういらないんじゃないかい。
いまどき Paradox も dBASE もしないだろうに。
それより BDE 経由しない ODBC の TDataSet がほしいな。
極力余計なライタイム不要な方向にしてくれ。＞某

>クライアントサイド最強の Delphi
ハァ？

>>49
ほっとけ。隔離スレの意味がなくなる。

>>47のリンク先より引用

> 使用例
> 使用したオブジェクトを自動破棄する。
> type
>　 TXXObject = class(XXXX)
>　　 :
>　 end;
>
> procedure TForm1.XXXXXX(Sender: TObject);
> var Obj: TXXObject;
>　　 AutoObjRef: IAutoObjRef;
> begin
>　 Obj := TXXObject.Create(.....);
>　 AutoObjRef := TAutoObjRef.Create(Obj);
>　　 :
> end; // ここで Obj は自動破棄される。
>
> 使用した　レコードを自動破棄する
> type
>　 TXXRecord = record
>　　 str: string;
>　　 :
>　 end;
>
> procedure TForm1.Timer1Timer(Sender: TObject);
> var pRecord: ^TXXRecord;
>　　 AutoPtr: IAutoPtr;
> begin
>　 New(pRecord);
>　 AutoPtr := TAutoPtr.Create(pRecord, TypeInfo(TXXRecord));
>　　 :
> end;　//　ここで　レコードが自動破棄される
>
> ＃レコードだけでなく、^String や ^動的配列 の自動破棄も
> ＃できます(^^

つまり、>>39>>43さん。よろしかったでしょうか？

>確かにC++にはガベコレはない。
>しかしプログラマに実力さえあれば、粘着質のように究極の安全性を追求できる。

Delphiでも出来るようです。

￣￣￣∨￣￣￣￣￣
　　　∧ ∧ 　　　ｽｹﾞｰ
　　　(,, ﾟДﾟ)∫
　　　/　 つ旦O 　ｶｸﾘ ｽﾚ ﾅﾉ?
　〜（__ｎ ｎ［￣￣￣.］
　　　　　　　 ￣￣￣
　もっとワクワクするネタくださいな。
クライアントサイドならC＃にも負けないよ
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1001489683

　隔離スレを利用して最強をｱﾋﾟｰﾙしとこかー。

http://www.f2.dion.ne.jp/~impact14/

デフォルトの名無しさんがデルファイの名無しさんに見える

Delphi for .NETとか言ってる奴は単にDelphiのIDEがタコなんで
MSのIDEが使いたいだけに一票
素直にC#に移行するのが後々楽だと思うが

>Delphi for .NETとか言ってる奴は単にDelphiのIDEがタコなんで
Ver.Up するたびに Delphi IDE のウィンドウが増えてきてて
ＸＧＡじゃ見づらくなってるからそろそろＩＤＥのモデルチェンジを
してもらいたいね。
だからといって別にＣ＃をしたいとは思ってないが。

正直ネエィティブコンパイルさえしてくれれば俺はC#にうつるぞ。

>>55
・・・

クライアントサイド最強なんてのは実績を残してから言え

OS の威光だけで生き残っているバカ言語。とっととくたばれ。

>>58
VBのことかな？(ﾌﾟ

For I = 1 to 10
って書いたときのエラーメッセージが
[for 文の制御変数はローカル変数でなければなりません]
ってのはどうにかしてもらいたい。

ほかに似たようなのある？

デファイルは糞

Rubyの次はDelphiか。。。

>60
ワーニングじゃなかったかな？
コンパイルは可能。
でも、なんで出るのでしょうかねぇ〜？

>>63
うぅ。分かってもらえない。
For I := 1 to 10
が正解。腹が立っているのは，:= と = を打ち間違えた事を指摘してくれないから。
(I = 1) という論理型の式がある。と判断して（これは正しいんだけど）
意味不明のエラーをだしちゃう。それが嫌。

本当だ。 I がローカル変数でも、
[for 文の制御変数はローカル変数でなければなりません]
って出ますね。

ヘルプにはこうあったよ！

このエラーは，制御変数が来るべきところに構文エラーがあるときにも表示されます。
たとえば以下のように，i := 0 でなければならないところを書き間違えた場合などです。

for i = 1 to 100 do
begin
end

正直、WindowsのDelphiはもういいから
kylixネタを頼むよ。

KylixはDelphiとの互換性なんて無視すればよかったのに。

まずは勘違いCUI厨房の啓蒙活動からやらないと勝ち目ないかも>Kylix

どのあたりの互換性が悪いの？>>68

>勝ち目ないかも>Kylix
LinuxではC/C++が強いってこと？

>>70
互換性を考えずに理想を追求して欲しかったということでは。
確かにコンポーネントをinterface化して欲しかった。

>>69
啓蒙活動はしなくても、kylixでできたアプリが普及してくれば、
勝手にパラダイムシフトが訪れるでしょう。
Windowsみたいに他のライバルがないし。

そんなことより、PPC版やSH版やMIPS版も開発して欲しい…。

Linuxの開発環境って教えて欲しいな。
まさか、標準で入っているccコマンド（確か、k&r）で開発なんかしないよＮＥ？

Delphi 使い）
・チャレンジ精神旺盛な人たち
・利用者のスキルレベルは低〜高までさまざま
・主に個人的ユーザが多く熱狂的なコミュニティが構築されている

BCB 使い）
・Delphi との両刀使い（昔はC/C++をやっていて人と思われる）
・Delphi がいいけど ObjectPascal はちょっと...と思っている人たち

VB 使い）
・利用者のスキルレベルは低がほとんど
・作ったソフトの品質は気にしない
・Microsoft 製品じゃないとだめと考える保守的な人が多い

VC 使い）
・利用者のスキルレベルは中〜高
・とにかくコードをしこしこ書くのが好き
・Microsoft 製品じゃないとだめと考える保守的な人も多い（特に仕事において）

>>72
ccつーかgcc。だけど開発環境と言うか言語だわな。

gccなのか。画面ツールとか何使うんだろう。リソースファイル手書きですか？

>>75
普通は全部手書き。
Gtk+ 用の RAD ツールとして glade というのはある。
X-Windowアプリのリソースファイルは手書きで十分。

それって、リソースバリバリのDelphiアプリに見劣りしないの？>>76
それとも、Linux使う時点で、画面に期待されてないとか。
でも、Linuxでもoffice互換ソフトとかあるんだよねぇ。star officeだっけ。

なぜ、GUIをリソースファイルを使って書く方が優れると考える？

リソースファイルの方が劣るよ。
Delphiはリソースファイルじゃなくて、独自dfm形式だよ。
リソース（標準コントロール＆独自コンポーネント）を
バリバリに使っているって意味。

>79
なら、ますます77の意味が分からない。
Kylixの標準（GUI）コンポーネントってQtのウィジェットらしいが、
（http://nsw.nikkeibp.co.jp/nsw/newsshow2.asp?ID=77）
viでソース書いてg++でコンパイルしてQtのウィジェット並べるのと、
KylixのGUIでQtのウィジェット並べるので差異がでるの？

解釈1：リソース＝資源一般
解釈2：リソース＝Windowsのリソースファイル

＞リソースバリバリのDelphi
？
確かにDelphiでもリソースは使われているが(アイコン等)・・・
バリバリ？

素直に読んでね>>81

リソース＝Windowsのリソース
リソースファイル＝Windowsのリソースを定義したリソースファイル

リソースファイルであろうと、DFM形式であろうと、
実行時はAPIコールなんだから実質同じ>>80

ただ、画面にペタペタはってバリバリ作るのと、
viでリソースファイルをしこしこ作るのでは、出来上がるものが違うでしょ。

>>83
出来上がるものは同じだよ。TMTOWTDI!
かかる手間が違うだけ :-)

>>84
手間がかからないほうが、よりよいインターフェイスのために試行錯誤したり、
適切な仕様変更を施したりすることが気軽になって、
完成度が上がるんじゃないか？

linuxの窮状を見るに、その通りじゃないかと思うけどね。
適切な仕様変更なのに面倒だからと受け入れなかったり、
もっといいレイアウトがあるかもしれないのに「これでいいや」と妥協したりしてないか？

　　∧∧ 　　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　(,,ﾟДﾟ)　　＜ ぷっはー。
　ヽ/つ且~~　　＼＿＿＿＿＿＿＿＿＿＿＿
　 （__　_）

>>352さん情報サンクス

>>341のコードのListBox1.Items.Addの前に2行追加してみました。

　　　　EventLogDateTime := EncodeDate(1970, 1, 1) + (pevlr^.TimeWritten / 86400);
　　　　S := DateTimeToStr(EventLogDateTime) + '|' + S;

　　　　ListBox1.Items.Add(S);

あっているのだろうか・・
NTEventLogの掃き方がどうも変なんだよなー。
あきらめておくのが正解かもね。

　　　 　 　 ∧ ∧ 　／￣￣￣￣￣￣￣￣￣￣￣￣
〜′￣￣(;TДT)＜　また書き間違えた。ゴメン
　 UU￣￣ U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　モウアキラメヨ…

パッケージファイル内で{$IFDEF} を使えるようにして欲しい。

BDEをアップデートしたらInstall Shieldのisdepend.iniや
swdepend.iniのどのエントリをいじれば良いかの技術情報
を公開してくれんかのう。複数バージョンを単一マシンで使ってる
身としては結構切実なんじゃ。

イベントログを自分のソフトから読む需要なんてほとんどあるとは思えないなあ。
イベントビューアで見ればいいだけだし。
イベントログに書き出すほうならサーバ系なら普通に使うだろうが。

旧バージョンをダウソして実行してみたけどバージョンは戻らないな・・・
鬱です。

　　　 　 　 ∧ ∧ 　／￣￣￣￣￣￣￣￣￣￣￣￣
〜′￣￣(；ﾟДﾟ)＜　イヤ・アノ・ソノ・・・>>90
　 UU￣￣ U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　純粋にこのページでやってることをパクってみたかっただけなんです、、
　　http://www.atmarkit.co.jp/fdotnet/csharptips/002anchor/002anchor.html

　　このｻｲﾄ書いた人に"イベントログなんて読む必要ねーんじゃ(ﾟДﾟ)ｺﾞﾙｧ"って
　　逝ったほうがいいでしょうか....たちのわるい読者になてしまいそうです。

Del6.Delphi初めて使ってみたけどおもしろーい。
C++直接通るならイカスぜ。

>C++直接通るならイカスぜ。
え、C++コードは通らないＺＯ！

>>93
それはBuilder

取り合えずBDEINST.CABからBDEINST.DLLを取り出して
TREGSVR.EXEと同じフォルダに入れ、バッチで、

TREGSVR -q BDEINST.DLL

インストーラで失敗したときに実行するようにしました。

>>94 >>95
いや、直接通る'なら'イカスんだから、
通らないDelは糞、これ、定説。

その意見が糞というのはあり得ないのか？>>97

>>98
あたりまえでしょ

>>97
BCB に Obj.Pacal コンパイラが搭載されてるように
Del にも C++コンパイラが搭載されていればうれしいが、
処理が重くなるのはやだっ。

Delphi.NETはまだですか？
出たら触るつもり。

今度はDelphiでvisioのようなものを作らなければ
ならなくなりました。
（回路図を書きたいんですが・・・）
・絵を貼り付けたり・・・
　（コンポーネントをフォームに貼り付けるように）
・貼り付けた絵を線で結んだり・・・
　（その線は絵にくっついていて絵を動かすと線も
　　ついてくる。）
等など色々あるのですが、まったく何をどうすれば
このような物ができるか分かりません。

まずはvisioのように絵を貼り付けるにはどうしたら
いいのか皆さんに力を貸してもらえないでしょうか？
かなり本気で困っています。(T_T)

よろしくお願い致します。m(__)m

以上

>>102
素直にvisioを使えとクライアントに言え。
図を編集してデータを出力するようなことをしたければ、
visio+VBAを使え。

で，ケイスケの勤める会社。
http://www.land-grp.co.jp/trip.html

コンテナでVisioを埋め込むとか
http://www.devexpress.com/products/vcl/product.asp?ProdID=12
を参考にするとか
線だけならFree

>>101
.NET 対応化を望む理由を教えてくれ？
.NET 化すると
(1) VB, C# などから Delphi で作ったクラス等を使えるようになる
(2) (1) の逆
このくらいだと思うが、おれには得に便利になるわけではない。
それともほかに何か理由があるのかい？

あのさ，
>.NET 化すると
>(1) VB, C# などから Delphi で作ったクラス等を使えるようになる
>(2) (1) の逆
これができるといっている，論拠は何？

それが.NETとういう物なんだよ

1 の提案に戻って、Delphi6 のバグでもまとめないか？

アップデートは撤回されたようだが日本でも以下のようにテスターの
募集が始まっている。

（公人の公開された空間での発言だから転載してもいいだろう）

“ボーランドの”大野です。
というわけで、ちょっと仕事にからんだメッセージで恐縮です^_^;
このパッチについて、すでに日本語版の作成に取り掛かっています。
米国のサイトで案内されているバリアント関連の問題については
そのままなのですが、このレベルのものを日本語版でお試しになりたい方は
いらっしゃるでしょうか。（サイズは 20MB 弱くらいになると思います）
ご興味のある方は [email protected] まで直接ご連絡ください。

さぁ。みんなでメールを出そう。

がんばれ人柱。

>>102
げ某MLにも同じ質問が．．．

既知だと思うがプロパティエディタで Proxies ユニットがなくて
コンパイルできんぞ。（DesignEditors.pas で uses している。）
いつも思うことだけどバージョンアップするたびにバグのレベルが
ひどくなってるよなー。
ちゃんとチェックすればファイルが足りないことは明白のはずだが
完全に手抜きしているな。＞某
Ver.5 のときのプロパティエディタのユニット名とか変更しておき
ながらヘルプにもその旨が載ってないしな。
後でアップデートパック出すからじゃ遅いんだよ。
製品出荷することにもっと責任を持ってくれ！！！＞某

>>111
MLからだれかコピペしただけかと。

厨プログラマたたきはマ板でやってくれ。たのむから

Delphi1が一番美しい。

>Delphi1が一番美しい。
そうだね。一番完成度が高かった印象がある。
Win3.1で唯一無二の最高作だよ。
もう一度初心に返ってもらいたいものだ。＞某

>>112
今度のはCLXの関係で特にひどそう
でもアメリカでは許容範囲かもね

>>112
Proxies ユニットが無くなったのは Delphi4 から。2/3 との互換性を考えて
ソース/ユニットが提供されていたのにガイドラインに従わずにいたコンポーネント作者の
怠慢は問わないのか？

・起動に時間が掛かり過ぎ。（Ver.Upのだびに遅くなってく感じ。）
・.exe ファイルでかくなりすぎ。（Ver.Upのだびにでかくなってる。）
・ObjectInspector にプロパティ、イベントが多くなりすぎで
　なんとか使い易くしてもらいたい。

毎々増えてく機能をすべてベースコンポーネントに詰め込んでるけど、
これらを interface にして外に出してせばいいじゃない。
Ｄ＆Ｄやドッキングなどは使わないケースがほとんどだからベースクラスから
切り離してもらいたい。
そのとき作りたいアプリに必要な機能だけ interface を実装するように
すれば多少 .exe サイズが小さくなるんじゃないの。

>>117
>Proxies ユニットが無くなったのは Delphi4 から。2/3 との互換性を考えて
実際このユニットファイルがないとコンパイルできんぞ。

ドッキングなんかは、コンポーネントにして欲しかった。
フォームにドッキングコンポを載せると、フォームがドッキング可能になる。

>そのとき作りたいアプリに必要な機能だけ interface を実装するように
委譲モデルにした方がいいか。

ＩＤＥとコンパイラ＋ＶＣＬを分離するとどうなるの？

>>120
たしかにそう思うけどそれだとドッキング対象がフォームのみになっちゃうよね。
ＤＢコンポの TDataSet系, TDataSource みたいな感じにすればいいと思うよ。
例えば、
ドッキング元：TDockSource
ドッキング先：TDockSite
みたいなコンポーネントがあってフォームや各種ビジュアルコンポーネントと
関連付けさせるようにしておけばいいと思うよ。
そうすればプロパティやイベントの分散されてObjectInspector に表示する量
も少なくなるしね。

>>122
>ＩＤＥとコンパイラ＋ＶＣＬを分離するとどうなるの？
言ってる意味がわからないんだけど。
ＩＤＥあってのＶＣＬでしょ。
ＩＤＥがなければＶＣＬの意味がない。

>124
Delphi6のIDEでDelphi3で開発していたプロジェクトを
コンパイルしたいわけです。
VCLやコンパイルをバージョンアップすると、あらたなバグが
潜む可能性があるからねっ！

Delphi7にDelphi1〜Delphi7までのVCLとコンパイラを内臓
していればいい。

コンパイラの最新機能がＶＣＬで使われるから、
ＶＣＬとコンパイラの分離は無理だと思う。

>>125
>Delphi6のIDEでDelphi3で開発していたプロジェクトを
>コンパイルしたいわけです。
>VCLやコンパイルをバージョンアップすると、あらたなバグが
>潜む可能性があるからねっ！
それならばそのプロジェクトだけ Delphi3 でやる続けるか、
Delphi6 用に調整するしかないんじゃないの。それはしょうがないよ。
仮に Delphi3コンパイラ + Delphi6VCL の組み合わせが可能でも
当然コンパイルエラーになるから意味ないじゃん。

>Delphi7にDelphi1〜Delphi7までのVCLとコンパイラを内臓
>していればいい。
それよりすべてのバージョン互いに干渉しないように同一ＰＣ内に
同居できるようになった方がいいと思うが。

>126
>Delphi3コンパイラ + Delphi6VCL の組み合わせ
IDEと(コンパイラ+VCL)の組み合わせです。

Delphi3で開発していたプロジェクトをバージョンアップを、
最新の開発環境(IDE)で行いたいのです。

>>127
納得。
ＩＤＥだけ最新もの（拡張されたいろんな機能）を使いたいということだね。
そうなれば JBuilder みたいだね。JBuilder は JDK バージョンを切り換えられるから。

127の訂正：プロジェクトを→プロジェクトの

>128
そうです。 でも、重くなるのは嫌！
VCLはもういっぱいいっぱい。

>>126
>それよりすべてのバージョン互いに干渉しないように同一ＰＣ内に
>同居できるようになった方がいいと思うが。

できるよね？

さっき気が付いたんだけど、Delphiについてくるアイコンとかの
イメージファイルがWindows3.1の頃から変わってなかったよ。
そろそろ更新したほうがいいとおもう。
アイコン作る暇ないとか、そういうときに標準の画像があると便利っていう人は多そう。
標準（エクスプローラとかオフィスとか）の画像はMSの著作物だから無理なのかな。

>>126
前に、Delphi1〜Delphi5まで一緒のPC(OS)に入れていたよ。
Delphi3は入れなかったけど（3.1は入れた）
全部ちゃんと動いていたよ。
この前、OS入れ替えたので、今はDelphi6しか入ってない。
＃ﾎﾞﾗﾝﾄﾞってバージョンアップしても前の製品のライセンス消えないよね？

>>106
>.NET 化すると
>(1) VB, C# などから Delphi で作ったクラス等を使えるようになる
>(2) (1) の逆
>このくらいだと思うが、おれには得に便利になるわけではない。
>それともほかに何か理由があるのかい？

それだけで十分だと思うんだけど・・・
それぞれで作ったコンポーネントが、再コンパイルや改変なしに
相互利用できるというのは、素晴らしいことだと思うのですが。

その世界で閉じちゃってる(あるいは、ヒキコモリたい)
人たちには分かんないかなぁ。

>それぞれで作ったコンポーネントが、再コンパイルや改変なしに
>相互利用できる

それがほんとにできたらね。けど同じ宣伝文句で ActiveX コントロールってのが
あったけど，本流にはならずに終わってしまったよね。

Delphiスレはどんなものであっても長続きするのか？

オレはむしろC#-.netがほしい・・・
それかBorland C# Builder(藁

MS製品の中核が.Netに移行する以上はいずれ対応する日がやってくるんじゃないかな？
どっちにしろ、今はDel使うからイイや。当分OSもWin2kで行くつもりだし。

>>130,>>132
以前複数Ver.入れて使ってたときどっちかのコンポーネントパレットの中身がすべて消えたことあったよ。
特殊なことをしたわけじゃないのに。
古いVer.のやつを新しいVer.のより後にインストールしたり、任意のVerを自由にアンイストールしたりしても
それぞれのVer.が完全に独立していればいいけど、現に問題があったから。

>>134
もしかして、ActiveXと呼ばれていたもののうち、
実際に何がどれくらい使われているか知らないのかな？

閉鎖的コミュニティではおかしな発言が正当化されやすいから、
気をつけたほうがいいですよ。

>>136
C# 使いたければ VisualStudio.NET でいいんじゃない。
Delphiライクにフォームにコンポを貼り付けてアプリ作れると思うから、
わざわざ Borland が同じようなものを作る必要はないと思うけど。

>140
136がいってるのはネイティブコードにコンパイルできるC#ってことじゃないの？

>>141
出来るに越したことはないが。
それならば Delphi 同様余計なランタイムがいらない .exe ファイルのみでも
ＯＫにしてもらいたいが、無理のような気がする。

>>140
>>136 じゃないがWindows & Linux対応のC# Builder求む。
Delphi & Kylixと同じようなもの。
Javaほど遅くないからネイティブにはこだわらない。
別にそうであってもいいが。

エンドユーザーアプリならネイティブにする必要ないじゃん。

Delphi のよいところは軽量コンポをサポートしているところ。
（軽量コンポ = TGraphicControlのサブクラス）
重量コンポと同様に扱えるようなしくみにした点には脱帽。
ということでＶＣＬ最高！

>エンドユーザーアプリならネイティブにする必要ないじゃん。
遅いより速い方がいいでしょう。

バグがなく仕様が完全に満たされているか、
インラインアセンブラが使えるか、どっちか満たしていればいいや。
じゃないとゲームに使えん。

>>145
軽量コンポーネント、フォーカスをもてないのがちとつらい。

>>147
Delでゲーム作る？正気か？

>>149
またそうやって脊髄反射で書き込みをするぅ。

>>149
ああ、Delじゃないよ
ネイティブだとかC#だとか言う話に対してのレス。
正直糞以外の言語なら何でも良いんで、ライブラリにバグが無いか、
もしバグがあるなら自分で作るからインラインアセンブラ使わせてくれればね。

最初からマシンコードで書けば良いだけの話

>>149
作ってた人はいたけどね。未完のままサイトが閉鎖されたけど。

>>147
Del用のDirectXコンポ使えば。
今どきアセンブラでゲーム作ろうとしてるやつはアホだぞ。

(！！ 154 はアホなので無視してください！！)

　　　　　　　　　∩
　　　　　　　　 //
　　　　　　　　//
　　　　　　　　|:| Λ＿Λ　　／￣￣￣￣￣
　　　　　　　　|:|（　´Α｀）＜　うるせー馬鹿！
　　　　　　　　|:|_）:∵:（ 　　＼＿＿＿＿＿
　　　　　　　　＼:∵:∴:＼
　　　　　　　　　 |∴:∵ ｌ::|
　　　　　　　　　 |∵:∴ |::|
　　　　　　　　　/∴:∵/|::|
　　　　　　　　　|ii;∵;i/　|:|
　　　　　　　　　|llll||lll|　 U
　　　　　　　　　|llll||lll|
　　　　　　　 　/ll/ |ll|
　　　　　　　　/l/ 　|ll|
　　　　　　　 /l/　　|ll|
　　　　　　 /l/　　　|ll|
　　　　　　ν　　　 ν

>>149
スミマセンそれオレです

ＤＢエクスプローラについて）

Delphi IDE から起動した場合はフィールドをフォームにドラッグ＆ドロップできるが、
別プロセスとして起動した場合にはできないのは不便だ。ＯＬＥドラッグ＆ドロップで
実現するようにしてもらいたい。

デルファイのエディタで、検索を行うときに、Shift + F3 で逆方向へ検索してほしいな。

C++Builderと一本化しちゃえばいいのに。どうせVCLは
パスカルだし今後のLinux進出考えればC++のがUNIX系の
歴史的に有利だし。デフォで生成されるコードをパスカルに
するかC++を選べるようにとかしてさぁ。。。

今後を考えればC++はないだろ。C#/Javaっぽいのが良い
ぃぬ厨がより高級な言語を理解できるとも思えんが

>>160
でもC++とDelphiのコンパイル・ビルド速度が愕然とするほど違うんだよなあ。
(Delphiのほうがはるかに速い)
両方やるとC++がつらい…

>>162
おれCやC++の膨大な資料を活かしたくて最近BC++5.5.1
ゲットしたす。開発効率のDelphiか、資産のC++か。
なんかDelphi持っててC++Builderも買う気もせんし。

>>161
C#はどうだろ？モノは良くともMSしかやらなそうだもんなぁ。
Red hatパッケージにでも入らん限りBorlandは黙殺だろ。
JavaもLinuxブレイク以前はアンチMSの支持集めてたけど
今はimodeくらいしかパッとせんし。

Ｃ＃Ｂｕｉｌｄｅｒが欲しい

DelphiとC++Builderを１パッケージにするなら賛成

仮に Borland が C#Builder を作ったとしよう。
Delphi, C++Builder 同様、ネイティブコードも吐き出せるようにしたとする。
そうなると今後 Delphi, C++Builder が売れなくなるだろう。
一番よい方法はそれぞれが単体でなくひとつに統合すればよいなと思う。
そうすると価格が上がり買われなくなるから、基本統合環境にアドインする
方法でもよい。
Delphi で開発した既存の資産も利用できるようにしないとダメ。

なんでBorlandはPascalを拡張してdelphiにしたのか、いまだに謎。
１パスでコンパイル速い以外に、なにか理由あんの？

>なんでBorlandはPascalを拡張してdelphiにしたのか、いまだに謎。
>１パスでコンパイル速い以外に、なにか理由あんの？
純粋 Pascal ってクラスとか使えないでしょ？

まあC/C++厨房はMFCであがいてなさいってこった。

>>169
いや、だからなんでPascalなの？って事

>>171
Delphiに関しては、Turbo Pascalっていうブランドがあったから。
ブランドで売れると。

Turbo PascalがなんでPascalかってのは、その開発当時はまだ
Pascalは結構普通だったからってのはあるんでは。
アルゴリズム関連の本はPascal多かったし

Borlandにはもう天才プログラマはいない。
機能追加や保守で精いっぱい。
もう新しい言語にチャレンジする体力が無いのさ・・
でもIDEのエディタは何とかして欲しいもんだな。

>>172
当時はまだＭａｃなんてＰａｓｃａｌがメーカー推奨の
標準開発言語だったよね。いまやコードウォリアーも
見限った感ありだが。確かに最近始めた人にはなんで
パスカルかわからんのも仕方ないと思う。

Pascalには
ストロング・タイピングなのでC/C++よりもコンパイルの段階でバグを見つけやすく
大文字小文字を区別しないのでコーディングしやすい
という利点がある

最近、CodeWarriorもPascalのサポートやめちゃったね。
そういえばこれもObjectPascalって言ってたけど
Delphiのとどうちがうんだろか？

>>175
大文字と小文字は同一文字の異なる形態というだけなので
それらに異なる意味を振ることができると人間の勘違いミスを
招くってことで同一視のほうがエラー予防になるってことじゃ
なかったかな。

>>177　そうだね

>>168
恐らく，ターボパスカルのボーランドだからでしょう．
マイクロソフトがベーシックにこだわるのと同じで．

>>176
ＡＮＳＩが標準化をすすめてきたＣ／Ｃ＋＋と違って
標準的なオブジェクト指向パスカルは存在しないようですから，
各社が勝手に拡張してオブジェクトパスカル
と名乗っているだけなのではないかと．

（そのためか，一部Delphi書籍では
　Delphi Pascalという言い回しを使っています）

ちなみにボーランド自身も，
デルファイの前身であるターボパスカルは
後期にオブジェクト指向言語に拡張していたようですが
デルファイになった段階で仕様が変更されています．
（互換性のためにターボパスカル式の記述もできるようです）

たぶん Delphi1の発売当時、先行していたVB の弱点として
　”VBがインタプリタだったのに実行までに非常に時間がかかる” <-当時ね

というのがあったから、TurboPascalの超絶的コンパイル速度
を非常に大きなメリットとしてぶつけられるというような戦略もあったのでしょう

実際、少し大きなプロジェクトだとVBは実行が始まるまでコーヒーが飲めましたからね

Delphiの速度があれば、コンパイル＆ゴーを繰り返すスタイルで開発出来ます
　デバックがある程度できればそれをモジュール化してゆく訳です

C++Builderの速度だと、ある程度　コーデングデバックも混ぜて
　デバックが済んだモジュールは出来るだけ触らないようなスタイルになって
しまいますよね

そういえばエクストリームプログラミングでも
コンパイル速度はなるべく早く保つというのは
重要な事だと主張されていますね。

>Delphiに関しては、Turbo Pascalっていうブランドがあったから。

>Borlandにはもう天才プログラマはいない。
>もう新しい言語にチャレンジする体力が無いのさ・・

そうとも言えないようだよ http://mentai.2ch.net/test/read.cgi/bsoft/998629435/29-31n
体力が無いのはヘジ、Delphiが売れたのはVBの失敗らしいＹＯ！

>>182　VBについてはこんな話もあったよ↓
http://piza2.2ch.net/test/read.cgi/tech/990101968/116-169

BorlandのPascalは確かにコンパイルは早いという面で素晴らしいが、
本当に技術がある会社ならば、その素晴らしさを新規開発の言語に投入できる
のではないだろか？
DelphiはPascalを独自仕様で拡張してるわけだが、
あのOOP拡張はPascalそのものとは左程相性がよいとは思えない。

新規開発をやらなかったのは、技術的に、過去の資産を使いまわしたのだろう、と思う。
爆速コンパイラの。

＃もちろん、ブランド名とかも使いまわした。

悔しい(?)がC#は後発なだけあって、言語仕様だけ見ればDelphiより良い面が沢山ある。
別にC#でなくてもいいのだが、そういう新しくて良い面を、Delphi(または類似品)に
どんどん投入して欲しいものだ。Borlandにその技術があるならば。

おっしゃる通り。

でも、Pascalを独自拡張で限界がきているわけではないから

C#を取り込みつつ既存DelphiPascalを大幅に越える方法があると思う。

そこまでしてDelphiにこだわるのは
はっきり言って怠慢以外の何ものでもない。
C#が良いならC#に移ればよい。
今後Delphiに出来るのはC#の後追いだけ。

>>185
確かに限界なんかは来てないのだが、
微妙な面倒さが少しづつ積もってきている。

たとえばプロパティ定義。delphiだと、メソッドの宣言、プロパティ自体の宣言、
そしてメソッドの実装、とわざわざ三箇所に記述を分散しないとならない。
(そのくせC++と違ってソースを分割することも出来ない)。
javaやC#のように一箇所にまとめられるほうが良いと思う。

言語仕様は、現状に「追加」するというよりも、時として「変更」して欲しい。
まぁ従来のを互換性の為に残すのは仕方ないが、もっとすっきりした構文とかを
順次導入して欲しいと思う。

>C#が良いならC#に移ればよい。

ゲイツ以外の実装が出てくれば、
安心して移る(というか併用：Delをやめる必要もまた有るとは限らない)
ことが出来るんだが…。

どっかの誰かがGPLでC#互換実装を作ってるって噂は本当でしょうか？

なお同じことはJavaにも言える。
AnyWhereっていってもVMが移植されてない環境ではねえ…。
Kaffeでもしとくか。

明示的にSetやGetメソッドを呼ぶことは、全くないわけだから。

propertyに拡張指定子でSetとGetメソッドの記述省略可能になってほしいね。

内部フィールドもpropertyのreadとwriteで記述可能にするとよさそう。

あのさあDelphiスレあげすぎ
自分はJavaユーザーだけど
はっきりいってうざい
煽りたくもなるってばよ

ショウガナイヨ、Javaは出来ること少なくて、終ってんだから>>190

C++とJava/C#のあいだって感じ〜？

おれはどっちも使うけど、
Javaスレの上がりっぷりはもっとウザイのを自覚せえよ（ｗ>190
Javaスレ立てすぎ＆バージョンとかメーカー毎に立てるのヤメロ
情報が分散し過ぎ

>>191
いやJavaがどうのこうのじゃなくて
Delphiスレあげすぎでうざいって言ってんだけど
通じないかなあ

>>190
ぷぷぷ、Javaユーザーって心が狭いね(w

Delphi>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Ruby>Java

カスJava消えろゴミくせえんだよ

悪かった。
WIDOWSしか使えん奴らに何言っても無駄だったな
わりいわりい

１９０はJavaが遅すぎてストレスが溜まってるんだね
Delphi使えばいいのに(笑
Javaダサすぎ(藁

Write Once, Run Any Where
君達には難しいかな

いや、それはJavaにも難しいだろう。

Write Once, Test Any Where
君達には難しいかな

どうやら、Java使いのフリをしてまた802童貞が荒らしているようだ。

Delphiの言語仕様を新しく考えるのなら
名前空間はしっかり考えて実装してほしい。

同じTxxxというコンポーネント名でも名前空間がしっかりしていれば
同時に使えると思われ

>>202
童貞という言葉にやたらこだわるね
なにか気がかりでも? (w

ていうかこの手の嵐はジサクジエンでしょうな

嵐が去ったようなのでここからはマジな話の再開
-------------------------------------------

あいかわらずヘルプはいいかげんだ。
InterBase Express (TIB...) なんか C++ のになってる。
確信犯としかいえないぞ！ > 某

ほんとはPascalなんて使いたくないんだけど、
Delphiで作るの楽だから使ってます。今後のBuilderに期待。

>>205
IBX は Borland の管理物ではなくなったから，しょうがないんじゃ？
英語版からだし.

>>207
> IBX は Borland の管理物ではなくなったから，しょうがないんじゃ？
Del6にはどうやらBuilder用のやつを付けてると思われる。
標準コンポーネントとしている以上ドキュメントはきっちりしないとだめだろう。そんなのは理由にならないぞ。
このことは別にIBXに限った話じゃないことを言いたい。
おれはC++もやってるから理解できるが、それとこれとは話が違う。
高い金払って買ってるわけだからいいかげんなやり方されちゃ文句の一つも言いたくなるわ。
はいそうですかで納得するヤツの気が知れないな。>某信者諸君

Delphiというより某に対してだったな。（Delphi自体は最高だと思ってる。）

>>208
何に対して怒っているのか理解できないな
Pascal 表記のヘルプがないことがそんなに問題かい？

「日本語版」でリリースしておいて、実際役に立つ筈のヘルプは
みんな英語だった、って状況と似てるな。
「日本語版」なんだから全部やれよ

>>209
言いたいことは
208> 高い金払って買ってるわけだからいいかげんなやり方されちゃ文句の一つも言いたくなるわ。
あと最近はどうかしらんがサポート担当者の対応がいいかげんだった。（ど素人って感じだった。）
他ベンダの製品と比べるといいかげんさがわかる。Del自体はすばらしいのに。

>>210
IBX のヘルプは、全部日本語じゃん。

>>211
他ベンダって、どこだよ。
今、日本で開発ツールを提供している会社、どれだけある？

208> 高い金払って買ってるわけだからいいかげんなやり方されちゃ文句の一つも言いたくなるわ。
これが間違いの元でしょ？
金を払ったからといって、どんな要求でも通ると思ってはいけない。
ツールの使用権を買っていると思えば怒る気もしない。

> 今、日本で開発ツールを提供している会社、どれだけある？
なにも開発ツールに限定した話ではないがな。

>208> 高い金払って買ってるわけだからいいかげんなやり方されちゃ文句の一つも言いたくなるわ。
>これが間違いの元でしょ？
>金を払ったからといって、どんな要求でも通ると思ってはいけない。
>ツールの使用権を買っていると思えば怒る気もしない。
俺が言ってることが特殊な要求か？
最低限のことを言ってるつもりだぞ。
ところで君は金払ってるお得意様に対してそんな態度とってるのか？

>>212
ちゃんと読め（ｗ

知識が豊富な開発者相手の商売だからこそ
野放しにされている部分は確かにあるだろう。

あきらめている人間はたくさんいるだろうな。

ドキュメントがないと宝の持ち腐れなのだから
大切にしてもらいたい。

Win32 API なんか英語で C 構文だぜ？
そっちのほうこそどうかして貰いたい。
IBX のヘルプなんか、訳されているだけでもありがたいよ。

type IList = interface abstruct(TList);

とかやったら TList の Public / Published な　メソッド　プロパティだけ
全部抽出したのが定義出来たらいいのに・・・　出来るのかな？

>>217
できない。

>>218　じゃ出来るようにしてよ。　ってボーランド人だよね？

ついでに pointer型だけでいいから
IMyList = interface (IList in TEdit);
とかやればプロパティやメソッドの pointerの部分が TEeditに
なるようにしてよ

なんか、めんどくさいことを全部言語処理系に押し付けていない？

>>219
そんなことして何がうれしいの?

そんなこと言わずにお願い！

"Templates in Object Pascal"
http://community.borland.com/article/0,1410,27603,00.html

>>223
この記事いいね。

テンプレートは強力なインライン展開をするマクロとしても使えるが、
その辺はさすがに代用は手段はないか・・・
ま、元々マクロやインラインが不要と言う方向性の言語だろうし。
無理にでも、やるとするとプリプロセッサ作るしかないわな。

現在VBで社内用業務アプリを開発しているのだが、
なんとかしてVBマンセー上司にDelphiの良さを伝えて、
Delphiで開発を行いたいのだ。


上司を説得するにはどうすればよい？

体を売る

>>225 プログラマ板向けのネタだよね。

　まあ結局は作ってみせるしかないと思うよ

でも、その話題、あんまりやると板全体が荒れるから　出来れば移動して欲しいな

VBだって時と場合によっては生産性が高いのは確かだ。
その上司が本当にツールの限界を理解していれば、だけど…。

VB"も"だろ。

Delphiと比べたらVBはゴミ以下

ういんどうずでは、VBできればまっいいや〜
Unixは、ｃだよな〜
まるちはJava。

おれはもっぱらじゃヴぁ

上司がDelphi知らないから、Delphiでの開発に乗り気でないのでは？

>>227
わかった。
マ板へと移る。

他にもレスくれた方々感謝。

同期型のコルーチンを記述出来るようにして欲しい

たとえば interface をメソッドに付けると
　インスタンスにローカル変数用のスタック領域を取るように変更される
　SPを切り替えてしまうとOSから例外が出てしまうから
　BPだけを使うようにする

　メソッド内部で switch(引数)　のように呼び出すと　外から見たらreturnして
帰って来たように見え、外部からそのメソッドを呼び出すとswitchの所から
処理が継続するような仕掛けね

C++のテンプレート機能が欲しいという意見は良くみかけるけど
ビジュアル開発環境との相性の点で疑問

コンポーネントはコンパイルされていなければ設計時に使えないのだから

>>234
それなにに使うの？

>>236
例えば、　圧縮展開なんかのメソッドを
function Thoge.get:char;interface;
begin
　・・・処理・・
　switch:=c; //ここで同期的にスイッチしてcharを一旦返す
　・・・処理・・

end;
と書けます。
　このメソッドでデータが出来る都度 switchで外に出し
　外から見ると getを連続して呼ぶだけで扱いが簡単です

>237
オモロイね。オブジェクト指向とちょっとかぶってるかな。
ところでinterfaceというのはどこから来た言葉なの？

定義済の単語でinterfaceが一番適当かなと思ったんで。

それと、複数のコルーチンメソッドを持った場合は

switch put(c); //putを呼んだルーチンに帰り、引数cを貰ってくる
switch get:=c: //getを呼んだルーチンにcを帰り値として渡す

みたいにメソッド名で識別できると便利
つまり、パイプみたいな処理を低負荷で出来る

>>237
なるほどよく分かった。でもちと言語レベルでサポートするには
仕様が複雑すぎると思う。
アセンブラごりごりなコードを書けばコンパイラに頼らなくでも
実現できそうだ。

fiber使え

>241 重いのと、引数の渡しが面倒です。

scheme使え

俺は演算子の定義が出来るといいな

Cのような演算子のオーバーロードじゃなくて　メソッドの定義で
　operator "演算子名"( 引数1,引数2) ;優先順位;
　型は指定しなくてもそのクラスの型になる
　引数が１個なら1項演算子、２なら２項演算子　３項演算子は不要

　使う時は c:=a "*" b みたいに "演算子名"でいいや
　演算子の優先順位は整数の範囲で大きい程上って感じ

おっと、メソッドじゃなくて　汎用関数の方がいいな

>>244
カスタムバリアントを使え。

なるほど、俺のDelphiには無いぞと思ったら Delphi6からの機能なんだな・・・逝ってきます

>カスタムバリアント
誰も使わないVariantに少数派の要望をねじ込んだ、実にうまい手だ！

三項演算子つくってくれ！！！切実に希望。

if A then
A := B
else
A := C;

を if A ? B : C とかそんな風にかけると、ソースコードの行数が結構減らせてイイ！！
しかも、A の真偽に応じて、B,Cの一方だけしか評価しない奴。

本当にそう思ってるのか？
ここで発言てみたいだけなんとちゃうんか？
と問いたい問い詰めたい。

function Iff();

IfThen()

>>251
>A の真偽に応じて、B,Cの一方だけしか評価しない奴
この要求を満たしていない。

「B,Cの一方だけしか評価しない」とは何ぞや？
評価なんてしないと思うが・・・

　これあげーる。

　評価しない＝functionの中身が呼ばれない
　MathユニットのIfThenと比較するとよくわかるﾆｬ

￣￣∨￣￣￣
　 ∧,,∧
　ミ,,ﾟДﾟ彡
　 ﾐ つ[ 三項 ］).
〜ﾐ ,,　ﾐ　
　 ∪∪　　

function TrueValue: Integer;
begin
　Result := 1;
　ShowMessage('Trueってヨシ');
end;

function FalseValue: Integer;
begin
　Result := 0;
　ShowMessage('Falseってヨシ');
end;

type TIntFunction = function: Integer;

function IfThen(AValue: Boolean; ATrue: TIntFunction;
AFalse: TIntFunction): Integer; overload;
begin
　if AValue then
　　Result := ATrue
　else
　　Result := AFalse;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
　Button1.Caption := IntToStr(
　　IfThen(True, TrueValue, FalseValue));
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
　Button2.Caption := IntToStr(
　　IfThen(False, TrueValue, FalseValue));
end;

>ソースコードの行数が結構減らせてイイ！！
この要求を満たしていない。

よくみると
＞if A then
＞A := B
＞else
＞A := C;
AはBoolean型の変数でないと使えない。

Cの三項演算子は A=B?C:D; だよ。

引数渡しと関数渡しが根本的に違うし…
>>254の他の欠点は
　　　type TIntFunction = function: Integer;
引数なしFunctionしか受け付けていないところ。

引数ありFunctionの場合、定義が必要になるのは面倒すぎるので
外部に公開するFunctionを
　　　type TIntMethod = function: Integer of Object
にしてみた。
　　　　　　　　　＿＿＿＿＿＿＿＿＿
　 ∧,,∧　　 ／
　ミ；ﾟДﾟ彡＜　悪い予感が…
　 ﾐつ　つ 　＼
〜ﾐ ,,　ﾐ.　　　　￣￣￣￣￣￣￣￣￣
　 ∪∪　　

////////////////////////////////////////////////////////////
type
　TFuntionClass = class(TObject)
　public
　　class procedure SetTrueValue(Value: Integer);
　　class procedure SetFalseValue(Value: Integer);

　　class function TrueMethod: Integer;
　　class function FalseMethod: Integer;
　end;

{ TFuntionClass }

var
　TrueValue, FalseValue: Integer;

class function TFuntionClass.TrueMethod: Integer;
begin
　Result := TrueValue;
　ShowMessage('Trueってヨシ');
end;

class function TFuntionClass.FalseMethod: Integer;
begin
　Result := FalseValue;
　ShowMessage('Falseってヨシ');
end;

class procedure TFuntionClass.SetTrueValue(Value: Integer);
begin
　TrueValue := Value;
end;

class procedure TFuntionClass.SetFalseValue(Value: Integer);
begin
　FalseValue := Value;
end;
////////////////////////////////////////////////////////////

type TIntMethod = function: Integer of Object;

function IfThen(AValue: Boolean; ATrue: TIntMethod;
AFalse: TIntMethod): Integer; overload;
begin
　if AValue then
　　Result := ATrue
　else
　　Result := AFalse;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
　TFuntionClass.SetTrueValue(100);
　TFuntionClass.SetFalseValue(200);

　Button1.Caption := IntToStr(
　　IfThen(True, TFuntionClass.TrueMethod, TFuntionClass.FalseMethod));
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
　TFuntionClass.SetTrueValue(300);
　TFuntionClass.SetFalseValue(400);

　Button2.Caption := IntToStr(
　　IfThen(False, TFuntionClass.TrueMethod, TFuntionClass.FalseMethod));
end;
　　　　　　　　　＿＿＿＿＿＿＿＿＿
　 ∧,,∧　　 ／
　ミ；ﾟДﾟ彡＜　Pascalに三項演算子は似合わないって事でよい？
　 ﾐつ　つ 　＼
〜ﾐ ,,　ﾐ.　　　　￣￣￣￣￣￣￣￣￣
　 ∪∪　　書いていて鬱になるコードだ.

>>257-258
　TrueMethodとFalseMethodをInterfaceで定義しておけば
　場面に応じてそのinterfaceを定義したクラスを作り
　使いまわしの出来るコードが作れるかもしれないけど

　ﾈｺは嫌になったからもうしらない。

￣￣￣∨￣￣￣￣￣
　　　∧,,∧ 　　　ｳﾂﾀﾞ
　　ミ,, ﾟДﾟ彡
　　 〃　 つ旦~~ 　
　〜ﾐ,,,ｎ,,ｎ［￣￣￣.］
　　　　　　　￣￣￣
　TFunction = function integer
と
　TAFunction = function(Value: Integer): Integer
も継承関係にあるべきと思うのはおかしいかしら。

３項演算子は単に短く書けるというだけの価値は無いと思います

Delphiは同じ処理を表現する手段がCより少ない事が　メリットの一つだと思いますから
無くても良いような機能は増えて欲しくない

だって C の三項演算子は

if aaa
　bbb;
else
　ccc;

の省略記法以上のものではないのだから、下手な細工はやめて if 文で
書いたら？

それに C の三項演算子、決して見やすくないよ。

　　∧,,∧∩　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 ミ,,ﾟДﾟ彡　＜　>>260-261　ﾘｮｶｰｲしまツた
　　U　　ミ　　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　ﾐ　　ﾐ
　ノ∪∪　誤ったﾄﾞﾂﾎﾞにはまってｼﾏﾃﾀ ﾉﾈ

マニュアルがしょぼいよね。
JavaDocみたいなのがほしい。

あるいは有志で整備するか。

Javaみたいなパッケージ階層希望、あるいは C++ みたいな名前空間でもいい。
とにかくコンポーネント名がダブってもよいしくみにして。

delphi.TObject
delphi.TComponent
delphi.TControl
...
com.borland.TDelphiExComponent
...
mydomain.TMyComponent
...

>Delphiは同じ処理を表現する手段がCより少ない事が　メリットの一つだと思いますから

三項演算子だけ欲しかった。
Ver6からのVBの関数互換はヤメテクレーって感じ。

　　　∧,,∧　　　／￣
＼,,,,ミ,,ﾟДﾟ彡　＜　>>264　ﾄﾞｳｲ
⊂,,,,,,,,,つつ.　　＼＿

TCommandなんていう名前定義するの、ドキドキするYO
TFusaGikoCommandで
TFGCommandと命名する方式はとてもカッコワルイ！

CLXとVCLとで名前空間を別に出来ているのだから
ユーザーにも名前空間別にする処理を提供してほしい。

C#みたいに完全に階層構造じゃなくても
パッケージとユニットの２段階層があればかなり便利になるのだ！

名前だけならなんとかなるとしても
　Obj.ClassName が返す名前をどうするの？

>>267
ユニット=Classes
カテゴリ=クラス処理ルーチン

function FindClass(const ClassName: string): TPersistentClass;

名前からClassを得るという活用方法が有るのだから、これでよかろう？

なお
procedure RegisterClass(AClass: TPersistentClass);
を忘れるな！

>>268
同じ名前をもつクラスをひとつのプログラムに同居させたい。という話をしているんですが。

クラス、関数、手続き内のスタティック変数ほしいかな。
今は型付き定数やユニットローカルな変数で代用してるけど。

型付き定数でいけない理由は？

　　　∧,,∧　　　／よく氏等ニャーが
＠,,,ミ,,ﾟДﾟ彡　＜　関数などはあとがきuses Unitが優先選択されるのだから
⊂,,,,,,,,,つつ.　　 ＼ クラス名も後書きuses Unitが優先されたりはしないの？

　完全な名前空間でなくても便利ならいいんだしー

>>272
それは（プログラム）スコープの問題でしょ？

フォーム上のコンポーネントをプログラム実行時に .dfm から復元するときに
コンポーネントのクラス名から vmt を特定してインスタンスを作成しなきゃ
いけない。このときのスコープはどうなっていれば良いと思う？

極端な話、TMyComp が二つのユニットで別々に定義されていて、それをひとつのフォームで
一緒に使いたい場合を考えてくれ。
.dfm にどのような情報を載せれば二つを区別できるのか。

ってことで結構大変。フォームのことを考えないんなら、ユニット名による
名前空間管理で結構何とかなるんだけどね。

　　　∧,,∧　　　／￣
(,,,,,,,ミ,,ﾟДﾟ彡　＜　なるほど。
⊂,,,,,,,,,つつ.　　 ＼＿

dfm読み出すとき対応するユニットからクラスを類推するのはだめ？
現状でもpasのないdfmのみだとインスタンス生成しないよね。

もしくはdfmの書式を変えてしまうとか？

Obj.ClassName が返す名前を　ユニット名＋クラス名にすればよいようだけど
あんまり綺麗じゃないと思うけどなあ

そろそろコンポーネントのウニコード対応してくれYO!

>>276
そんな貴方にＣＬＸをどうぞ

>>276
まともにやると Win98/Me で動かなくなるしぃ

CLXコンポ少なすぎ！
ドッキングもサポートしてないし。
バグまみれだし。
Kylix2が発表されたが期待していいのか？

どうなんだろ。CLX
個人的にはバリバリにLinuxに最適化して使い勝手を上げてくれた方が嬉しいのだが。
Win環境でVCLを捨ててCLXを選ぶのはデメリットが大きすぎる。
それでもクロスプラットフォームの方がメリットがあるのかな。

>>280
それはXP次第だろうな。レジストレーションを避けて
チケット予約端末なんかのLinux化は進行すると思われ。

>>281
チケット予約端末に組み込まれる Windows に個別のアクティベーションが必要なのか？

>>271
全ての型付き定数が代入を許してしまうので、
定数では無くなるのでは？

あのさ、WinXPでDelphi使うと、F9なんかでIDE内で実行させた後
実行したアプリを終了すると、XPが十数秒固まらない？これバグなの？

ちなみに毎回ではなく、3,4回に一回くらいなるんだけど…

せめてポインタの加減算くらいキャストなしでやりたい・・・

>>286 気になる・・・・どんなコード書いてるの？　

>>287
会社でゲーム作ることになったんだけど
画像処理にポインタ使いまくるし

>>288
　いやキャストってどうやってるのかなって・・・
　　ポインタに整数値で前後させたになら　-->inc/dec
　　ポインタからの相対番地を使う---->配列をポインタにabosoluteして使う

あ！　もしかして 24bitColorの処理？
　　それならアセンブラ使った方が綺麗かも

>>289
あれ？ポインタに Inc()/Dec() って使えたっけ？
どーも Inc(Integer(p), line_span); とかしないと
コンパイルエラーが出るなーと思って悩んでたんだけど・・
ちょっと今から試してみます

「配列をポインタにabsolute」の技は知らなかったです
Integer() キャストして Pointer() キャストしてて，鬱になってました
ありがとうです。。。

あ，また新たに書き込みが（わらぃ
ずばり，24bitColor の処理です
アセンブラっすか
腕に自信はないけど，ちょうど勉強し始めた分野だー

　もしかして p が　単なるPointer型じゃないの？　Byte型のポインタならInc/Decで±１
Integer型のポインタならInc/Decで±４されるよ

>>293
　　　　　　　　　(;ﾟДﾟ)ﾉ　＜ ・・・

─────　失礼しました〜〜　─────

よく考えたら C だって void* の加減算はできないわけで
すっかり忘れてたっすわ・・・(;´Д`)ｧｩｧｩｧ

２４bitColorを使うならこんな感じね

procedure func(src:PByte);
　type T24Color=packed record
　　 r,g,b:byte;
　end;
T24ColorArray=array [0..10000]of T24Color;
var pc:^T24Color absolute src;
var ac:^T24ColorArray absolute src;
begin
inc(pc);
with ac^[1] do begin r:=2;g:=3;b:=5;end;　<---　最初のsrcの6,7,8
inc(pc,5);
with ac^[2] do begin r:=1;g:=2;b:=3;end; <---　最初のsrcの8*3番地

ｸｽｺ ヽ(´ー`)ﾉ ｸｽｺ

>>284-285

HKEY_CURRENT_USER\Software\Borland\Delphi\6.0\Debugging を 0 にしてみたら？

結果連絡よろしく

Delphi.NETアゲ http://itpro.nikkeibp.co.jp/free/NSW/NEWS/20011115/2/

.NETっていろんな言語使えるのがウリだよね。

Javaスレは一体．NETのなにと戦っているんだろう？

255.NET>>300

>>299
当然の決断だろうなー。
だけんども、CLIのコードはけるくらいなら、
JavaVMのコードもはけるようになれば面白いのに(冗談

SHR だけでなく　SAR 演算子を追加して欲しい

符号付きの変数に対してDIV 2とか定数の割算ならSARになるけど
変数でシフト数を指定したい場合もあるんだから

え？　インラインアセンブラ使えって？・・・・ハイハイ

>>303
分かっているじゃないか。インラインアセンブラ使え。

アセンブリ言語にベッタリ癒着した演算子は基本的に
Pascalとマッチしない。

Delphi# 希望！　仕様はキミたちが想像してくれい。
ネイディブはもちろん.NETも対応してほしい。

きょうはdelphi6へアップデートしないことに決定！！？？？

理由
1．豊富なコンポーネント実はほとんどフリーウェア(INDYはMPL、FASTNETも古いものなら)
2．WINAPI関連コンポーネントのバグはなおすきなし
3．やっと3DNOWとSSEに対応したインラインアセンブラ
　でもとき遅しすでに直接コーディングが身にしみている。あとはNASMとか
　もう3DNOWもないだろうし
　しかもExentiaがあれば取敢えず十分だろう。辺鄙なコードは

4．データベース関連コンポーネントの依存度大きすぎ
　あとなんかぜいたく品扱いなのがおかしい。ADOexpressとか
　Windowsに標準搭載されているもので
　VBSで数行でADOが実装できるというのに．．．


5．LINUXを強調しているけれどX86のＰＣならWindowsだけで十分
　マルチプラットフォームならばWin−CEかMacじゃなきゃ意味なし。

6．改善されない馬鹿でかEXEファイル、glutみたく400kbyteぐらいのランタイムが
あったほうが使いやすい

7．DirectXにもSAPI5にも未対応、というかACTIVE−Xに動的に対応できないのは痛い

というわけで最近はコンポーネントを使うものはdelphi3pro(ファイルサイズ180kbyte)
あとのプログラムはdelphi5　learningです。
ゲームプログラマーなのでコンパイラーとしてのdelphiは好きですが
コンポーネントはAPIのテスト以外まったく使いません。こてこてのメモ帳型プログラマーです。

ところで業務・商用利用できるdelphiで一番安いのはD5−learningです。お店にあったら買いではなかろうか．．
使いませんがべたのWin32APIでなくてKOL＆MCKでも100kbyte以下のプログラムを作れるみたいですね。

あとなんかD6は関数が増えたっていうけれど手持ちのものより優れているとは思えんし
なんかメモリリークおきやすいとか悪いうわさもある。
コンパイラがP3最適化できるとか何かD6購入動機があればつっこんでくりー
明日がタイムリミット

＞5．LINUXを強調しているけれどX86のＰＣならWindowsだけで十分
＞　マルチプラットフォームならばWin−CEかMacじゃなきゃ意味なし。
ここだけ妙に主観的。

>>307　だってさ、なぜか知人にまっかーな人が多くって
LINUXな人にならWinでも入れてといえるけどMacにゃ物理的に不可能でやんしょ。

つーかCPUが違わなきゃ、マルチOSっていうなぁ。
最近はPC安いからWinだけに対応しときゃ、最悪PCとソフトセットにしてもよいと思ふ
こっちの手間が省けることが最優先

LinuxはPowerPCでも動いているんだから、Kylixを移植してもらえないものかねぇ。

>309
VCLやObjectPascalがコンパイラマジックに依存しているので、
面倒なんじゃない？
まず、Mac用のObjectPascalコンパイラをつくらなあかんよって。

つーかマカに開発者いないし

>>306
>なんかメモリリークおきやすいとか悪いうわさもある。
これは噂だな。知られているバグは Update でつぶされている。

なんつーか，某 ML 「のみ」を情報源にすると判断誤るから気をつけた方がいいよ。
D6Update で RTL の文字列コピー関連のコードが PIII 系最適化されたし，
マルチスレッド周りの微妙なバグもだいぶとれているし。

RTL でかい。ってのはソース付属の Delphi の利点を捨てているわけで。
機能を追加するのは Borland に任せて，自分で使うときは機能を削ぐ。
ドッキングを使わないアプリを作るのなら，その部分をコメントアウトしちゃえば良い。

ADOexpress は Pro 版には標準装備だろ？

順序逆だが
1．豊富なコンポーネント実はほとんどフリーウェア(INDYはMPL、FASTNETも古いものなら)
これは間違い。Indy だけが MPL.
TeeChart も QuickReport も FastNet も商品の一部。

2．WINAPI関連コンポーネントのバグはなおすきなし
これは具体的に何？バグがないとは言わないが，あらかた直っているとも思いますが？

5．LINUXを強調しているけれどX86のＰＣならWindowsだけで十分
CBuilder の ARM 版が今度でるでしょ？発表がありました。
海外のサイトの噂では CLX ベースになるそうで。

7．DirectXにもSAPI5にも未対応、というかACTIVE−Xに動的に対応
MS 以外の言語の中では一番充実していると思っていますが？
D7 も D8 もガンガン使ってコードをかいている方がいらっしゃいますが？

あー今日なんだねアップデート締め切り

Delphiコミュニティで「これが出来ない」　というと　「あんたの能力不足」になっちゃうからなあ・・・・

　まあ確かにそうなんだけどね

>>312
＞CBuilder の ARM 版が今度でるでしょ？発表がありました。
ギャーマジ？
ﾊﾟｽｶﾙないの？

> ドッキングを使わないアプリを作るのなら，その部分をコメントアウトしちゃえば良い。
　　 ∧,,∧ 　　　 　／
　　ミ,TДT彡　　＜ 　そんなんできません。ってば。
　　ﾐ つ且~~　　　＼
〜ﾐ,,,,,,　,,ﾐ 　ﾀﾞﾚ? ｲｯﾀｲﾀﾞﾚｶﾞ.... ｿﾝﾅﾜｻﾞｦ...

> ところで業務・商用利用できるdelphiで一番安いのはD5−learningです。お店にあったら買いではなかろうか．．

ンー、ト。金儲けするのにPro版の数万円をケチルというのは
ちょっと体質的にどうかと....思われ
プログラマだって雇っているだけで金が減っていくわけだし。

>>316
うーん。カスタム VCL ってどこでもやっていることだと思っていたのだけど。
個人レベルだとメンテナンスが大変かもしれないけど、企業ユーザーなら困難では
ないと思いますが。特に自社製コンポーネントの再利用で生産性を上げられるの組織なら
カスタムフォーム/カスタムメモリマネージャを用意することに違和感はないと
思いますが。

>カスタム VCL
ライセンスの問題でライブラリとしての配布は出来ないんだろうね。でも欲しいなあ。

>>318
各種バグレポートを集めておいて、パッチを当てたライブラリを用意するくらいの
ことはするでしょ？それの延長。

System/SysInit 以外は、ターゲットプロジェクトに VCL ソースを投げ込んじゃえば
好きに改造できるし、デバッグも楽。あとで各プロジェクトごとに書き換えたソースを
回収するとき大変だけどね。

結局アップデートしてしまいました。
12/28着にもかかわらずバグ含みのCD-ROM．．．作ったCD-ROMはなおさんのかい？？

アップデートしようと思ったら許諾コードとかやらが必要とか．．．うーむ
でアップデート前にフォームだけで400kbyte強、アップデートして360kbyte強
バージョンだけでなくてファイルサイズもDel3の倍？？？
たくさんあるコンポーネントも似たようなものばかり、

てっきりフォーム関連についてはD5よりもましになっていると思ったんだけど
なんとフォームを使わないプログラムでもファイルサイズが肥大するようです。
SULLACOのOpenGL　64Kbyteデモが192kbyteになるのはちょっと笑えた．．．

仕方がないのでKol導入、ただし信頼性が．．．

CLXだけどこいつはだめですね、dll必須とはどこにもかいてなかった．．．

>>312
ADO関連ってボーランドがえばるようなもんでもないでしょ。
VBScriptでも使えるんだし
あとドラッグアンドドックはかなり深いところまでちらばっていて
これをはずすというのはVCLほとんど書き直すようなもんで
そんなことすんならばWin32APIでアプリ作ったほうがまし
というよりDelphi3でフォームをdllにするという手が．．．

1．Fastnetはフリーダウンロードできます。
2．OLELOADPICTUREの宣言が間違っているので使えない
といっても自前で宣言すればいいのだけれども
5．がんがんコードを書いているというのはMSのヘッダーからの変換も含めてです。
これってTformのソースを1から書いているのとおんなじ
本来OSのAPIなんだからコンパイラ側で用意するのが当たり前では？
結局ボーランドはだめだから自前でということではないかと．．．．

さらに　ZLIBはまだ1.04、Jpegも古いライブラリー(a)
OpenGLは1.0、Winsockは1.1

全部自前で再構築が必要、やっぱりやる気がないとしかいいようがない。
まっとうに考えるのならばWinMeやWin2KでのMSのライブラリーくらいは
ちゃんと変換しておいてほしいのだけどどうみてもD6のそれはWin95、NT4レベル

ただし送付されたCD-ROMにはフリーウェアとしてJEDIのヘッダーがついていました。
OSレベルのヘッダーまでフリーウェア依存というのはやはり問題では？
というよりCD-ROMに入れなくたってURLを入れれば十分では？という感じです。
（それにしてもdelphi2だけのためにあるようなNKdibとかがあるのはなぜ？？）

まぁそれでもIDEはそこそこよいと思いました。
コンポーネントを使わないばあいててでもまぁまぁ使えるようにはなったと思います。
あと購入の決定打はインストールシールドが今っぽいところですか．．使わないけど
その他はSocketcompがWSAルーチンをきちんと入れているようなのでフリーズ必須ではなくなったみたいです。
インターネット関連のボーランドキラーなソフトを作るにはよさそうです。
ただし古いWindockのみ対応

取敢えず開発環境はD6でいいけれど
ソースを流用してD5でコンパイルしたほうがサイズもスピードも速いんじゃないか
というのが私の結論です。

唯一何もしないアプリprogram x;begin end;だけはD5より小さくなるんだよね……

>ただし送付されたCD-ROMにはフリーウェアとしてJEDIのヘッダーがついていました。
>OSレベルのヘッダーまでフリーウェア依存というのはやはり問題では？
せっかく JEDI が作ってくれているのだから borland がわざわざ作りなおす事もないでしょう．
ヘッダなんて２つもいらないです．
JEDI の勇士だってバンドルされて喜んでいるでしょう．
borcon 招待されるし，D6 もロハで貰えるし(w

>というよりCD-ROMに入れなくたってURLを入れれば十分では？という感じです。
すべての人がネットに接続できるとは限らないでしょう？
CD-ROM の容量余っているんだから入れたって別にいいと思いますが

とか言う私は今回はじめてバージョンアップを見送りましたが


良いお年を

>>322

全面同意、ああたは賢い！！

>> 305

個人的にはDelphi.NETには、Delphi#よりもUnmanaged Object Pascalになって欲しい。
VC++.NETと同じくCLRに乗ってなおかつネィティブコードを吐くやつ。
実現すれば、C#に限りなく近い言語機能でC++並みの実行速度を誇る.NET最強言語の誕生だ。

で、実際のところDelphi.NETってどうなんだろう…

Unmanagedとネイティブコードは直接関係ないだろ。

そうかもしれないけど、VC++.NETが「Unmanaged C++」を名乗っているから。

#が付くと(safe/unsafeは別にして)中間言語を吐き、 (→ C#, Eiffel#)
Unmanagedが付くとネィティブコードを吐く (→ Unmanaged C++)
「気分」でいました。(ダメ？

と、思ったら、何を寝ぼけているんだ俺は…

324, 326のUnmanagedは、全てManagedに訂正。
うわー、恥ずかしい… (ツッコミありがと

>>322
つうかdelphi自体インターネットに接続しなければBug修正もできないものなんだし
各フリーウェアはみんなインターネットでのみのサポートだということをお忘れなく

そもそもCD-ROMの容量があまってんじゃなくて
わざわざもう一枚のCD-ROMにぎっちりフリーウェアが入っているんですけれどもね、

というかバージョンアップを見送ったねこまさんは
D6-Proがいかに問題があるか体感していないからそんなことがいえるんでしょ。
オーバーロードとかInt64とかフォームのテキスト化とかもあわせて
delphi5が頂点だと思うよわたしゃ(次点delphi3)

.NETならばTMTPASCALっつうほうがdelphiよりよさげだ
あとdelphi6personalよりfreePascalのほうがよさげだ

さすがブビ厨はBASICしか出来ないようだ>>329

へーTMTPASCALなんて知らんかった。class型じゃなくてobject型とか
手続き型にフレームアドレスが含まれてるとか、それほどオブジェクト指向
しない場合はよさそうだね。
日本語通るか知らんが。

もうDelphiバージョンアップしないでいいからバグフィックスに専念しておくれ。
Kylix もバグだらけだし、某国どうしたんだよ。ちゃんとまともなものリリースしろよな！！！

>>332
>もうDelphiバージョンアップしないでいいから
んなこたない
IDEにTestingFrameworkとUMLデザイナを統合する作業が残ってる

Delphiってなんて読むの？
でるパイ？

>>334
正解。

Tobjectを捨てるか捨てないかというのが最後の選択になりそうだけれども
とりあえずclassesとsysutilsは捨てたほうがよさそうだ

なんかHTMLデザイナーみたいなのでフォーム作って
privateに変数宣言してWindowcreate時に動的生成するクラスがいいかなぁと思ったけど
kolというのがすでにやってた。

やっぱ社名をインプライスにした時にdelphiは終わったんだろうか？

IDEやおまけの関数は増やさなくていいから
コンパイラでせめてターゲットCPUオプションくらいはつけてほしい。
あとD6ProにはWin32API　Helpはついていないの？うーん

ところで最近SIMDの計算ライブラリーを手に入れたんだけど
これはよかった。最近delphi用のソースは完全に本家を超えている。

でもVCLが厚化粧だからこそ、簡単にRAD用のコンポーネントが書ける訳で、一長一短と思う。
コミュニティーのレベルが高いのは同意。

ドッキング機能とかいらないからもうちょっと軽くしたLiteなFormがほしい

>>338
とりあえずクライアント系のソフトを作る場合
OleコンテナだけのウィンドークラスをWin32で作ってhtmlとかXMLで
オブジェクトをおいてくってのはどう？
近道はIEを使うことだけど

あとデザイン固定ならば
コンポーネントベースでデザインしてからテキストベースのfrmファイルを
WIN32APIに置き換えればよいと思う。
色とかにこだわらないのならやっぱりダイアログを使うのがよい。
delphiはBRCCとか使わなくてもメニューやダイアログなどのRCファイルはコンパイルしてくれる。

Delphi互換にこだわる場合で手間のかからない方法として（＝あまりソースを変えない。）
delphi3でフォームを表示するdllを作って＝D3のソースを取り込むとかいわない

通常の設計手法のあとフォームのテキスト文をリソースに入れて
unitないのイベントハンドらとかをformからはずす＝unit内関数にする。

そうすると多分できの悪いD6でもEXE100の以内、dllは300kbyteくらい
設計時専用パッケージを作れば

というか取敢えずKol　＆　MCKはそこそこいけてる。
Class(Tobject)ではなくて(Obj)というのを使っているのがいやらしいけれど．．．

100の--→100k

>MEMORY PC-100 64MB CL2 1,170円
な時代に高々数百kbケチるために
そこまでするってのもご苦労な話だな。
古いマシンには古いOS・開発初環境がお似合いだよ。
皮肉抜きでさ。

配布の話なんでしょう。ブロードバンドの時代に、っていうのは無しとして。
IE&OLEを使ってメモリ効率も何もないでしょうから。
#最近はTGraphicControlのありがたみも無くなって来ましたねぇ

>341
企業ユーザでないならそれでいいんだけどね。

>>343
企業ユースならなおさらだろ。
開発効率・安定性・開発者の習熟度捨てて
サイズとるなんてアフォのやること。
VCL, SysUtils, Classes, TObject捨てて
なおDelphi使うなんて仕事では考えられない。

客先によってはFDとかダイヤルアップでやり取りするときもあるから
小さいほうが使い勝手がいい
いろんな環境があるので最低Win95でComCtlだけアップデートした環境で動くようにしてる
でも最新のIDEの環境に慣れると古いバージョンはしんどい
JBuilderでJavaのバージョン変えれるみたいにDelphiでも
古いバージョンのVCLに変えれたらいいのに

いまだにＦＤなんてドキュソな企業だが、それが現実だ。

>344
あんた、企業ユーザじゃないね。
アフォのやることをやらざるを得ない状況に持ち込まれるってことを
理解できていない。プログラマが全てをコントロールできるなら、
そりゃ幸せだよ。

あけましておめでとうございます．

>そもそもCD-ROMの容量があまってんじゃなくて
>わざわざもう一枚のCD-ROMにぎっちりフリーウェアが入っているんですけれどもね
そういえばそうだった……．

borland には dfm を UTF-8 にするだけではなく XML そのものにしてほしかった……
そんで TParser を打ち切って XML コンポーネントを pro 版にも提供すべき
この辺かなりガッカリした

インライン関数(メソッド)はあってもいいんじゃない？
問題はinlineが既に予約語なんだよねっ！

#define は読み難くなるから却下。

>349　inline　予約語だけど、使えるんじゃないかな、 inline(バイト並び)　でない
　　単なるinlineが後置されたら c++のinline相当って事で

interface部には書けないって仕様でも十分便利だし

でも、delphiのような言語を使う場合は、アルゴリズムで高速になるように検討し
それでも不足するならインラインアセンブラでって方式の方がいいでしょう。

C++と違ってプロパティがあるんだから単なる内部変数を読み出したいだけのメソッドを
定義する必要も無いし、多少でも処理内容があるなら インラインにした方がサイズ肥大
＝速度低下って時代になってるし

>>348
>この辺かなりガッカリした
かってに期待してかってにガッカリされても一私企業にとってはどうしようも
ないんじゃない？要望リストとして送りつける程度のことはできたんじゃ？

頼むから次期 Delphi には CLX 入れないでくれ。
いれるならオプションの形に。どうせもう使う気ねーからな。
はっきり言って Kylix と互換ねーじゃねーかよ！！！
おまけに Kylix はバグバグバグバグバグ... だらけだし。
まあ、このままじゃあ Kylix は消えるだろうな。
最近の某の製品のクオリティが落ちているが、初心に戻ってほしいよな。

>>352
CLX使っている人ってどのくらいいるんだろう。
俺は、別に付いていても使わないだけだから、どうでもいいんだけどさ。
それより、ヘルプのVCLとCLXがゴチャゴチャに入っているのが許せない。
同じクラス名でVCLかCLXか区別が付かないやつとかあるし。

>>353
たしかにヘルプでいちいち選択するのはウザイよ。
ほぼみんながWinアプリのためにDelphi使ってるから、わざわざコンポ少ない、
低機能なCLXなんかだれも使わんだろうな。
まあ、一度は試したことあるだろうけど。
どうせ使わないんだからCLXなんかやめてしまえってこと。
CLXが原因で多分、
・Delphi6 の品質悪い（今までで最悪）
・起動時間はめちゃくちゃ遅い（全Verとかと比較すると）
・ヘルプ調べるときに VCL or CLX かいちいち選択しなきゃいけない
のようなことが起こると思われる。（もちろんVCL機能拡張などもあるだろうが。）

CLX使って幸せになったヤツがいたらどこがいいのか聞いてみたいよ。

はぁ... ヘルプヘルプ、ってヘルプ読んでいないのがばればれ。
VCL ヘルプだけを出す方法がかかれているのに。
よく読めな。

>>355
キミは隅から隅までヘルプ読んでるのかい？
オレなんかは調べたいキーワードがあったときにエディタ上でＦ１でそいつのヘルプ見るくらいだよ。
必要もないのにいちいち全部読んでる時間なんてこっちにはないいんだよ。意味もないし。

オレは決してDelphi批判してるわけじゃないぞ。
今のところ Delphi は最強だと思ってる。
だからこそ悪いとこは改善してほしいわけだから
自分が思ってる意見を言ってるだけだよ。

そういう人に限って「CLX と VCL の両方のヘルプが見られないのは何事だ！」
とか言うんだろうね。

「自分が思ってる意見を言う」だけなら小学生でもできますって。
まず Readme くらいよんであげなよ。自分の頭が悪いことを
長々と書き連ねるな。見苦しい。

>>357
>そういう人に限って「CLX と VCL の両方のヘルプが見られないのは何事だ！」
>とか言うんだろうね。
両方使って幸せになってるヤツならそりゃ言うだろう。
ちゃんと>>354を見な。圧倒的に使わないヤツが多いわけだから（推測だが明らか）、
そのおかげで不便を強いられてるなら VCL を優先させるのは当然だろ！

>「自分が思ってる意見を言う」だけなら小学生でもできますって。
>まず Readme くらいよんであげなよ。自分の頭が悪いことを
>長々と書き連ねるな。見苦しい。
ここは意見を言う場なのだよ。見たくなければ見なきゃいいだけのこと。

>>358
2ch って意見を言う場だったんですか？匿名がなれ合う場じゃ無かったんですかね？
便所の落書きも意見ですかね？

単に頭に浮かんだことを垂れ流してもそれを意見とは言わないものです。

>>359
言葉の定義で揚げ足取りかよ、おめでてーな。

終わりか？ >> 358
揚げ足取られて逆切れするな。ガキめ。

Delphi6 がでて半年経っているけど ML でも news でも 2ch でもだれも話題に
していないのはなぜだと思う？ちょっとは冷静に周りを見回してみろよ。
あんたが不満に思っていることが, ほとんどの人にとって取るに足らないこと,
すでに解決済みの事だったりするんだよ。もちろんすべてがそうとは言わないが。

この一点のみで, あんたの意見なるものは便所の落書きに決定。

>>361
358≠360

ここは言葉の汚い fj ですか？

>>353-354　既出だと思うけど
ヘルプ-カスタマイズでCLX関係を削除すればいいだけのこと

どっちもどっち。いい加減にしなさい。

README.txt の以下の項を読んでくれな。

注意事項:
オンラインヘルプ

CLX ヘルプ参照のリンクを解除するには
[Enterprise 版および Professional 版のみ]

>>361のﾚｽも便所の落書きに一票
無論ｺﾚﾓﾅｰ

実際に使われる頻度は少なくても
Borlandのクロスプラットホーム開発環境を作れる技術力の
アピール、Linuxを利用した
Borlandツールのマーケティング戦略には
非常に効果があるのがCLXだと俺は思いマフ

￣￣￣∨￣￣￣￣￣
　　　∧,,∧ 　　VB/VCには絶対ﾏﾈできない
　　ミ,, ﾟДﾟ彡　ことが出来るというのはいい事だよ
　　 〃つ旦O
　〜ﾐ,,［￣￣￣.］ だから二系ｿﾌﾄでも特集扱いなんだし。
　　　　 ￣￣￣
ｱﾊﾟｰﾁのDLLﾓﾁﾞｳﾙ開発でも
ASPを圧倒してくれたらいいんだけどなー(妄想)



ところで、
XPの小規模リリースの原則から言えば
Borlandの
「出来上がったものだけしか発表しない」
という、意味の無い"伝統"は
百害あって一理なしだと思う。

VSやC#のβをたくさんリリースするMSを
見習って欲しいんだけど、どう重います？

>>368
ボーランド製品 = 世間で言うところのベータ

ﾌｧｰｲ
|,,∧∩　実は俺もCLXとVCLﾍﾙﾌﾟ表示には
|Дﾟ彡 　あきらめﾓｰﾄﾞだったです。
|　ミ′ 　リードメに書いてあるとわ。
|　ﾐ
| U 　　誰に感謝すればわからないけど
　　　　ｻ〜ﾝｸｽｺ

>>368
Ｍ＄だけは見習ってほしくない。あんなヤクザな会社にだけはなってほしくない。
堅気の会社でいてくれ。というかもう既に影響されまくってる
気がするが。

>>368
サンセーイ。あとこまごましたもの（エキスパートとか）もちょくちょく出してくれると
嬉しい。

>>369
たしかにそれは言えてるかも。
初代Delphiの完成度の高さはピカイチだったが、
最近は金儲けに走ったせいなのかどうか、
ろくに品質テストもしないでリリースしてるんだろうな。
会社が製品リリース間隔が異常に短いのがやはり気になる。

> 会社が製品リリース間隔が異常に短いのがやはり気になる。
「会社が」の削除希望

>>373
内部関係者？

　　 ∧,,∧ 　　　
　　ミ,,ﾟДﾟ彡　　
　　ﾐ つ且~~　　　
〜ﾐ,,,,,,　,,ﾐ

β版で利用者にテストを兼ねさせるという事を
ほとんどやらないから、バグが多いのかも。

[cbuilder:33588] Re: C++Builder6?
にもかかれているけど

どうしてリリース計画を明らかにしない
という事にこだわるのかな。

新分野を開拓する画期的製品を
リリースしているわけでもないんだし。

…MSに新機能をぱくられるのが嫌とか？

>>376
ベータ版を公開してもバグレポートが帰らないから。です。
MS にしても Borland にしても、公開ベータはマーケ的宣伝以上の
物ではありません。

Delphi2はβ版ありませんでしたか？

>>377
つか、日本語でバグ報告してもさ、それを某が確認＆翻訳して本社に伝えるのは
大変なコストがかかりそうな気がする。

だから日本語環境は見捨てられていく...

やっとバグ報告が集まった頃にはもう次のバージョンになってしまう
(未知のバグがいっぱいの……)

Delphi5 Update2 出せ！

バグ集めても公開しないんじゃ直る日はこないな。
http://www.infonia.ne.jp/delphi/ ここも忘れられて久しい。

Delphi7 Wish List あげ

やっぱヘルプのことが言われたね。

なんか、あんなヘルプじゃ Copy の使い方を勘違いするとか言ってたな。
リファレンス部分でいちいち初心者を意識した冗長な書き方されたらうざいんですけど。
初心者は入門書読んでから出直せって感じ。

>385
正論だがそんなこといってるから
信者獲得&勢力拡大できないんだよ。

ヘルプか・・・やっぱりか・・・
まあ当然だろうな。

Delヘルプが使いにくいってのは、そういう事だったのねー。
Del使ってばかりいる人には気が付けないいい視点
MLの人が「文法文法」って言ってるのに萎えた。
彼らは他言語習得にマニュアルを活用したことないのかな。

サンプルが沢山載ってるのが
言語習得には確かに効果あり。

￣￣￣∨￣￣￣￣￣
　　　∧,,∧ 　
　　ミ,, ﾟДﾟ彡　
　　 〃つl⌒|⌒l
　〜ﾐ,,［￣￣￣.］
　　　　 ￣￣￣
VB使うときHELPの記述が少々変でも
サンプルコードで実行結果が予想できて
実にわかりやすかった事を思い出したYO.

＞彼らは他言語習得にマニュアルを活用したことないのかな。
先に言語リファレンスを通読します。その後サンプルコードと言語
リファレンスを対比しながら読みます。
ヘルプの各項目にサンプルが必要とまではいかないです。

>先に言語リファレンスを通読します。
だからこんなの↑基準にしてたらいつまでたっても今以上にはならないんだって。

ちょっとでもつまずくとすぐ止めてしまうような人間を基準に考えないと。

いや、正直、信者は要らない。
いろんな環境を普通に使える普通の技術者に使ってもらえればそれで良し。
現在そうなっているから特に広めなくていいよ

>>390
＞彼らは他言語習得にマニュアルを活用したことないのかな。
に一つのサンプルとして答えただけ。

すべての関数と手続きに簡単な例を付けるだけでいいと思うんだけど
Borland はやらないんだよねぇーーいつまでたっても……

M$みたいに売れてないから
そこまで手が回らないと思われ
Webで公開して有志に任せたらいいのに
最後に某がリリースすればよさげ

>>394
それやろうとして，結局誰もファイルを提供しないのでこけた実績あり。

>395
これだね。
http://www.freeml.com/ctrl/html/JoinForm/delphihelp

そう。編集システムのことばかり気にして崩壊。
途中から Borland 版ヘルプの逆コンパイルとか、かってに HTML ヘルプにして
公開しようとかって話になり、ライセンスの指摘を受けて確認したら案の定断られた。

オープンソース的プロジェクトの失敗の典型例。オープンソースが悪いと言うわけではないぞ。

UNISYS買収して、VCLでGIFをサポートするのはどぉ？

>>398
だれが買収すんだ？
おまえか？

結局全員クレクレ君ばかりで何事も上手く行かないのだ。

>>399
私はぁ、ボーランドの経営にタッチしてないので、買収できません〜

　　∧,,∧　 　　／
　 ミ,,ﾟДﾟ彡　＜　某社の人がﾘｰﾀﾞｰｼｯﾌﾟ発揮して
　 ,;ﾞ　　ﾐ　 　 　＼　作って欲しいサンプルのリストくらい
　ﾐ.　　ミ 　　　　　　見せてくれりゃいいのにネ
／゛゛゛゛
　　　　　　　　　　　今のまんまじゃ、何のサンプル作ったらいいか
　　　　　　　　　　　わかんねし。

　BorがUNISYSﾊﾞｲｼｭｳできるわけないのでは？
　会社規模だと、逆じゃないのかしら。

proだと　VCLソース見れば使い方のサンプル判るけど
入門者に優しくなければならない筈の std/Personalが一番優しくないからなあ・・・

前に、MLかなんかで、サンプル集だったか、見やすいヘルプだったかを
作るプロジェクトを立ち上げた人いなかったっけ？
どうなったんだろう。。。
もし、ポシャっていたら、Delスレ住人でプロジェクトを立ち上げようかとか言ってみるテスト。

それが >>396

>　　　　　　　　　　　今のまんまじゃ、何のサンプル作ったらいいか
>　　　　　　　　　　　わかんねし。
ヴぁか丸出し。こんな糞レスつけてる暇があったら、
サンプルのひとつでも書いてageてみろや。

　　　　　　∧,,∧l||l 　なんで煽られてるんだろ…
　　　　 　 ;ﾞ⌒ヽ彡　　
　　 　 〜ﾐ＿__ﾐ
　　　 ''" ""''"" "''
　　　　　　　　　　ｸﾜｯ
　　　　　　　∧,,∧l||l 　2ﾁｬｿで
　　　　 　 ;;ﾞミﾟДﾟ彡　　サンプルのひとつやふたつや
　　 　 〜ﾐ＿__ﾐ 　　　みっつやよっつや…
　　　 ''" ""''"" "'' 　20ッツくらいは書いてんじゃん！

今日もVBで
文字列のIndexが0から始まるか
1から始まるか忘れてたので
Mid$のヘルプみてヘルプ文はみてもどうせわけわかなので
Midのサンプルみて速攻、わかったです。

こういうヘルプがDelphiの
CopyやDeleteにも必要ってことっしょ。

with文の是非(1/3)

私は少し前までは主にC++、JAVA等をメインにプログラムを組んでいましたが
４ヶ月程前からObjectPascal(Delphi)での開発に携わるようになりました。
Delphiでの開発はVC++での開発で言語的にもWindowsアプリ開発に関する点でも
下地が結構あったのでそれほど苦労することはありませんでした。ただObjectPascal
にはC++等の他言語にはないユニークな仕様が幾つかあったので、そこらへんでは多少
とまどいました。「with文」もその一つです。with文以外のユニークな仕様に関して
は単純に慣れの問題だったのですがwith文だけは見れば見るほど、使えば使うほど、
考えれば考えるほどその存在に疑問を感じるようになりました。

そこで皆さんに質問があります。
それは、
「with文は是か非か？」
ということです。
ちなみに私は「非」です。主な理由は「メンテナンス性の点で様々な問題がある」
からです。以下でその問題の詳細を述べます。

＜メンテナンス上の問題点＞
１．ソースコードの解析が困難。
２．コードの再利用性。
３．他言語への移植性。
４．将来的にバグを生む原因となる可能性。

１．ソースコードの解析が困難。
with文を使ったソースコードは一件簡潔に見えるので解析もしやすいと誤解
される方もいますが、実際他人の作ったコードを読んでると変数や関数が
どのオブジェクトと結びつくものなのかを正確に理解するのは大変骨が折れ
ます。それどころか、自分の作ったコードでも思った通りの動作をしないこ
とがたまにあります。メーリングリストの過去ログなどでも「この文を何と
かwith文を使って書けませんか？」というのをたまに見かけます。そこまで
してwith文を使う必要がどこにあるのか・・・。

２．コードの再利用性。
これは解析が困難というのと同じような話ですが、私は（多分皆さんも）
既存ソースコードからのカット＆ペースト（以下C&P）を日常的に使用します
がwith文を使用しているソースコードのC&Pをした場合、まるで違う動作
をする可能性があります。

３．他言語への移植性。
前述の２つの問題点が複合したような問題点です。大量にwith文を使用して
いる（ネストしてたりもする）ソースコードを正確にwith文を使用しない
文章に書き直す自身は私にはありません。

with文の是非(2/3)

４．構造上の欠陥（将来的にバグを生む原因となる可能性）
１以上に深刻かつ致命的な問題点です。
これは例を使って説明します。
＜例＞
・先ず２つのクラスTCls1, TCls2があったとします。これらはそれぞれ
　別のユニットで定義されていたとします。

----------------------------------------------------------------
[クラスTCls1]
unit Unit2;

interface
uses Classes;

type
TCls1 = class
class function Func1( slst: TStrings ) : TStrings;
class function Func2() : String;
end;

implementation
uses Windows, Unit3;

class function TCls1.Func1( slst: TStrings ) : TStrings;
begin
result := slst;

with TCls2 do
begin
slst.Add( FuncA() );
slst.Add( Func2() );
end;
end;

class function TCls1.Func2() : String;
begin result := 'TCls1.Func2()'; end;
----------------------------------------------------------------
[クラスTCls2]
unit Unit3;

interface

type
TCls2 = class
class function FuncA() : String;
end;

implementation
uses Windows;

class function TCls2.FuncA() : String;
begin result := 'TCls2.FuncA()'; end;

with文の是非(3/4)←３ページではおさまりませんでした
・ここで以下の処理を実行します。
[処理]
var
slst : TStrings;
begin
slst := TStringList.Create();
try
TCls1.Func1( slst );
slst.SaveToFile('C:\Windows\Temp\Func1(1).txt');
finally
if( Assigned(slst) ) then slst.Free();
end;
end;
----------------------------------------------------------------

・上記処理の実行結果です。
[結果]（テキストファイルの内容）
TCls2.FuncA()
TCls1.Func2()

・さてここでTCls2の作成者が全く新規でTCls2の既存のメンバにも
関連性の全くない関数「Func2」を追加したとします。
TCls2 = class
class function FuncA() : String;
class function Func2(v: String) : String;
end;
class function TCls2.Func2(v: String) : String;
begin result := 'TCls2.Func2(' + v + ')'; end;

当然「実パラメータが足りません」のエラーが出てコンパイル出来ま
せんでした。TCls1.Func1のwith文中のFunc2呼び出しの部分で
コンパイラがFunc2をTCls2の関数として解釈しようとする
からです。このエラーはTCls2を使用しているソースを実際にコンパ
イルするまでは発覚しません。ただ、この場合はTCls1とTCls2の
Func2はそれぞれ引数リストが異なることからコンパイルエラーが
出るのでその時点で問題が発覚するのでまだ救いようがあります。

with文の是非(4/4)

・致命的なのは次のように名称も引数リストも同じというケース
です。
TCls2 = class
class function FuncA() : String;
class function Func2() : String;
end;
class function TCls2.Func2() : String;
begin result := 'TCls2.Func2()'; end;

・このコードではコンパイルエラーは出ません。前述の処理を実行
すると結果は以下のようになります。
[結果]（テキストファイルの内容）
TCls2.FuncA()
TCls2.Func2()
・２行目の出力が前回と異なります。このバグはTCls1とTCls2が
それぞれ別に開発されたコードである場合回避するのは非常に困難
です。
・実際このように名称も引数リストも同じ関数・プロシジャー
が作られる可能性がどの程度かはわかりませんが関数の名称という
のは通常その機能を簡潔にまとめたものになっていると思われる
ので全く有りえないとは言えないと思います。運悪くこのバグが
発生した場合、非常に発覚しにくいたちの悪いバグとなります。

以上がメンテナンス上の問題点です。

あと、さらに付け加えるなら「with文のメリット」はそれほどメリットがない
というのも理由の一つです。例えば「with文を使えば一行が短くてすむ」と
いうやつですが、こんなのは「行が長くなったなら改行を入れれば？」だし、
「with文を使えば階層が深いオブジェクトへのアドレス参照が一度ですむので
処理効率が上がる」というやつも「最深部のオブジェクトを参照する変数を
用意すればいいだけでは？」と思います。

結局メリット・デメリットを天秤にかければ圧倒的にデメリットの方に傾く
と思います。よって、
「with文の使用は絶対に"非"」
だと思います。

ML の感想文を書き写すなよな。

with 文も含め，状況によって使い分ける。それだけ。

使う前に天秤にかける意味はない。使いながらメリットが多ければ使う。
それだけ。議論の立脚点が違うのでこれ以上は議論にならず。

with って単なる構文糖衣A じゃないの？
プロパティの初期化にはよく使ってる。

俺はwith文はほとんど使わない。
それを人に押し付けようとはしない。
そして、読む気の失せる長文で人に相談しようとはしない。

withはオリジナルpascalからあるんだよ、文句はWirthに言ってくれ。

withはデータ利用の局所化を促すので最適化にいいんでなかったっけ。
しかし非("否"じゃないのか)とかいってるのなら、クラスのメンバでのselfや
namespace(unit name)も省略不可にしろとかいうのなら厳密性は高まるといえるだろうが。

ってのはともかくwithは、それを使ったほうが明らかに読みやすいと思う場面でのみ
使ってるな。
withっぽく縮めたいが紛らわしくなりそうなときは、ポインタの一時変数に代入して使うかな。

with はVCLインスタンスをその場で作って解放するなんて時には便利だけどね

例：
http://pc.2ch.net/test/read.cgi/tech/1009903617/143

このコードは
with TBitmap.Create do try
　　Width :=100;
　　Height:=100;
　　PixelFormat:= pf1bit;
　　Canvas.Ellipse(1,1,100,100);//円を描く
　　Canvas.TextOut(5,5,'こんにちは');
　　SaveToFile('temp.bmp');
finally Free; end;
とローカル変数を使わずに書ける
出来れば
with XX same Y do と書くと XXの別名が Yになる構文だったらもっといいな

ただ >>417のように書くと、デバックの時に苦労したりするから
完全に定型処理で　コナレタような場合限定だからね

┏━━━━━┯━━━━━
┃　 　 　 　 　 ｜
┃　 　 　 　 　 ｜
┃　　　　　　 ∩∩ 　
┃ 　　　　　 ∧ ∧　ｿﾚ ｺﾋﾟﾍﾟ ﾁｬｳ？
┃ 　　　　　ﾐ,,ﾟДﾟﾐ　
┃ 　　　　 　ﾐ　　ﾐ　ﾌｩ…
┃ 　　　 　　ﾐ　　ﾐ
┃ 　　 　　　ﾐ　　ﾐ
┃ 　 　　　　..Ｕ..Ｕ
┃ 　　　　　　　　
┃ ぶら下がり倦怠期

>>414
>そして、読む気の失せる長文で人に相談しようとはしない。
ごめんなさい。
>>415
>withはオリジナルpascalからあるんだよ、文句はWirthに言ってくれ。
たしかにそうです。ただ私としてはDELPHIではwith文を仕様不可能にしてほしいという
わけではなくてgotoのよう「文法の仕様としては含んでいるが極力使わないほうがよい」
という感じになってくれたらなーと思っています。
>>416
>withはデータ利用の局所化を促すので最適化にいいんでなかったっけ。
ポインタの逆参照が一回ですむというやつでしょうか？最適化に関してはあまり深い知識
はないので間違ってたら指摘してください。ちなみに、参照用の変数を用意して、
Obj3 := Obj1.Obj2.Obj3;
というふうにやった場合とwith文を使用した場合では最適化の点からみた場合、差はある
のでしょうか？ちなみに是非の「非」はこれでよいみたいです。
------------------------------------------------------------------------
で、基本的に問題点が１、２、３のみだったらここまで強硬な主張をするつもりはないし
適切な場面に限って使用すれば便利な場合もあるだろうと思います。ただ、やっぱり問題
点４の構造的な欠陥がどうしても無視できません。しつこいようですが例をあげると、
１．あなたがボーランドの提供するあるクラスを使ってプログラムを組むとします。
２．その後のDELPHIのバージョンアップでそのクラスにプロパティ又は関数が追加さ
れたとします。
３．あなたのDELPHIをバージョンアップしてさらに前述のプログラムもバージョン
アップしたとします。
４．あなたがプログラムに何も手を加えていなくてもコンパイルエラー又は不可解な
バグに悩まされる可能性があります。自プログラムでwith文の使用を停止する以
外に完全に防ぐてだてはありません（たぶん）。
と言う訳で将来的に保守する必要のあるプログラムなら無視はできないとおもいます。

>点４の構造的な欠陥がどうしても無視できません。
で、あなたがこのトラブルに遭遇した回数は？

羮に懲りて鱠を吹く。

>>420
　なんかC言語使いの移植性がどうとかばかり言ってる人と共通するニオイ

その４と似た問題は with使わなくても　例えばDeleteでも起きてるんじゃないのかな？

何があっても大丈夫なように
unit名まで完全修飾してますが何か？
type
　Boolean = 1..2;
var
　a: System.Boolean;
　b: Unit1.Boolean;

結局さあ　C言語ではローカル変数での構造体の初期化がその場で出来る機能

つまり
a={"AAA","BBB",123}

があるけど、
pascalでは　その代わりに with を用意したって事だと思うよ、その方が柔軟な事は確か

だから、初期化程度に利用したらいいんじゃないの？

>>417　のようなその場でインスタンスはその悪用みたいに感じるけどねね

var節でしか変数宣言できないPascalは文法レベルでのwithは必要だろう．
使うかどうかは別として．

>>409
with文の中で指定したクラス以外のメンバにアクセスするときは
そのクラスを明示するべきではないのか。
そんなコード書くのが悪い。

あなたがその問題点を理解しているなら、いくらでもそれを回避したコードは書けるだろう？
どんな道具でも使い方次第。

>>423
>その４と似た問題は with使わなくても　例えばDeleteでも起きてるんじゃないのかな？
？？どういう場合でしょうか？いまいち思い浮かびません。よろしかったら参考までに教えていた
だけないでしょうか？

>>427
>with文の中で指定したクラス以外のメンバにアクセスするときは
>そのクラスを明示するべきではないのか。
ということは、
with TCls2 do
begin
slst.Add( FuncA() );
slst.Add( TCls1.Func2() );
//又は slst.Add( self.Func2() );
end;
とするべきだということでしょうか？でもこの関数はTCls1クラスの関数だしFunc2も同じく
TCls1クラスの関数だから普通は明示的には書かないのでは？というかそれをやる（withで指定した
以外のオブジェクトのメンバへのアクセスは明示的に示す）ならwith文で書くメリットも薄くなる
ように思います。
>そんなコード書くのが悪い。
あれはあくまでも問題点を説明するためのソースなので実際私がそういうコードを書いているわけ
ではありませんが、実際あの手のコードはよく見かけます。

>>421
>で、あなたがこのトラブルに遭遇した回数は？
ありません。ただ構造上は発生しても何の不思議も無いなーと思います。潜在化しているだけで
実際には遭遇していても気付かないという可能性もあります。実際、この現象が発生する可能性
というのは確かに低いものだとは思います。（そのような報告を耳にしたこともないし・・・）
結局この問題点に関してＭＬやこの掲示板に投稿したりした結果の反応をまとめると、
・with文の乱用は良くないが適切な使いかたをするなら特に問題はない。
・というか必要だ。
まあ大抵の場合は条件付で「是」という考えのかたが多いみたいです。結局私が気にしすぎている
ということかもしれません・・・。ただ私は仕事でＰＧを書く場合は割と保守性に重点をおくほう
なのでやはり今後もwith文を使う気にはならないとは思いますが皆さんのご意見は大変勉強になり
ました。ありがとう御座いました。ちなみに今回私がここらへんの問題を考えたのは現在仕事で目
にするソースコードに無闇に深くて長いwith文のネストがあったりしたのを目にしたせいで「いっそ
のことwith使用禁止にしてくれ」と思ったことがきっかけです。そのためwith文の粗捜しをするよう
なひねくれた書き方・考え方になっている部分もあったかもしれません。

>>430
端から見てたが、>430が話の分かるタイプの人で安心した。
結局は、

■乱用は良くないが適切な使いかたをするなら特に問題はない。

なんだよねぇ。
つか適材適所というか。

with 文は　このような場所で短いサンプルを出すときに読みやすくて良い。

　　∧,,∧,,,,,,,,,,,,,,, 　　　　　／￣
　ミﾟДﾟ,,彡,,,,,,,,,,,,ヾ〜　 ＜ 　とにかく問題はﾌﾟﾛｸﾞﾗﾏ側だと
　　　U U """"UU　　 　　＼＿ ｵﾓﾜｰﾚ

似たような別な話ですが
PascalかDelphiかの構文では
thenの後にbegin endプロック無しでも1行書けたりします。
使い方によっては見やすいソースになるけど

変なソース書こうとと思えばかけます。
　if ... then
　　if ... then
　　　if ... then begin
　　　end;
　　else
　　;

ってのも許可されるはずだけど(はずだっけ？)
if と elseの対応がわけわかになって
混乱の元だから書くの避けたりしません？
後から読みにくいですし。

面倒でもこんな風にbegin endの対応を書くでしょ。
　if ... then begin
　　if ... then begin
　　　if ... then begin
　　　end;
　　end
　　else
　　begin

　　end;
　end;

withもそれと同じで
変なソースになると思った瞬間、withをアボーンしたり
with内で省略しないコードを書くのは
各々のプログラマの責任で、Delphi側の問題は何もないような気します。

withの問題で大騒ぎしてたら、C＋＋やVBでも同様に混乱の元になる
記述はいくらでもできるんじゃないでしょうか。

VBで
Dim A, B as Integer
と宣言して、Aがバリアント型、BがInteger型になってて
そのおかげで潜在バグが発生してたのには参ったけど、、、

>ちなみに今回私がここらへんの問題を考えたのは現在仕事で目
>にするソースコードに無闇に深くて長いwith文のネストがあったりしたのを目にしたせいで「いっそ
>のことwith使用禁止にしてくれ」と思ったことがきっかけです。

気持ちはわかりますが、出来の悪いﾌﾟﾙｸﾞﾗﾏの問題を
Delphiの責任にされちゃイヤン

長文ゴメンソ

>気持ちはわかりますが、出来の悪いﾌﾟﾙｸﾞﾗﾏの問題を
>Delphiの責任にされちゃイヤン
禿げ同意

そういやCで
int* a,b;
としてbがポインタになってくれないの嫌いだなあ。

出来の悪い人ほど、思ったとおりにいかない時に道具のせいにする。
誰もが通る道だ。430 さんもめげずに。単に使いづらけりゃ使わなきゃよい。

＞誰もが通る道だ。

　　　　　　　ヽ从／
　　　　　γ´￣ヽ(ヽ　←!! 禿げ
　　　　　 ミ；ﾟДﾟ彡
　　　　　ﾐ　 つ ﾐ　 　シク同意
　　　〜ﾐ　　　 ﾐ
　　　　　）ノ　ヽ）

with　より goto　や absolute が嫌じゃないのが不思議

それから　a[8.)　とか書けるって知ってた？

自慢したかったのか？
>[ は文字の組 (. に相当し，] は文字の組 .) に相当します。左カッコとアスタリスクの組み（(*）と右カッコとアスタリスクの組み（*)）は，左右の中カッコ（{ }
）に相当します。

>438

そんな書き方するやつとは仕事したくないと思わん？

同意

.Net 対応
ttp://www.borland.com/about/press/2002/net_platform.html

>>417

varが途中でも書けたらさらにいいな。(forのインデックスにも使えるし)

procedure A;
begin
　...
　var
　　Work: TBitmap = TBitmap.Create;
　begin
　　Work.Width :=100;
　　Work.Height:=100;
　　Work.PixelFormat:= pf1bit;
　　Work.Canvas.Ellipse(1,1,100,100);//円を描く
　　Work.Canvas.TextOut(5,5,'こんにちは');
　　Work.SaveToFile('temp.bmp');
　　Work.Free
　end;
　...
end;

>>443
　それは高速コンパイルの障害になりそうだから嫌

　with TBitmap.Create do
　try
　　Width :=100;
　　Height:=100;
　　PixelFormat:= pf1bit;
　　Canvas.Ellipse(1,1,100,100);//円を描く
　　Canvas.TextOut(5,5,'こんにちは');
　　SaveToFile('temp.bmp');
　Finally
　　Free
　end;
でいいじゃん。

>>442
ま、予想通りか。
C# にも対応するのかな？

>>438
しらんかった

>>444
高速な実行の障害になりそうだから嫌と.Net対応にもいってやれよ。

>>435
typdefでも駄目だっけ？

もともとvarブロックとbodyブロックを分けてるのはソースの全体を
調べなくても、ある変数の型が分かる（varブロックを見ればいい）
ってことじゃなかったっけ？今だとエディタの支援を受けられることが
多いからありがたみも薄れるかな。

C++ 風の必要なときに宣言する記法は、PASCAL だと入れ子関数/手続きとして置き換えることが
できる。

だいたい、ループ管理変数なんて非常に局所的にしか存在しないのだからまとめて一つの手続きに
仕上げた方が見やすい。

もちろん程度の問題だし、途中宣言できても文法的に破綻することはないとおもうけどね

>>450
破綻したコードは書きやすくなる。

>>449
変数の有効範囲が広い場合のﾃﾞﾒﾘｯﾄの一つとして「ﾃﾞﾊﾞｯｸ等のｿｰｽ解析時
に変数を追跡するべき範囲も広くなる」という点があると思う。
例えば、
　　　procedure ProcA;
　　　var a, b, c, d, e : Integer;
　　　begin
　　　　　（略）
　　　　　if( xxxx ) then
　　　　　begin
　　　　　　　　（略）
　　　　　end;
　　　　　（略）
　　　end;
だとProcAの全体を通して変数abcdeの追跡が必要になる可能性があるが、
　　　procedure xxxxxxx;
　　　var a : Integer;
　　　begin
　　　　　（略）
　　　　　if( xxxx ) then
　　　　　begin
　　　　　var b, c, d, e: Integer;
　　　　　　　　（略）
　　　　　end;
　　　　　（略）
　　　end;
てなかんじで書けたなら変数bcdeの有効範囲がifのﾌﾞﾛｯｸ内部に限定され
るのでその分ｺｰﾄﾞの解析も容易になるように思うのだがどうだろう。

んー、じゃあ、withの話からはずれてしまいますがfor限定で。

for I: Integer = Low(TheArray) to High(TheArray) do ...

元々Pascalはforを出たらIの値は保証されない文法ですから、
この方がスコープが値の有効範囲と一致していいと思うのですが。
(Adaなんかもループ変数だけはfor I in 1..10 doっていきなり書けますし)

ごめんなさい。Adaの例を for I in 1..10 loopに修正。

いやだから、それはこうやって書き直せるでしょ？
って話。C だとこの書き方ができないから C++ であの記法が入った。のではないかな？

　　　procedure xxxxxxx;

　　　　procedure yyyyyyy;
　　　　var b, c, d, e: Integer;
　　　　begin
　　　　　　　　（略）
　　　　end;

　　　var a : Integer;
　　　begin
　　　　　（略）
　　　　　if( xxxx ) then
　　　　　　yyyyyyy;
　　　　　（略）
　　　end;

++の付かないただのCでも、{ の直後ならどこでも変数宣言できますよね…

void func(void)
{
　...
　{
　　int a;
　　...
　}
　...
}

C++の、ブロックの先頭「以外」でも宣言可能な機能は、
コンストラクタが働くタイミングを制御したいから、ですね。
ObjectPascalでは自動で走るコンストラクタは無いので
(stringやVariantが空に初期化されるぐらい)、関係なしです。

ルーチンのネスト構造を考えた場合、
Cなんかでは「グローバルとローカル」の二段階しか無いですが、
Pascalは関数内関数によっていくらでもネストが効きますよね。
グローバルとローカルの関係を、「内側は外側を参照できる」として一般化したものが
Pascal系言語の関数内関数だと思います。

一方、途中宣言は>>452さんの言っているように、「使う範囲のみにスコープを限定する」ためのもので
用途が違うのでは無いでしょうか？(代用が効くのは確かですが…

関数内関数って、処理の流れが上に折り返すので、あまり読みやすく無いし。
( Adaは関数内関数とdeclareによる途中宣言を両方できるし

>関数内関数って、処理の流れが上に折り返すので、あまり読みやすく無いし。
これを読みやすいととるか読みづらいととるかの違いでしかないな。

>関数内関数って、処理の流れが上に折り返すので、あまり読みやすく無いし
別に関数の動作が分ってればわざわざその場で上に折り返して追う必要性を感じないが。
まあ、おざなりな関数名で説明もついてなければ追わざるえないけど(苦笑)

関数・モジュールに分割すると、処理の流れがバラけるので、あまり読みやすくないし。
トップのbegin/end.ブロックにすべて書くのがいいよね。

はいはい。

>>459
最後には GOTO 文まんせーとでもいうのか。
構造化言語を真っ向から否定するような発言しやがって。

>>459は俺への皮肉でしょうか

見にくい見やすいの話題を加えたのは俺のミスです。
後で考えれば論争にしかなりませんしね。すいません。

456で本当に言いたかったのは、
関数内関数と変数の途中宣言は、片方で片方を代用できるけれど、
本質的には用途が違うのでは無いか、ということなんです。

きのうProfessionalを買ってきてPersonalと入れ替えたんだけど、
Personalに比べるとコンポーネントの量が半端じゃないので
IDEの起動が３倍くらい遅くなってしまった

CLXとか使わない人ならPersonalの方がいいかもしれない

一部の人しか必要なさそうなコンポーネントがたくさん並んでるので
自分のいらないものは外しておこう

使わないパッケージははずす。が基本。
プロジェクトごとに管理できるかららくちん。

Personalならコンポーネント全部ロードしても大したことないから
コンポーネントの取捨選択なんて考えてもみなかったけど
Professional以上の版だと膨大なコンポーネントがついてるから
ちゃんと管理しないと大変

フィルターをスマートに書けるようにして欲しい
具体的に言うと、クラスのメソッドがコルーチンで書けるようなもの

クラスメソッドで
　Filter　だけをつけると　スタックをグローバルスタックではなく　その
　クラス内に取られたクラス内ローカルスタックを使う
　
　FilterInterface　という識別子をつけるとフィルター名となり
　　呼び出すとコルーチン切替を起こす

>>466
やりたければやりなさい
Delphiはそれを妨げたりはしません

>466
なんとなく面白そうだけど、それってどういうときに使うの？

>>468　フィルターって言ってるんだから　圧縮とかエフェクトを
　入力と出力をつなぐように書きたいんだろうと思うが？

つまり　関数Aで input() と 関数Bでoutput(c) と書いたら接続されて同期するって事でしょう
同期しないならFIFOバッファでいいだろうけど

コルーチンはOSの管理のせいでスタック切替で実現が難しくなってしまってるみたい
だから、ハードウエアスタックではなく　擬似スタックを使いたいのでしょう

Update Pack 2が落とせん
むちゃくちゃ重い

完全マルチプラットフォームな NEW Delphi が欲しい。

>>471 昔 JAVA-VM用のDelphiを作ってたらしいね。
　　今でもエラーメッセージにその名残が見つかる事が・・・という事は殆どリリース直前まで行ってたのかな

>>463
Professinalだけどコンポーネントほとんど使わんから
パッケージ全部はずしてパレットごと非表示にしてるよ。
でも起動はそんなに変わらんよ。スペック低い？

>>472
(　ﾟдﾟ)JAVA-VM用のDelphiを作ってた？
↓
(　ﾟдﾟ)・・・・。
↓
( ；ﾟдﾟ)・・・・。
↓
(#ﾟДﾟ)そりゃJBuilderだｺﾞﾙｧ

これとは違うの？
http://www.javadelphi.com/

>>472
(　ﾟдﾟ)JAVA-VM用のDelphiを作ってた？
↓
(　ﾟдﾟ)・・・・。
↓
( ；ﾟдﾟ)・・・・。
↓
(#ﾟДﾟ)そりゃC#だｺﾞﾙｧ

Delphi2Jじゃ Delphi2の日本語版になっちゃうよ。
それに、ObjectPascalをJavaに変換するだけみたい。

マルチプラットフォームなら死角が無いのにな。
ついでに１から設計し直して欲しい。
バージョンアップでVCLを変更しないで済むように
して欲しいな。

例えばドッキング。
TFormでやるんじゃなくて、コンポーネントでサポートして欲しかった。

　　　 ∧,,∧ 　　　／
　 _　ミ,,ﾟДﾟ彡_＜　　DelphiToJavaって意味では？　
.=| |==U==U=| |= ＼
　| |＠ﾐ　　ﾐ .| |
　| |　∪''∪　| |
　| |　　　　　 | |

> 例えばドッキング。
> TFormでやるんじゃなくて、コンポーネントでサポートして欲しかった。
Toolbar2000をBorland側の標準コンポとして登録して欲しかった。
そしたら、Indyみたいに日本語HELPがつくし。
フリーソフト系開発者魂をよりがっちりつかむ事ができるのに。

　　ageでいくか！
　　∧,,∧　　　 ／
　 ミ ﾟДﾟﾐっ　＜　ま。いまさらToolbar2000を取り込むのは問題あるだろうけど
　　|''Ｕ￣|　　　＼誰もが必要を感じそうな
　　|￣￣| 　　　　終了して再起動したら元の位置を保存するような
　/　　　　ﾞヽ 　　コードを自前で書かなければならないってのは
（ 　　ﾟДﾟ　　） 　VCL標準で対応してくれないかな。
人＿_＿＿ノ
Formなんか特に、その他各種コンポーネントでも
すべて対応してくれたらいいのに。

例えば
Toolbar2000はこれだけの記述で
Toolbarのドッキング状態を保存して復帰してくれる。

function AppIniFilePath: String;
begin
　Result := ChangeFileExt(Application.ExeName, '.ini');
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
　TBIniLoadPositions(Self, AppIniFilePath, 'toolbar');
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
　TBIniSavePositions(Self, AppIniFilePath, 'toolbar');
end;

や
procedure TForm1.FormCreate(Sender: TObject);
begin
　TBRegLoadPositions(Self, HKEY_CURRENT_USER, 'Software\My Company\My Program\Toolbars');
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
　TBRegSavePositions(Self, HKEY_CURRENT_USER, 'Software\My Company\My Program\Toolbars');
end;

どうして、こういう所の必要性はVCL開発の中に現れてこないのかしら？

VCLのドッキングでこんな関数だれか作ってません？

パッケージの管理をもう少ししやすくしてくれ・・・。

パッケージファイルでも{$IFDEF}等をサポートし、
一つのパッケージファイルで複数のDelphiのバージョンに対応できる
ようにしてほしい。

>>479
最初に言った奴が作るってことで。じゃ、フサギコよろしく。

　　,,,,,,,,,,,,,,,,∧,,∧　 　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
〜′,,,,,,,,,,ミ,,ﾟДﾟ彡 ＜　どうせ息詰まるからヤダ
　 UU"""" U U　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

感覚的なんだけど、多分
細かい事やろうとするとVCLバグに衝突して
俺には解決不能レベルの問題になってしまってストレスが増大すると思われ
なのです。

フリーソフトでVCLのドッキングツールバーで実装しているのある？

付箋紙2000はドッキング&フローティングしないっす。
ゾヌのカキコ用Windowのﾂﾙﾊﾞｰもドキ&フローしないし
なんかバグってる。

その悩む時間でToolbar2000の使い方を知った方が幸せなの。

プロジェクトグループを使った時に 同じユニットが含まれていて
プロジェクトによって{$IFxx} で　コンパイルオプションを変えていた場合
「全てのプロジェクトを再構成」すると、 どうもその場合別けが巧く機能しない場合がある

個別に再構成したら大丈夫だから

あそ。

コンポのイベントを　IDEがメッソドまで書いてくれるけど
あれを自作コンポ側でカスタマイズ出来る機能が欲しいな
たとえば

procedure TForm1.Edit1Change(Sender: TObject);
begin
with Sender as TEdit1 do begin
|
end;
end;
みたいな感じにとか　BCB両用にするのメンドクサイから駄目？

なにが

ぶっちゃけ begin 〜〜 end; より { 〜〜 } の方が見やすい。

>>486
イベントハンドラ用のプロパティエディタ作ればできる。

>>486
それ、面白い。

IFormUpdater を再実装すればよし。

>>489　そうなの？　優先順位付けられるくらいかと思ってた

>>486
コード本体部分まで自動生成はキモイ。カッタルイ。いいことないぞ。
消すの面倒だし。

世にあるDelphiのプログラムなんて、たまたま動いているだけ。
所詮クズ

>>494
はげしく同位

494 != 495

N88BASICは世界一ィィィィィィィィィィィィィィィィィィイイイイィィッ！

なんかこの板にジョジョっぽいヒトがいる。

言うとる場合かぁァァァァァァァァァァァァァァァァァッッッッッッッッ！　　　

Delphiはversion1ですでにいい意味において完成していたため。
その後、(今の経済の仕組みとしては)バージョンアップで金を取るのが
つらい感じ。
Turbo Pascal を書いていた人(名前どわすれした)が
マイクロソフトに逝ってしまって、J+とか虚しい言語の開発を
初めてしまったのも残念。

>>500
アンドリューヘジルスバーグ?

ガベージコレクションはあったほうがプログラマの気が楽になるかも。
(既出だったらごめん)

>>502　コンポーネントとインターフェースだけ使え

>>502
インラインアセンブラなどで現在ネイティブであることの幸せを噛み締めながら、Delphi.NETを待つ

( 実際のところ、自作メモリーマネージャーか何かでできないのでしょうか？GC )

>>504
　誰も参照していない事を検出するには、スタックからCPUのレジスタまで検索しなければいけない
　スタックは作られたスレッド全て検出しなければいけないしで、重い処理になるだろうね。

>>500
C#は空しく無いだろ。

>>506
C#がどんな言語か知らないけど、たしかに利用者は多くなりそうだね。
Delphi.NET って Borland がやると言っているの?

Delphi の「2Way-Tool」って誇張してるけど、あれは使えんな。みんなそう思うだろ。当然。
JBuilder のようにJavaソースコード修正したらフォームに反映されるようにしろよ！！！
知らないヤツは JBuilder みたいにできると勘違いするだろ！ボケ！！！

あともう一つ。
「コンポーネントをフォームにＤ＆Ｄする」って表現やめろよ。
知らないヤツはＤ＆Ｄ操作して貼り付けると勘違いするだろ！ボケ！！！

まだあった。
「エリアス」ってなんだ？？？
Alias = エイリアスだろ！ボケ！！！！
某日だけだぞ。そんな言い方するのは。世間一般の言い方と統一しろよな。

以上です。

>>508
出来るぞ？己の文法エラーで騒がんでくれるか？

そんなことより、Delphi.NETはどうした?
漏れは心配で眠れんよ!

>>508
「某日」ってなんだ？

>>510
まだまだ先。D7の次くらいじゃなかったっけ？
それまでゆっくり寝とけ。体に悪いぞ。

>>511
Borland Japanでは？＜某日

>>512
おお、そういうことか！ ｻﾝｸｽｺ

>>508
ＶＢ使ってろよ！ボケ！！！

漏れはBorland C時代からC++を経てDelphi 3か4あたりまでずっとボーランドの
ファンで(今もそうだけど)正規ユーザでした。
Delphiのversion1が発表されたときは、柄にもなく非常に興奮して、これでVBは
確実に逝くなと思ったものでした。
しかし、そのころNiftyに顔を出していた Borland の大野さんという方が
「売れるには売れたけど、最初に思ったほどｳﾞｧｶみたいには売れていない」と
言っているのを聞いて、なかなか難しいものなんだなと思っていますた。

最近、2chにくるようになって、Del厨とかいうことばを見るようになって、
やっとDelphiが今の若い人たちに広がりだしたんだなと思ってうれしくなりますた。

ちなみに大野さん(元もとはゲームプログラミングをしていたと聞きました)という方は
いまでもBorlandにいらっしゃるのでしょうか? (Borland Japanの社長だったりして)

>>515
まだいると思う。
以前はMLにも顔を出していたが、最近はみかけない。