5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:01/09/26 03:23
Delphi を使ってみて、ここがダメ、この方が使い易い、あるいは今後こういう機能が必要、
等々何でもいいから日頃あなたの思っていることを正直にカキコして頂戴。(初心者歓迎)
なお、Delphi 未使用者の冷やかし発言は御遠慮願います。

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

3 :デフォルトの名無しさん:01/09/26 03:30
Delphi.NETがあればいいんでないの。

4 :デフォルトの名無しさん:01/09/26 03:42
大野さんは見ているの?

5 :デフォルトの名無しさん:01/09/26 04:16
>>1の存在そのものが冷やかしなんじゃないの?

6 :デフォルトの名無しさん:01/09/26 04:20
>>5
うるせーよ。氏ね。
おもしろいと思ってんの?

7 :デフォルトの名無しさん:01/09/26 04:27
6=大野元久

8 :6:01/09/26 04:30
釣れた!!!

9 : :01/09/26 04:44
7=安藤由男

10 :5:01/09/26 05:15
大野って誰?

11 : :01/09/26 05:46
Delphi関係の人って、どうしてこうポコポコとスレ立てたがるの?

12 :デフォルトの名無しさん:01/09/26 05:51
>>11
だって<以下自粛>

13 :デフォルトの名無しさん:01/09/26 06:06
スレがたくさんあると、どこにレスつけたか忘れるぽこ〜。

14 :デフォルトの名無しさん:01/09/26 07:57
Delphiの付くスレッド全部消去してはどう?

15 :デフォルトの名無しさん:01/09/26 08:11
>2 HTML埋め込み対応希望

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

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

16 :デフォルトの名無しさん:01/09/26 09:40
.NETに統合されることで最強になると思うんですが。

17 :Delギコ:01/09/26 10:04
>無意味な長文投稿や仕切り屋が

          ∧ ∧
         Σ(,,゚Д゚)
          / |   ソレ オレ ノ コト ジャン
      ,, ,,,,  (_,ノ ,,, , ,,
          ノ ,,

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

18 :デフォルトの名無しさん:01/09/26 10:08
>>11
Delphi厨つぶし野郎の陰謀だよ。
VBがどうのこうのってスレ立ててるやつとたぶん一緒・・・

19 :Delギコ:01/09/26 10:08
      昇天
  ∩   ∩_     / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
〜⊂ ̄ ̄ (。Д。)⊃ < 誤爆りました・・・
  ̄ ̄ ̄ ̄∨∨ ̄ ̄|\_____________

  ア・アボーン シテオイテ チョーダイ

20 :デフォルトの名無しさん:01/09/26 10:40
Delphi.NETはまだですか?

21 :デフォルトの名無しさん:01/09/26 10:42
C#に改名しましたが?

22 :デフォルトの名無しさん:01/09/26 11:04
Java&C# メモリの解放はコンパイラが自動化する。
C++ メモリの解放はプログラマ次第で自動化できる。
Delphi メモリの解放を自動化することは不可能。

23 :デフォルトの名無しさん:01/09/26 11:30
Delphi UNIT
Modula-2 モジュール
JAVA パッケージ

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

24 :デフォルトの名無しさん:01/09/26 11:37
>>22
それってマジ?
Delphi.NETが最後の希望の光だと思うんだけど・・・

25 :デフォルトの名無しさん:01/09/26 11:55
不可能じゃないと思うよ。

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

26 :デフォルトの名無しさん:01/09/26 12:16
関連レス↓
http://mentai.2ch.net/test/read.cgi?bbs=bsoft&key=998629435&st=30&to=31

27 :コピペ:01/09/26 12:19
一人の天才がすべてを作っていると?

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

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

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

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

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

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

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

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

29 :デフォルトの名無しさん:01/09/26 12:48
>それってマジ? Delphi.NETが最後の希望の光だと思うんだけど・・・

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

30 :デフォルトの名無しさん:01/09/26 13:41
.NET非依存の C#開発ツール出してくれ>某

31 :2:01/09/26 14:02
>>15

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

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

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

32 :デフォルトの名無しさん:01/09/26 14:24
>>22
またまたあ(藁

33 :デフォルトの名無しさん:01/09/26 14:27
>.NET非依存の C#開発ツール出してくれ>某

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

34 : :01/09/26 14:27
VC++のエディタみたいに自動で段落がずれるようになってほしい。

35 :デフォルトの名無しさん:01/09/26 15:40
>>22
Stringってどうしてんだよ。

36 :デフォルトの名無しさん:01/09/26 15:45
.NET 好きが多いけどみんなはMS派かい?
おれは Delphi の .NET化に興味なし。
.NET したければ C# 使えばいいことだよ。

37 :デフォルトの名無しさん:01/09/26 15:57
>.NET 好きが多いけどみんなはMS派かい?

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

38 :Delギコ:01/09/26 15:59
    ∧ ∧   />>22
  ∩(,,゚Д゚) <  ガベコレのことでしょ?C++で出来るの?
⊂,,⌒ ,,つつ.  \Javaでもガベコレに頼ると
   ̄ ̄             結局動作が遅くてイヤだという噂もありますが…
    ∧ ∧   / ̄
  ∩(,,゚Д゚) <  確かにDelphiスクリプトは標準であったらベンリ。
⊂,,⌒ ,,つつ.  \ 是非に。Borlandに真剣になってもらいたー
   ̄ ̄  
   ∧∧   />名前空間機構を導入してほしいということ。
〜''~(,,゚Д゚) < 欲しい欲しい
  UU'UU    \
   ∧∧   />.NET したければ C# 使えばいいことだよ。
〜''~(,,゚Д゚) < つまりJavaを使えと・・・
  UU'UU    \いうことですか....

39 :デフォルトの名無しさん:01/09/26 16:32
>>38
確かにC++にはガベコレはない。
しかしプログラマに実力さえあれば、粘着質のように究極の安全性を追求できる。

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

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

40 :39:01/09/26 16:34
>>22ではなく>>35の間違い。

41 :デフォルトの名無しさん:01/09/26 16:50
>確かにC++にはガベコレはない。
>しかしプログラマに実力さえあれば、粘着質のように究極の安全性を追求できる。

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

42 :41:01/09/26 17:18
念のためだけど、deleteがあること位知ってるからね。

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

43 :デフォルトの名無しさん:01/09/26 17:23
>>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;
 }
}

44 :Delギコ:01/09/26 17:46
http://www2.big.or.jp/~osamu/Delphi/delphi-browse.cgi?index=041720
  ∧ ∧    /
  (,,゚Д゚)  <  ナカムラ先生タンもがんばっておられるようです。
  |⊃ ,⊃   \ 解決してるのかな。このスレッド…
@|  |       ダレカ(奥)サマリーつくってくれ
  ∪∪
  これだけガベコレが流行るんだから。Delもなんとかして欲しい。

45 :デフォルトの名無しさん:01/09/26 18:59
>>39
interface知らない?

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

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

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

46 :デフォルトの名無しさん:01/09/26 18:59
よく考えたらコンポーネントは自分で開放してないね。

47 :デフォルトの名無しさん:01/09/26 19:04
>>44
これもおもしろいな
http://leed.issp.u-tokyo.ac.jp/~takeuchi/delphi/browse.cgi?index=041732

48 :デフォルトの名無しさん:01/09/26 19:24
BDE はもういらないんじゃないかい。
いまどき Paradox も dBASE もしないだろうに。
それより BDE 経由しない ODBC の TDataSet がほしいな。
極力余計なライタイム不要な方向にしてくれ。>某

49 :デフォルトの名無しさん:01/09/26 19:34
>クライアントサイド最強の Delphi
ハァ?

50 :デフォルトの名無しさん:01/09/26 19:43
>>49
ほっとけ。隔離スレの意味がなくなる。

51 :Delギコ:01/09/26 22:12
>>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  カクリ スレ ナノ?
 〜(__n n[ ̄ ̄ ̄.]
         ̄ ̄ ̄
 もっとワクワクするネタくださいな。
クライアントサイドならC#にも負けないよ
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1001489683

 隔離スレを利用して最強をアピールしとこかー。

52 :1:01/09/26 22:20
http://www.f2.dion.ne.jp/~impact14/

53 :デフォルトの名無しさん:01/09/26 22:26
デフォルトの名無しさんがデルファイの名無しさんに見える

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

54 :デフォルトの名無しさん:01/09/26 22:44
>Delphi for .NETとか言ってる奴は単にDelphiのIDEがタコなんで
Ver.Up するたびに Delphi IDE のウィンドウが増えてきてて
XGAじゃ見づらくなってるからそろそろIDEのモデルチェンジを
してもらいたいね。
だからといって別にC#をしたいとは思ってないが。

55 :Del厨:01/09/27 00:00
正直ネエィティブコンパイルさえしてくれれば俺はC#にうつるぞ。

56 :デフォルトの名無しさん:01/09/27 00:28
>>55
・・・

57 :デフォルトの名無しさん:01/09/27 01:10
クライアントサイド最強なんてのは実績を残してから言え

58 :sage:01/09/27 02:46
OS の威光だけで生き残っているバカ言語。とっととくたばれ。

59 :デフォルトの名無しさん:01/09/27 02:47
>>58
VBのことかな?(プ

60 :デフォルトの名無しさん:01/09/27 02:53
For I = 1 to 10
って書いたときのエラーメッセージが
[for 文の制御変数はローカル変数でなければなりません]
ってのはどうにかしてもらいたい。

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

61 :デフォルトの名無しさん:01/09/27 02:54
デファイルは糞

62 :デフォルトの名無しさん:01/09/27 03:20
Rubyの次はDelphiか。。。

63 :デフォルトの名無しさん:01/09/27 03:59
>60
ワーニングじゃなかったかな?
コンパイルは可能。
でも、なんで出るのでしょうかねぇ〜?

64 :デフォルトの名無しさん:01/09/27 04:41
>>63
うぅ。分かってもらえない。
For I := 1 to 10
が正解。腹が立っているのは,:= と = を打ち間違えた事を指摘してくれないから。
(I = 1) という論理型の式がある。と判断して(これは正しいんだけど)
意味不明のエラーをだしちゃう。それが嫌。

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

66 : :01/09/27 05:04
ヘルプにはこうあったよ!

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

for i = 1 to 100 do
begin
end

67 :デフォルトの名無しさん :01/09/27 05:08
正直、WindowsのDelphiはもういいから
kylixネタを頼むよ。

68 :デフォルトの名無しさん:01/09/27 05:29
KylixはDelphiとの互換性なんて無視すればよかったのに。

69 :デフォルトの名無しさん:01/09/27 08:02
まずは勘違いCUI厨房の啓蒙活動からやらないと勝ち目ないかも>Kylix

70 :デフォルトの名無しさん:01/09/27 09:12
どのあたりの互換性が悪いの?>>68

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

71 :デフォルトの名無しさん:01/09/27 10:47
>>70
互換性を考えずに理想を追求して欲しかったということでは。
確かにコンポーネントをinterface化して欲しかった。

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

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

72 :デフォルトの名無しさん:01/09/27 11:14
Linuxの開発環境って教えて欲しいな。
まさか、標準で入っているccコマンド(確か、k&r)で開発なんかしないよNE?

73 :大雑把にまとめてみると:01/09/27 11:24
Delphi 使い)
・チャレンジ精神旺盛な人たち
・利用者のスキルレベルは低〜高までさまざま
・主に個人的ユーザが多く熱狂的なコミュニティが構築されている

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

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

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

74 :デフォルトの名無しさん:01/09/27 11:56
>>72
ccつーかgcc。だけど開発環境と言うか言語だわな。

75 :デフォルトの名無しさん:01/09/27 12:52
gccなのか。画面ツールとか何使うんだろう。リソースファイル手書きですか?

76 :デフォルトの名無しさん:01/09/27 12:58
>>75
普通は全部手書き。
Gtk+ 用の RAD ツールとして glade というのはある。
X-Windowアプリのリソースファイルは手書きで十分。

77 :デフォルトの名無しさん:01/09/27 13:00
それって、リソースバリバリのDelphiアプリに見劣りしないの?>>76
それとも、Linux使う時点で、画面に期待されてないとか。
でも、Linuxでもoffice互換ソフトとかあるんだよねぇ。star officeだっけ。

78 :デフォルトの名無しさん:01/09/27 13:09
なぜ、GUIをリソースファイルを使って書く方が優れると考える?

79 :77>78:01/09/27 13:31
リソースファイルの方が劣るよ。
Delphiはリソースファイルじゃなくて、独自dfm形式だよ。
リソース(標準コントロール&独自コンポーネント)を
バリバリに使っているって意味。

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

81 :デフォルトの名無しさん:01/09/27 14:47
解釈1:リソース=資源一般
解釈2:リソース=Windowsのリソースファイル

>リソースバリバリのDelphi

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

82 :デフォルトの名無しさん:01/09/27 15:04
素直に読んでね>>81

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

83 :デフォルトの名無しさん:01/09/27 15:06
リソースファイルであろうと、DFM形式であろうと、
実行時はAPIコールなんだから実質同じ>>80

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

84 :名無しさん@Emacs:01/09/27 15:46
>>83
出来上がるものは同じだよ。TMTOWTDI!
かかる手間が違うだけ :-)

85 :デフォルトの名無しさん:01/09/27 16:58
>>84
手間がかからないほうが、よりよいインターフェイスのために試行錯誤したり、
適切な仕様変更を施したりすることが気軽になって、
完成度が上がるんじゃないか?

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

86 :Delギコ:01/09/27 17:38
  ∧∧     / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  (,,゚Д゚)  < ぷっはー。
 ヽ/つ且~~  \___________
  (__ _)

>>352さん情報サンクス

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

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

    ListBox1.Items.Add(S);

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

87 :Delギコ:01/09/27 17:40
        ∧ ∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
〜′ ̄ ̄(;TДT)< また書き間違えた。ゴメン
  UU ̄ ̄ U U  \_____________
 モウアキラメヨ…

88 :デフォルトの名無しさん:01/09/28 02:17
パッケージファイル内で{$IFDEF} を使えるようにして欲しい。

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

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

91 :89:01/09/28 10:56
旧バージョンをダウソして実行してみたけどバージョンは戻らないな・・・
鬱です。

92 :Delギコ:01/09/28 10:58
        ∧ ∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
〜′ ̄ ̄(;゚Д゚)< イヤ・アノ・ソノ・・・>>90
  UU ̄ ̄ U U  \_____________
  純粋にこのページでやってることをパクってみたかっただけなんです、、
  http://www.atmarkit.co.jp/fdotnet/csharptips/002anchor/002anchor.html

  このサイト書いた人に"イベントログなんて読む必要ねーんじゃ(゚Д゚)ゴルァ"って
  逝ったほうがいいでしょうか....たちのわるい読者になてしまいそうです。

93 :デフォルトの名無しさん:01/09/28 12:44
Del6.Delphi初めて使ってみたけどおもしろーい。
C++直接通るならイカスぜ。

94 :デフォルトの名無しさん:01/09/28 12:57
>C++直接通るならイカスぜ。
え、C++コードは通らないZO!

95 :デフォルトの名無しさん:01/09/28 12:59
>>93
それはBuilder

96 :89:01/09/28 14:23
取り合えずBDEINST.CABからBDEINST.DLLを取り出して
TREGSVR.EXEと同じフォルダに入れ、バッチで、

TREGSVR -q BDEINST.DLL

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

97 :デフォルトの名無しさん:01/09/29 15:01
>>94 >>95
いや、直接通る'なら'イカスんだから、
通らないDelは糞、これ、定説。

98 :デフォルトの名無しさん:01/09/29 15:53
その意見が糞というのはあり得ないのか?>>97

99 :デフォルトの名無しさん:01/09/29 16:24
>>98
あたりまえでしょ

100 :Del = 軽量:01/09/29 16:56
>>97
BCB に Obj.Pacal コンパイラが搭載されてるように
Del にも C++コンパイラが搭載されていればうれしいが、
処理が重くなるのはやだっ。

101 :デフォルトの名無しさん:01/09/29 17:29
Delphi.NETはまだですか?
出たら触るつもり。

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

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

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

以上

103 :デフォルトの名無しさん:01/09/29 20:22
>>102
素直にvisioを使えとクライアントに言え。
図を編集してデータを出力するようなことをしたければ、
visio+VBAを使え。

104 :デフォルトの名無しさん:01/09/29 20:24
で,ケイスケの勤める会社。
http://www.land-grp.co.jp/trip.html

105 :デフォルトの名無しさん:01/09/29 21:09
コンテナでVisioを埋め込むとか
http://www.devexpress.com/products/vcl/product.asp?ProdID=12
を参考にするとか
線だけならFree

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

107 :デフォルトの名無しさん:01/09/29 21:28
あのさ,
>.NET 化すると
>(1) VB, C# などから Delphi で作ったクラス等を使えるようになる
>(2) (1) の逆
これができるといっている,論拠は何?

108 :デフォルトの名無しさん:01/09/29 21:31
それが.NETとういう物なんだよ

109 :デフォルトの名無しさん:01/09/29 21:43
1 の提案に戻って、Delphi6 のバグでもまとめないか?

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

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

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

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

110 :デフォルトの名無しさん:01/09/29 21:54
がんばれ人柱。

111 :デフォルトの名無しさん:01/09/29 22:56
>>102
げ某MLにも同じ質問が...

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

113 :デフォルトの名無しさん:01/09/29 23:43
>>111
MLからだれかコピペしただけかと。

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

114 :デフォルトの名無しさん:01/09/30 00:29
Delphi1が一番美しい。

115 :デフォルトの名無しさん:01/09/30 00:46
>Delphi1が一番美しい。
そうだね。一番完成度が高かった印象がある。
Win3.1で唯一無二の最高作だよ。
もう一度初心に返ってもらいたいものだ。>某

116 :デフォルトの名無しさん:01/09/30 01:13
>>112
今度のはCLXの関係で特にひどそう
でもアメリカでは許容範囲かもね

117 :デフォルトの名無しさん:01/09/30 01:27
>>112
Proxies ユニットが無くなったのは Delphi4 から。2/3 との互換性を考えて
ソース/ユニットが提供されていたのにガイドラインに従わずにいたコンポーネント作者の
怠慢は問わないのか?

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

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

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

120 :デフォルトの名無しさん:01/09/30 01:52
ドッキングなんかは、コンポーネントにして欲しかった。
フォームにドッキングコンポを載せると、フォームがドッキング可能になる。

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

122 :デフォルトの名無しさん:01/09/30 01:58
IDEとコンパイラ+VCLを分離するとどうなるの?

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

124 :デフォルトの名無しさん:01/09/30 02:15
>>122
>IDEとコンパイラ+VCLを分離するとどうなるの?
言ってる意味がわからないんだけど。
IDEあってのVCLでしょ。
IDEがなければVCLの意味がない。

125 :デフォルトの名無しさん:01/09/30 02:30
>124
Delphi6のIDEでDelphi3で開発していたプロジェクトを
コンパイルしたいわけです。
VCLやコンパイルをバージョンアップすると、あらたなバグが
潜む可能性があるからねっ!

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

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

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

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

127 :デフォルトの名無しさん:01/09/30 02:53
>126
>Delphi3コンパイラ + Delphi6VCL の組み合わせ
IDEと(コンパイラ+VCL)の組み合わせです。

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

128 :124:01/09/30 03:04
>>127
納得。
IDEだけ最新もの(拡張されたいろんな機能)を使いたいということだね。
そうなれば JBuilder みたいだね。JBuilder は JDK バージョンを切り換えられるから。

129 :127:01/09/30 03:30
127の訂正:プロジェクトを→プロジェクトの

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

130 :デフォルトの名無しさん:01/09/30 03:42
>>126
>それよりすべてのバージョン互いに干渉しないように同一PC内に
>同居できるようになった方がいいと思うが。

できるよね?

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

132 :デフォルトの名無しさん:01/09/30 03:53
>>126
前に、Delphi1〜Delphi5まで一緒のPC(OS)に入れていたよ。
Delphi3は入れなかったけど(3.1は入れた)
全部ちゃんと動いていたよ。
この前、OS入れ替えたので、今はDelphi6しか入ってない。
#ボランドってバージョンアップしても前の製品のライセンス消えないよね?

133 :デフォルトの名無しさん:01/09/30 04:22
>>106
>.NET 化すると
>(1) VB, C# などから Delphi で作ったクラス等を使えるようになる
>(2) (1) の逆
>このくらいだと思うが、おれには得に便利になるわけではない。
>それともほかに何か理由があるのかい?

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

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

134 :デフォルトの名無しさん:01/09/30 05:08
>それぞれで作ったコンポーネントが、再コンパイルや改変なしに
>相互利用できる

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

135 :デフォルトの名無しさん:01/09/30 07:11
Delphiスレはどんなものであっても長続きするのか?

136 :デフォルトの名無しさん:01/09/30 10:38
オレはむしろC#-.netがほしい・・・
それかBorland C# Builder(藁

137 :デフォルトの名無しさん:01/09/30 10:54
MS製品の中核が.Netに移行する以上はいずれ対応する日がやってくるんじゃないかな?
どっちにしろ、今はDel使うからイイや。当分OSもWin2kで行くつもりだし。

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

139 :デフォルトの名無しさん:01/09/30 11:04
>>134
もしかして、ActiveXと呼ばれていたもののうち、
実際に何がどれくらい使われているか知らないのかな?

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

140 :デフォルトの名無しさん:01/09/30 11:12
>>136
C# 使いたければ VisualStudio.NET でいいんじゃない。
Delphiライクにフォームにコンポを貼り付けてアプリ作れると思うから、
わざわざ Borland が同じようなものを作る必要はないと思うけど。

141 :デフォルトの名無しさん:01/09/30 11:16
>140
136がいってるのはネイティブコードにコンパイルできるC#ってことじゃないの?

142 :デフォルトの名無しさん:01/09/30 11:28
>>141
出来るに越したことはないが。
それならば Delphi 同様余計なランタイムがいらない .exe ファイルのみでも
OKにしてもらいたいが、無理のような気がする。

143 :デフォルトの名無しさん:01/09/30 11:51
>>140
>>136 じゃないがWindows & Linux対応のC# Builder求む。
Delphi & Kylixと同じようなもの。
Javaほど遅くないからネイティブにはこだわらない。
別にそうであってもいいが。

144 :デフォルトの名無しさん:01/09/30 11:58
エンドユーザーアプリならネイティブにする必要ないじゃん。

145 :デフォルトの名無しさん:01/09/30 12:07
Delphi のよいところは軽量コンポをサポートしているところ。
(軽量コンポ = TGraphicControlのサブクラス)
重量コンポと同様に扱えるようなしくみにした点には脱帽。
ということでVCL最高!

146 :デフォルトの名無しさん:01/09/30 12:11
>エンドユーザーアプリならネイティブにする必要ないじゃん。
遅いより速い方がいいでしょう。

147 :デフォルトの名無しさん:01/09/30 13:58
バグがなく仕様が完全に満たされているか、
インラインアセンブラが使えるか、どっちか満たしていればいいや。
じゃないとゲームに使えん。

148 :デフォルトの名無しさん:01/09/30 14:59
>>145
軽量コンポーネント、フォーカスをもてないのがちとつらい。

149 :デフォルトの名無しさん:01/09/30 19:31
>>147
Delでゲーム作る?正気か?

150 :デフォルトの名無しさん:01/09/30 19:46
>>149
またそうやって脊髄反射で書き込みをするぅ。

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

152 :デフォルトの名無しさん:01/09/30 20:09
最初からマシンコードで書けば良いだけの話

153 :デフォルトの名無しさん:01/10/01 14:37
>>149
作ってた人はいたけどね。未完のままサイトが閉鎖されたけど。

154 :デフォルトの名無しさん:01/10/01 19:07
>>147
Del用のDirectXコンポ使えば。
今どきアセンブラでゲーム作ろうとしてるやつはアホだぞ。

155 :デフォルトの名無しさん:01/10/01 19:43
(!! 154 はアホなので無視してください!!)

156 :デフォルトの名無しさん:01/10/01 19:54
         ∩
         //
        //
        |:| Λ_Λ  / ̄ ̄ ̄ ̄ ̄
        |:|( ´Α`)< うるせー馬鹿!
        |:|_):∵:(   \_____
        \:∵:∴:\
          |∴:∵ l::|
          |∵:∴ |::|
         /∴:∵/|::|
         |ii;∵;i/ |:|
         |llll||lll|  U
         |llll||lll|
         /ll/ |ll|
        /l/  |ll|
        /l/  |ll|
       /l/   |ll|
      ν    ν

157 :デフォルトの名無しさん:01/10/01 20:51
>>149
スミマセンそれオレです

158 :デフォルトの名無しさん:01/10/01 20:54
DBエクスプローラについて)

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

159 :デフォルトの名無しさん:01/10/07 00:37
デルファイのエディタで、検索を行うときに、Shift + F3 で逆方向へ検索してほしいな。

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

161 :デフォルトの名無しさん:01/10/07 00:50
今後を考えればC++はないだろ。C#/Javaっぽいのが良い
ぃぬ厨がより高級な言語を理解できるとも思えんが

162 :デフォルトの名無しさん:01/10/07 00:51
>>160
でもC++とDelphiのコンパイル・ビルド速度が愕然とするほど違うんだよなあ。
(Delphiのほうがはるかに速い)
両方やるとC++がつらい…

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

164 :デフォルトの名無しさん:01/10/07 01:18
>>161
C#はどうだろ?モノは良くともMSしかやらなそうだもんなぁ。
Red hatパッケージにでも入らん限りBorlandは黙殺だろ。
JavaもLinuxブレイク以前はアンチMSの支持集めてたけど
今はimodeくらいしかパッとせんし。

165 :デフォルトの名無しさん:01/10/07 01:18
C#Builderが欲しい

166 :デフォルトの名無しさん:01/10/07 01:39
DelphiとC++Builderを1パッケージにするなら賛成

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

168 :デフォルトの名無しさん:01/10/08 15:39
なんでBorlandはPascalを拡張してdelphiにしたのか、いまだに謎。
1パスでコンパイル速い以外に、なにか理由あんの?

169 :デフォルトの名無しさん:01/10/08 15:44
>なんでBorlandはPascalを拡張してdelphiにしたのか、いまだに謎。
>1パスでコンパイル速い以外に、なにか理由あんの?
純粋 Pascal ってクラスとか使えないでしょ?

170 :デフォルトの名無しさん:01/10/08 15:46
まあC/C++厨房はMFCであがいてなさいってこった。

171 :デフォルトの名無しさん:01/10/08 16:59
>>169
いや、だからなんでPascalなの?って事

172 :デフォルトの名無しさん:01/10/08 17:02
>>171
Delphiに関しては、Turbo Pascalっていうブランドがあったから。
ブランドで売れると。

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

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

174 :デフォルトの名無しさん:01/10/08 17:37
>>172
当時はまだMacなんてPascalがメーカー推奨の
標準開発言語だったよね。いまやコードウォリアーも
見限った感ありだが。確かに最近始めた人にはなんで
パスカルかわからんのも仕方ないと思う。

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

176 :デフォルトの名無しさん:01/10/08 17:57
最近、CodeWarriorもPascalのサポートやめちゃったね。
そういえばこれもObjectPascalって言ってたけど
Delphiのとどうちがうんだろか?

177 :デフォルトの名無しさん:01/10/08 18:03
>>175
大文字と小文字は同一文字の異なる形態というだけなので
それらに異なる意味を振ることができると人間の勘違いミスを
招くってことで同一視のほうがエラー予防になるってことじゃ
なかったかな。

178 :デフォルトの名無しさん:01/10/08 18:06
>>177 そうだね

179 :名無しヘタぐらまさん:01/10/10 11:38
>>168
恐らく,ターボパスカルのボーランドだからでしょう.
マイクロソフトがベーシックにこだわるのと同じで.

>>176
ANSIが標準化をすすめてきたC/C++と違って
標準的なオブジェクト指向パスカルは存在しないようですから,
各社が勝手に拡張してオブジェクトパスカル
と名乗っているだけなのではないかと.

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

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

180 :デフォルトの名無しさん:01/10/10 11:46
たぶん Delphi1の発売当時、先行していたVB の弱点として
 ”VBがインタプリタだったのに実行までに非常に時間がかかる” <-当時ね

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

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

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

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

181 :デフォルトの名無しさん:01/10/10 11:52
そういえばエクストリームプログラミングでも
コンパイル速度はなるべく早く保つというのは
重要な事だと主張されていますね。

182 :デフォルトの名無しさん:01/10/10 12:33
>Delphiに関しては、Turbo Pascalっていうブランドがあったから。

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

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

183 :デフォルトの名無しさん:01/10/10 13:35
>>182 VBについてはこんな話もあったよ↓
http://piza2.2ch.net/test/read.cgi/tech/990101968/116-169

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

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

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

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

185 :デフォルトの名無しさん:01/10/11 23:20
おっしゃる通り。

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

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

186 :デフォルトの名無しさん:01/10/11 23:25
そこまでしてDelphiにこだわるのは
はっきり言って怠慢以外の何ものでもない。
C#が良いならC#に移ればよい。
今後Delphiに出来るのはC#の後追いだけ。

187 :デフォルトの名無しさん:01/10/11 23:34
>>185
確かに限界なんかは来てないのだが、
微妙な面倒さが少しづつ積もってきている。

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

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

188 :デフォルトの名無しさん:01/10/11 23:43
>C#が良いならC#に移ればよい。

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

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

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

189 :デフォルトの名無しさん:01/10/11 23:43
明示的にSetやGetメソッドを呼ぶことは、全くないわけだから。

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

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

190 :デフォルトの名無しさん:01/10/11 23:44
あのさあDelphiスレあげすぎ
自分はJavaユーザーだけど
はっきりいってうざい
煽りたくもなるってばよ

191 :デフォルトの名無しさん:01/10/11 23:47
ショウガナイヨ、Javaは出来ること少なくて、終ってんだから>>190

192 :デフォルトの名無しさん:01/10/11 23:49
C++とJava/C#のあいだって感じ〜?

193 :デフォルトの名無しさん:01/10/11 23:49
おれはどっちも使うけど、
Javaスレの上がりっぷりはもっとウザイのを自覚せえよ(w>190
Javaスレ立てすぎ&バージョンとかメーカー毎に立てるのヤメロ
情報が分散し過ぎ

194 :デフォルトの名無しさん:01/10/11 23:50
>>191
いやJavaがどうのこうのじゃなくて
Delphiスレあげすぎでうざいって言ってんだけど
通じないかなあ

195 :デフォルトの名無しさん:01/10/11 23:50
>>190
ぷぷぷ、Javaユーザーって心が狭いね(w

196 :デフォルトの名無しさん:01/10/11 23:54
Delphi>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Ruby>Java

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

197 :Java:01/10/11 23:57
悪かった。
WIDOWSしか使えん奴らに何言っても無駄だったな
わりいわりい

198 :デフォルトの名無しさん:01/10/11 23:59
190はJavaが遅すぎてストレスが溜まってるんだね
Delphi使えばいいのに(笑
Javaダサすぎ(藁

199 :デフォルトの名無しさん:01/10/12 00:14
Write Once, Run Any Where
君達には難しいかな

200 :デフォルトの名無しさん:01/10/12 00:14
いや、それはJavaにも難しいだろう。

201 :デフォルトの名無しさん:01/10/12 00:16
Write Once, Test Any Where
君達には難しいかな

202 :デフォルトの名無しさん:01/10/12 00:36
どうやら、Java使いのフリをしてまた802童貞が荒らしているようだ。

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

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

203 :デフォルトの名無しさん:01/10/12 00:56
>>202
童貞という言葉にやたらこだわるね
なにか気がかりでも? (w

204 :デフォルトの名無しさん:01/10/13 10:42
ていうかこの手の嵐はジサクジエンでしょうな

205 :デフォルトの名無しさん:01/10/13 11:56
嵐が去ったようなのでここからはマジな話の再開
-------------------------------------------

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

206 :デフォルトの名無しさん:01/10/13 16:09
ほんとはPascalなんて使いたくないんだけど、
Delphiで作るの楽だから使ってます。今後のBuilderに期待。

207 :デフォルトの名無しさん:01/10/13 23:45
>>205
IBX は Borland の管理物ではなくなったから,しょうがないんじゃ?
英語版からだし.

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

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

209 :デフォルトの名無しさん:01/10/14 14:04
>>208
何に対して怒っているのか理解できないな
Pascal 表記のヘルプがないことがそんなに問題かい?

210 :デフォルトの名無しさん:01/10/14 14:28
「日本語版」でリリースしておいて、実際役に立つ筈のヘルプは
みんな英語だった、って状況と似てるな。
「日本語版」なんだから全部やれよ

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

212 :デフォルトの名無しさん:01/10/14 14:39
>>210
IBX のヘルプは、全部日本語じゃん。

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

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

213 :208:01/10/14 14:52
> 今、日本で開発ツールを提供している会社、どれだけある?
なにも開発ツールに限定した話ではないがな。

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

214 :210:01/10/14 14:54
>>212
ちゃんと読め(w

215 :デフォルトの名無しさん:01/10/14 15:31
知識が豊富な開発者相手の商売だからこそ
野放しにされている部分は確かにあるだろう。

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

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

216 :デフォルトの名無しさん:01/10/14 21:46
Win32 API なんか英語で C 構文だぜ?
そっちのほうこそどうかして貰いたい。
IBX のヘルプなんか、訳されているだけでもありがたいよ。

217 :デフォルトの名無しさん:01/10/16 17:17
type IList = interface abstruct(TList);

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

218 :デフォルトの名無しさん:01/10/16 17:22
>>217
できない。

219 :デフォルトの名無しさん:01/10/16 17:34
>>218 じゃ出来るようにしてよ。 ってボーランド人だよね?

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

220 :デフォルトの名無しさん:01/10/16 17:37
なんか、めんどくさいことを全部言語処理系に押し付けていない?

221 :デフォルトの名無しさん:01/10/16 17:39
>>219
そんなことして何がうれしいの?

222 :デフォルトの名無しさん:01/10/16 17:43
そんなこと言わずにお願い!

223 :デフォルトの名無しさん:01/10/16 17:54
"Templates in Object Pascal"
http://community.borland.com/article/0,1410,27603,00.html

224 :デフォルトの名無しさん:01/10/16 19:57
>>223
この記事いいね。

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

225 :デフォルトの名無しさん:01/10/18 20:15
現在VBで社内用業務アプリを開発しているのだが、
なんとかしてVBマンセー上司にDelphiの良さを伝えて、
Delphiで開発を行いたいのだ。


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

226 :デフォルトの名無しさん:01/10/18 20:31
体を売る

227 :デフォルトの名無しさん:01/10/18 20:32
>>225 プログラマ板向けのネタだよね。

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

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

228 :デフォルトの名無しさん:01/10/18 20:40
VBだって時と場合によっては生産性が高いのは確かだ。
その上司が本当にツールの限界を理解していれば、だけど…。

229 :デフォルトの名無しさん:01/10/18 20:43
VB"も"だろ。

230 :デフォルトの名無しさん:01/10/18 20:54
Delphiと比べたらVBはゴミ以下

231 : :01/10/18 21:22
ういんどうずでは、VBできればまっいいや〜
Unixは、cだよな〜
まるちはJava。

おれはもっぱらじゃヴぁ

232 :デフォルトの名無しさん:01/10/19 02:00
上司がDelphi知らないから、Delphiでの開発に乗り気でないのでは?

233 :225:01/10/19 09:13
>>227
わかった。
マ板へと移る。

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

234 :デフォルトの名無しさん:01/10/20 15:16
同期型のコルーチンを記述出来るようにして欲しい

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

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

235 :デフォルトの名無しさん:01/10/20 15:26
C++のテンプレート機能が欲しいという意見は良くみかけるけど
ビジュアル開発環境との相性の点で疑問

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

236 :デフォルトの名無しさん:01/10/20 15:52
>>234
それなにに使うの?

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

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

238 :デフォルトの名無しさん:01/10/20 16:34
>237
オモロイね。オブジェクト指向とちょっとかぶってるかな。
ところでinterfaceというのはどこから来た言葉なの?

239 :234:01/10/20 16:49
定義済の単語でinterfaceが一番適当かなと思ったんで。

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

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

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

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

241 :デフォルトの名無しさん:01/10/20 18:53
fiber使え

242 :デフォルトの名無しさん:01/10/20 19:02
>241 重いのと、引数の渡しが面倒です。

243 :デフォルトの名無しさん:01/10/20 20:21
scheme使え

244 :デフォルトの名無しさん:01/10/23 10:16
俺は演算子の定義が出来るといいな

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

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

245 :244:01/10/23 10:19
おっと、メソッドじゃなくて 汎用関数の方がいいな

246 :デフォルトの名無しさん:01/10/23 10:19
>>244
カスタムバリアントを使え。

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

248 :通りすがり:01/10/23 10:27
>カスタムバリアント
誰も使わないVariantに少数派の要望をねじ込んだ、実にうまい手だ!

249 :デフォルトの名無しさん:01/10/24 03:45
三項演算子つくってくれ!!!切実に希望。

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

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

250 :-:01/10/24 07:25
本当にそう思ってるのか?
ここで発言てみたいだけなんとちゃうんか?
と問いたい問い詰めたい。

function Iff();

251 :デフォルトの名無しさん:01/10/24 09:16
IfThen()

252 :デフォルトの名無しさん:01/10/24 12:09
>>251
>A の真偽に応じて、B,Cの一方だけしか評価しない奴
この要求を満たしていない。

253 :デフォルトの名無しさん:01/10/24 13:17
「B,Cの一方だけしか評価しない」とは何ぞや?
評価なんてしないと思うが・・・

254 :Delフサギコ:01/10/24 13:30
 これあげーる。

 評価しない=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;

255 :デフォルトの名無しさん:01/10/24 13:47
>ソースコードの行数が結構減らせてイイ!!
この要求を満たしていない。

256 :重箱の隅つついていい?:01/10/24 13:54
よくみると
>if A then
>A := B
>else
>A := C;
AはBoolean型の変数でないと使えない。

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

257 :Delフサギコ:01/10/24 14:04
引数渡しと関数渡しが根本的に違うし…
>>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;
////////////////////////////////////////////////////////////

258 :Delフサギコ:01/10/24 14:05
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に三項演算子は似合わないって事でよい?
  ミつ つ  \
〜ミ ,, ミ.     ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ∪∪  書いていて鬱になるコードだ.

259 :Delフサギコ:01/10/24 14:12
>>257-258
 TrueMethodとFalseMethodをInterfaceで定義しておけば
 場面に応じてそのinterfaceを定義したクラスを作り
 使いまわしの出来るコードが作れるかもしれないけど

 ネコは嫌になったからもうしらない。

 ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄
   ∧,,∧    ウツダ
  ミ,, ゚Д゚彡
   〃  つ旦~~  
 〜ミ,,,n,,n[ ̄ ̄ ̄.]
        ̄ ̄ ̄
 TFunction = function integer

 TAFunction = function(Value: Integer): Integer
も継承関係にあるべきと思うのはおかしいかしら。

260 :デフォルトの名無しさん:01/10/24 14:18
3項演算子は単に短く書けるというだけの価値は無いと思います

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

261 :デフォルトの名無しさん:01/10/24 14:22
だって C の三項演算子は

if aaa
 bbb;
else
 ccc;

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

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

262 :Delフサギコ:01/10/24 14:39
  ∧,,∧∩  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ミ,,゚Д゚彡 < >>260-261 リョカーイしまツた
  U  ミ   \____________
  ミ  ミ
 ノ∪∪ 誤ったドツボにはまってシマテタ ノネ

263 :デフォルトの名無しさん:01/10/24 16:43
マニュアルがしょぼいよね。
JavaDocみたいなのがほしい。

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

264 :デフォルトの名無しさん:01/10/24 17:13
Javaみたいなパッケージ階層希望、あるいは C++ みたいな名前空間でもいい。
とにかくコンポーネント名がダブってもよいしくみにして。

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

265 :デフォルトの名無しさん:01/10/24 17:31
>Delphiは同じ処理を表現する手段がCより少ない事が メリットの一つだと思いますから

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

266 :Delフサギコ:01/10/24 18:18
   ∧,,∧   / ̄
\,,,,ミ,,゚Д゚彡 < >>264 ドウイ
⊂,,,,,,,,,つつ.  \_

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

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

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

267 :デフォルトの名無しさん:01/10/24 18:42
名前だけならなんとかなるとしても
 Obj.ClassName が返す名前をどうするの?

268 :デフォルトの名無しさん:01/10/25 02:18
>>267
ユニット=Classes
カテゴリ=クラス処理ルーチン

function FindClass(const ClassName: string): TPersistentClass;

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

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

269 :デフォルトの名無しさん:01/10/25 03:03
>>268
同じ名前をもつクラスをひとつのプログラムに同居させたい。という話をしているんですが。

270 :デフォルトの名無しさん:01/10/25 03:19
クラス、関数、手続き内のスタティック変数ほしいかな。
今は型付き定数やユニットローカルな変数で代用してるけど。

271 :デフォルトの名無しさん:01/10/25 06:53
型付き定数でいけない理由は?

272 :Delフサギコ:01/10/25 13:20
   ∧,,∧   /よく氏等ニャーが
@,,,ミ,,゚Д゚彡 < 関数などはあとがきuses Unitが優先選択されるのだから
⊂,,,,,,,,,つつ.   \ クラス名も後書きuses Unitが優先されたりはしないの?

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

273 :デフォルトの名無しさん:01/10/25 13:48
>>272
それは(プログラム)スコープの問題でしょ?

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

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

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

274 :Delフサギコ:01/10/26 19:48
   ∧,,∧   / ̄
(,,,,,,,ミ,,゚Д゚彡 < なるほど。
⊂,,,,,,,,,つつ.   \_

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

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

275 :デフォルトの名無しさん:01/10/26 20:55
Obj.ClassName が返す名前を ユニット名+クラス名にすればよいようだけど
あんまり綺麗じゃないと思うけどなあ

76 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)