[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 05/09 13:22 / Filesize : 110 KB / Number-of Response : 605
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

バカボンのDelphi不買・販促・その他談話室その29



1 名前:デフォルトの名無しさん mailto:age [2006/07/18(火) 22:06:22 ]

       / ̄ ̄ ̄ ̄\            / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
     >/_______/|           |  Delphi不買 や Borland DevCo に関する話題
    |\      __・\_        <  雑談や質問を、しながら
     |  ..|   ・  /.・`    )       | マターリくつろいでね
     |  |      /フ ̄| |        \_________
     ( ∂  @_/ ̄  / / 
     \⊥ \    m/ /  
      \    ヽ─ ⌒ /   
        ヽ────-      

(注)本スレは被害担当艦としての機能も持ち合わせているんだ。
見識の狭い困ったちゃんが他のDelphiスレで暴れるのを防ぐため
なま暖かい心で構ってあげてね。

Borland Developer Network
bdn.borland.com/

前々スレだよ
pc8.2ch.net/test/read.cgi/tech/1130648644/

前スレだよ
バカボンのDelphi不買談話室その28
pc8.2ch.net/test/read.cgi/tech/1134668922/


413 名前:デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:04:36 ]
>>Enterpriseを買うか、Professionalを買うか検討してるのですが、
>>dbExpressって、dbGOに比べてどういいのでしょう?
俺的には問題はドライバの質だよな。Enterprise版のOracleやSQLServerのドライバは
Borlandが開発してるから、今一ドライバの質が悪そうで不安(本格的に使ったことはないが)。
一方、ADOのドライバはデータベースメーカ純正がほとんどだから、データベース自身を売るためにも
しっかり作ってありそうで安心感はある。
まぁ、Borland的にはdbExpressを売りたいから、dbGoのバグ取りとかあんま本格的に以前やってなさそうだったので、
それも問題であるが・・・


414 名前:デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:05:59 ]
BDEで良いんじゃね?

415 名前:デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:07:59 ]
BDE最強だが、dbGo最高。

416 名前:デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:36:35 ]
>>407
> dbExpressって、dbGOに比べてどういいのでしょう?

Delphi2007 ではdbEpxress が大幅に改良されているみたいだけど
過去のイメージとしては

dbExpress ・・・速い。非常時接続タイプ。どちらかと言えば、サードパーティの有料ドライバが前提。
dbGo・・・遅い。常時接続タイプ。ドライバは豊富。

> EnterpriseとProfessionalの違いで、データベースアプリケーションの開発

どちらかと言うとdbExpress よりDataSnap とかじゃね。

417 名前:デフォルトの名無しさん mailto:sage [2007/02/26(月) 18:52:34 ]
>>412
ありがとう。とっても参考になりました。

>>413
たしかに、他の言語でも使われているADOで接続したほうが安心感はありますね。
質がよくわからんdbExpressとバグありのdbGO、究極の選択ってことか。

>>416
DataSnapなるものがあるのですか。
さっそく、調べてみます。
まぁ、現状で使ってないということは、俺には必要ないものでしょうな。


とりあえず、Professionalで問題なということか。
まあ、なんていうか、製品構成ぐちゃぐちゃですね。
お仕事ユーザはBDSに統合されて、趣味ベースはTurboシリーズで単体売りを始めた、
とおもったら、今度はDelphi単体で製品名はTurboでない。しかも、Enterpriseあり。
新しいロードマップがでて、説明もされてるようだけど、なんだかなぁ。

今更だけど、今後も、ついていけるか激しく不安だ・・・・・・・・・・・・・・・・




418 名前:デフォルトの名無しさん mailto:sage [2007/02/26(月) 18:53:58 ]
>>417

Delは旧バージョンのままで十分使えるから無問題。

未だにDel7とBCB6使ってるお。

419 名前:デフォルトの名無しさん mailto:sage [2007/02/26(月) 19:59:06 ]
え?新しいロードマップってどこに??

420 名前:デフォルトの名無しさん mailto:sage [2007/02/26(月) 22:17:45 ]
お仕事なら、メンテ以外ではもうDelの出番はないでしょ。
これから新たに、なんて正気とは思えないが。

421 名前:デフォルトの名無しさん [2007/02/27(火) 05:43:59 ]
>>417
> 新しいロードマップがでて、説明もされてるようだけど、なんだかなぁ。

まだ公式には出てないよ。
1週間後のデベロッパーキャンプで、偉い人が日本に来て説明する。
2007もそこでお披露目。



422 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 05:46:54 ]
>>420
> これから新たに、なんて正気とは思えないが。

Vista 対応も出来た・していくようだし
2・3年で使い捨てるようなアプリなら、新規にDelphi でもいいんじゃね。

423 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 06:07:02 ]
>>413
> 俺的には問題はドライバの質だよな。

dbExpress はインターフェースを提供しているだけで
ドライバ(の機能)自体はDB ベンダが提供しているドライバを使う。

424 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 08:16:49 ]
win32 ユニコード対応!対応!騒いでる奴は腕がないだけ。
こんだけ情報があれば普通のプログラマはもうとっくに対応してる。
そしてなぜ標準対応にならないのかを考える頭すらないへぼぷろぐらま。

425 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 08:40:37 ]
騒いでる奴に、頭ごなしにヘボだと言うよりも、やり方を教えてやる方が建設的だろう。

1、ファイル名入力ダイアログで大陸系のファイル名が文字化けして困る人
 ⇒TOpenFilenameW/GetOpenFileNameW
  書き出しはunicodeなんぞのファイル名を書かせるな

2、LoadFromFileでunicode文字が・・・・
  ⇒自前でWideString/UCS4String/UTF8Stringなりに読んで変換すりゃいいじゃない

3、エラーメッセージを大陸の文字で出したい
  ⇒そこまで大陸に拘る必要あるまいに
  いや、補助漢字とかシフトJISじゃ表示出来ない日本語の漢字もあるんで
  TNTware 使えよ ⇒ www.tntware.com/delphicontrols/unicode/


426 名前:405 mailto:sage [2007/02/27(火) 08:58:20 ]
ColorBox1.Items[#] := 'キャプション';

で事故解決しますあt

427 名前:Delフサギコ ◆A6VzDeLphI mailto:sage [2007/02/27(火) 10:05:53 ]
俺がユニコード対応対応と騒いでるわけじゃないけど
対応はしてほしいね。

> win32 ユニコード対応!対応!騒いでる奴は腕がないだけ。
> こんだけ情報があれば普通のプログラマはもうとっくに対応してる。

    ∧,,∧  ボカーン
    ミ ゚д゚彡
  〜ミ,,,,uuミ

いや、情報の取捨選択とか
標準化の意味とか、クラスライブラリの意味とか
そういうのが理解できない人に
> そしてなぜ標準対応にならないのかを考える頭すらないへぼぷろぐらま。
よばわりされても...

某ユーザーは全員が全員、標準でユニコード対応してないから
全員が苦労して対応しなきゃならないわけ?

なぜMS環境が標準対応になるのか考えた事とかってなさそうだね。きみは。

構文解析などの文字列処理を行うときでも
UnicodeとSJIS、両方対応めんどうだしなあ。

428 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 10:13:06 ]
>なぜMS環境が標準対応になるのか

ダウト。
今M$環境が超弱まってる。
組み込み系はほぼC/C++、例外的にJava。
ドトネトなんてPCでも使われてない。

429 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 10:47:20 ]
構文解析は、結局世の中に色んな文字コードがある以上、
どの文字コードでやるかを自分で決めてやるしかないだろう
俺はANSIの方が再帰下降とか状態遷移で分析する時にテーブルがコンパクトで楽だけど
別に、UNICODEが好きならUNICODEでやればいいだけ。
両方に対応する必要はない。 文字コード変換すればいいだけでは?
文字コード変換で変換できない文字があるというような趣旨なら、
そもそもその前に何かが破綻してるのだろう。

>UnicodeとSJIS、両方対応めんどうだしなあ
ボーランドだって売り上げに直結しないなら、両方対応するの面倒だろうよ

430 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 11:01:17 ]
>UnicodeとSJIS、両方対応めんどうだしなあ

仕方ないから内部処理はUTF8して、描画のタイミングで切り替えてる。

Windowsに寄り添ってもUCS3になったり4になったり振り回される。
UTF-8の内部処理がベスト。

431 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 11:23:35 ]
そうだよなあ UNICODEって 7から32まで、でもってBOMの有無からホント色々。
S-JIS/EUCだって無視出来ないわけで、

windowsが ANSI系のAPIを廃止するならともかく
今の対応状況で十分だろ。

というか、いったいどんな対応を期待してるわけ?
for .NET な for win32?



432 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 11:29:44 ]
>UnicodeとSJIS、両方対応めんどうだしなあ

コンポーネントがUNICODE受け付けてくれたら便利だが、
内部処理はUTF-8じゃないと結局複数対応になるよ。

それにUTF-8じゃないとヌル文字が混ざってAnsi系のc/c++系の莫大なライブラリが動作しなくなる。

とにかく内部処理はUTF-8。

433 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 11:31:36 ]
たぶん UNICODE対応しても、俺はまず使わない
理由は自作コンポーネントが ANSI文字列前提で色々やってるから
それを全部変更しなくちゃいけないが、それだけコストをかけてやってる仕事が今の所ないよ。

そして、コンポーネントを対応したとしても、既に作ったものは、やっぱりANSI対応にしてる。
で、こっちはメインテナンスモードだから、作り直すわけにはゆかない。

そうなると自作コンポーネントが2種類になる。
やってられないよ

434 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 11:35:48 ]
>そうなると自作コンポーネントが2種類になる。

1種類のコンポに文字入出力が、AnsiとUnicodeと2種類あれば良いんじゃね?

435 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 11:39:16 ]
>>434
そういう対応出来る場合もあるだろうけど
winコントロール継承だと、そう巧くゆく場合ばっかりじゃないだろなあ


436 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 11:52:54 ]
>>435
winコントロールがそうなってるんだけど...

437 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:01:57 ]
Win自体CreateWindowで切り返れるんだから、コンポ内でもそうすりゃいいだけだろうよ

438 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:04:05 ]
つーか、unicode対応しろって言う人間に対し技術力がないとか煽るくせに、
対応反対の言い訳はAnsi前提だから、かよ。アホかw どれだけ思考停止してんだよ・・・

439 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:23:59 ]
>>434
たとえばCaptionのプロパティ型を AnsiString に
WCaption ってプロパティを作って WideStringに というようなことをしようって事?
無理でしょ?

string が AnsiString 型と WideStringか UTF8String に切り替わるわけで
条件コンパイルでこの2つを切り替えたコードにするしかないと思うよ

440 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:26:39 ]
>>438
指向停止と言われても、結局過去ボーランドのDelphiを購買し、今後も購買するのは
俺達老人なわけで、

それを批判するなら、UNICODE-Delphiをキミらがバカスカ買うしないよ。
キミらがバカスカ買って市場が広がるなら、俺達だってUnicode-Delphiを使うのに、何の躊躇も持たない

441 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:31:30 ]
>>439
ヒント:入出力メソッド2つ→4つ



442 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:32:23 ]
もはや支離滅裂

443 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:43:52 ]
>>441
こういう事を言いたいわけ?
ANSI版    TCaption = type string;
UNICODE版 TCaption = type WideString;
だとするよ。

既に作ってるアプリは string変数で受けてるとする
ANSIアプリでは Caption をそのまま従来通り使う
UNICODE版では WCaptionを使う?

でも、継承してる以上、上がCaptionをTCaptionと定義してたら UNICODE版も Captionは WideString;だ

WCaptionって無駄じゃね?

444 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:49:39 ]
>>443
別に文字列保持はUTF8(つまりANSI)1個にしといて、
入出力が2つあれば良いんじゃね?

メソッド増やすの無駄だって言うんなら、クラスベースコーディングの否定だお。
これらの処理が入るだけで、複数のANSI系言語を1アプリで動作するんだから、
あっという間に国際化だお。

445 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:50:57 ]
念の為説明。

AnsiStringとUtf8Stringは名前が違うだけで、実体は同じ。

446 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:58:38 ]
プロパティの型は継承したコンポーネントで変更出来るし
GetCaption/SetCaptionはvirtualではないから この場合は可能だろうけど
親子で同じ名前の型が違うのはどうだろうな


447 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 13:04:29 ]
ヒント:違う名前

WinAPIだと末尾にA/Wが付くお。

448 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 13:05:45 ]
GetCaption(); ← GetCaptionAと等価
GetCaptionA();
GetCaptionW();

で良いんじゃね?

449 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 13:09:14 ]
>>448
いや、だから、ソレ無駄でしょ?
古いアプリではGetCaptionしか呼ばないから
GetCaptionA(); <---誰も呼ばない
GetCaptionW(); <---必要ない

UNICODEアプリでは、GetCaptionがそもそもUNICODEなのだから
GetCaptionW(); <---誰も呼ばない
GetCaptionA(); <---必要ない


450 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 13:23:49 ]
>>449
いや、だから、メソッドの追加が無駄ならクラスライブラリ使うのやめなさい。
実際のところこれらの追加とは比べものにならない無駄なメソッドの塊がクラスライブラリだから。

単なるPascalとかC言語があなたにあってるよ。

451 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 13:37:27 ]
互換を取りつつUNICODE対応を追加するのならソレでいいけど
この場合は土台が変化するのだから条件コンパイルでしょ

UNICODE対応が完了したらそんな盲腸みたいにANSIのメソッドを付ける必要は何もない
今UNICODEに対してやってるように文字コード変換関数を使えばいいのだから




452 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 13:44:37 ]
>互換を取りつつUNICODE対応を追加するのならソレでいいけど

互換を取りつつ追加すればよい。

>この場合は土台が変化するのだから条件コンパイルでしょ

わけわかんない事言うな。

>UNICODE対応が完了したらそんな盲腸みたいにANSIのメソッドを付ける必要は何もない
>今UNICODEに対してやってるように文字コード変換関数を使えばいいのだから

違うんだなー。

「UNICODE対応」という言葉一つだが、そーじゃない。・
Winコントロールに値を渡すときにWinのバージョンによってUCS2、UCS4なんかと切り替わる。
さらにWinのUCS2なんかに合わせると、NULLが混ざって旧いライブラリが通らない。

つまり、「UNICODE対応」と言いながら、
・内部処理はUTF-8
・Winコントロールに渡すときにUNICODE同士でエンコード
の2つとなるのがベスト。




453 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 13:46:12 ]
>>433の問題に対して >>434の解決は、センスが悪いと思うよ。

理由を書くよ。
 このコンポーネントは2つの環境で使われるANSIとUNICODEだ。
 だから>>433はコンポーネントを2つに別けようとしたのだろう
 他の対応方法としては
 2、条件コンパイル
 3、両方に対応出来るコンポーネント
 が考えられる。
 1,2の対応では、テスト量は2倍になる。

 しかし、両方のメソッドを持つコンポーネントは、それぞれのメソッドを
 どちらの環境からも呼ばれる可能性まで考えなければいけない。
 つまり、複雑さは4倍になってしまう。
 ANSI環境からUNICODEメソッドを呼ばれるテストとその逆のテストも追加しなければいけないからね

多くの場合、コードを書くコストよりテストやメンテナンスが大きいわけで

454 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 13:48:40 ]
> 1,2の対応では、テスト量は2倍になる。

なりません。

クラス派生した場合は、既存の上位メソッドが呼ばれるだけ。

そうじゃなく、委譲と化する場合なら、委譲を受け持つベースクラスがある筈だから。


455 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 13:50:07 ]
453はクラスライブラリを使いながら、クラス派生により差分コーディングされてるという事実を知らないの?

センスが悪いどころでなく、無知。


456 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 14:04:48 ]
差分コーデングっていうが
GetCaptionA();
GetCaptionW();
も、TControlには無いわけだ。
それぞれTFormだのTEditだの
から継承結果に追加するわけだろ?

あるいは、独自のTUniControl でも書くわけ?
で、書いたとしてソレに何のメリットがあるわけ?

ANSIが絡んでるのは検索とか、演算とかスクリプトとかのエンジンだろう
インターフェースの問題に置き換えたって そっちの問題は何も解決しないじゃん


457 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 14:07:12 ]
>>456
おまいにクラスライブラリ設計能力どころかクラスライブラリの中の人を知らない事が分かったからウセロ!

458 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 14:09:28 ]
>>456
UNICODE対応を望んでいる人は多いんだから、
悪いけどこのスレから出て行って貰えないかな?

459 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 14:14:18 ]
>>454
焦らないで、良く読めよ

1は、ファイルを2つに別けて対応した場合
2は、条件コンパイルで対応した場合だ、

そもそも、
UNICODEコンパイラとANSI コンパイラの2つの環境でテストしなければならないのだから
> 1,2の対応では、テスト量は2倍になる

という事だ。


460 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 14:15:50 ]
>>458
それはどうかな? ホントに多いか?

もし今後UNICODEコンパイラのみになるとしたら反対する奴の方が多いだろう。
俺達の資産はどうしてくれるんだ!とね

461 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 15:11:11 ]
とりあえず、互換性を保ってUNICODE対応するにはを考えれば良いだけじゃね?
UNICODE対応は要る人には必須なんだから。



462 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 15:19:28 ]

>UNICODEコンパイラとANSI コンパイラの2つの環境でテストしなければならないのだから
>> 1,2の対応では、テスト量は2倍になる

そもそも、

片方が必要な人は片方をテストすればよいし、
両方いる人は両方をテストすればよいという当たり前。

という事だ。



463 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 15:28:20 ]
使う人がテストすりゃいいんですか
それは素晴らしいアイデアですね。  
大陸の人は実践してるようですし、彼らはそういう思想のようですからあなたは仲良くなれそうですよ。


464 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 15:36:38 ]
459のバカにちょっと寄り添ってテストしてやるって書いただけで、本当はテスト不要。
大体、Captionの入出力なんてテストしたことないし、
VCLの中を作る人もインターフェースはクラス派生、処理は委譲なのでテスト不要。

465 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 15:49:22 ]
>>458
> UNICODE対応を望んでいる人は多いんだから
詭弁のガイドラインにそういうのあったよね。

> 悪いけどこのスレから出て行って貰えないかな?
このスレは被害担当艦でもあるしねぇ…

466 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 15:50:22 ]
つまり、既成のコモンコントロール類はそのまま使うんだろ?
だったら、自前のコントロールも、既成コントロールに似せて作った方が使いやすいだろうに

だいたいUNICODEコンパイラを使うなら、UNICODEだけで書く方が楽だろうに
ANSIは変換して使うだけでいいだろ?

なんで 2つもインターフェースが必要なの?
そのメリットは何?

467 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 15:55:30 ]
P2Pアプリで落としてきた、海外のエロファイルをそのまま扱えるとか。

468 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 15:56:55 ]
466がUNICODEといってもWindowsに複数のエンコードがあることが分かってない件について

469 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 15:58:04 ]
466がUNICODE文字列の途中のNULLによって既存のANSI系のライブラリを通過しないことを知らない件について

470 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 16:06:26 ]
Unicode対応キボンヌと言ってても
これじゃ 出て来たものが
WideStringでもUTF8Stringでも文句言うだろうな

for .NET のstringクラスならどうだ? これでも文句言うのかな?

471 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 16:10:49 ]
某社としてはWin32をサッサと捨てて、開発者が.NETに移行してくれることによって
VCL/Unicodeに関する問題をスルーしてくれることを目論んだんだろうけどな。
現実はそう甘くなかった。



472 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 16:20:58 ]
>>470
当たり前。

ただ単にUNICODE対応すれば良いってもんじゃない。

現状に文句言ってるのは描画のタイミングでUNI→ANSI変換だけだと、
複数言語混ぜれない。

473 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 16:28:20 ]
今まで文字コードなんて意識した事すらない俺にはお前等が何喋ってんのかちんぷんかんぷんだ

474 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 16:29:24 ]
結局 Unicode対応希望グループの総数は多くても
総論賛成、各論反対で、全員を満足出来る解が無い以上、厳しいって事だな。

for .NET が売れてりゃ、その方向の可能性もあったけどさ

475 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 16:31:50 ]
難しい事はよくわからんが、とりあえずIMEパッドで第2水準の文字とかが
入力できて、そのまま表示できればそれでいいや

476 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 16:54:12 ]
>>475
おまいのソフトが突如ヨーロッパで売れて、
ドイツ語とフランス語同時に表示汁!
って言われたら、
小細工コーディングじゃなくてVCLに標準装備して欲しくない?

477 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 16:56:27 ]
ドイツ語とフランス語ならASCIIの範囲でも両立するんじゃなかったっけ?

478 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 19:33:02 ]
記事

DelphiがVistaのUIに対応しAjaxもサポート
www.itmedia.co.jp/enterprise/articles/0702/22/news009.html
www.thinkit.co.jp/free/news/0702/21/7.html
enterprise.watch.impress.co.jp/cda/software/2007/02/21/9685.html
it.nikkei.co.jp/business/news/release.aspx?i=153436


479 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 20:14:40 ]
「CodeGear」ってブランド名扱いなのか

480 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 21:03:04 ]
>>471
まぁ、.NETがこけたことでDelphiも生き長らえたんだけどな。


481 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 21:07:37 ]
Delphi for PHP で、Delphiの定義がわからなくなったな
だったらKylix も Delphi for LINUX とか名づけておきゃよかったのに



482 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 23:23:52 ]
>481
単なる苦し紛れなネーミングですから。本当ならPHP Builderとかにしたかったんじゃないの?

483 名前:デフォルトの名無しさん mailto:sage [2007/02/28(水) 01:23:43 ]
Delphi for C++
Delphi for Java
Delphi for C#

484 名前:デフォルトの名無しさん mailto:sage [2007/02/28(水) 02:41:47 ]
Delphi for Pascal
Delphi for VB厨

485 名前:424 mailto:sage [2007/02/28(水) 08:14:29 ]
>>427
念のためいっとくけど424以降ここまで俺の発言はひとつもないよ
ここまでのレスを見て俺の言う意味がわかったろ?

486 名前:デフォルトの名無しさん mailto:sage [2007/02/28(水) 09:14:26 ]
つか、俺も条件コンパイルかソース分ける方がスマートと思うが。

スレを読んでみたけど、>>444の言ってる事意味不明。前に出てきたグローバルフック君みたいな感じ。

ここではCaptionの例が出てるが、すでに
Captionプロパティの型はTCaption = stringと定義されてるわけで、君がどういう実装がいいと思ってるのか
知らんがこの定義を変えるだけで、
>>互換を取りつつ追加すればよい
君の言う互換性が失われるわけだが・・



487 名前:デフォルトの名無しさん mailto:sage [2007/03/01(木) 07:22:52 ]
Delphi 2007 for WIN32 は買い or 待ち?

488 名前:デフォルトの名無しさん mailto:sage [2007/03/01(木) 08:05:45 ]
Unicode待ち

489 名前:デフォルトの名無しさん mailto:sage [2007/03/01(木) 08:06:28 ]
.netを普及させる方法を思いついた!
win32に、WCaption: WideString みたいなメンバを追加して
さらにくそでかく遅いバイナリしか生成できなくする。
これなら.netでいいや、ってなりwin32死滅。

490 名前:デフォルトの名無しさん mailto:sage [2007/03/01(木) 10:29:53 ]
>>488
Unicode 以外に興味は無いのかw

491 名前:デフォルトの名無しさん mailto:sage [2007/03/01(木) 12:14:17 ]
>>490

禄に使わない機能に限って多大な興味を持たれるらしい。




492 名前:デフォルトの名無しさん [2007/03/01(木) 20:02:53 ]
つか、いまどきDelphiは禄に使われないし、興味も持たれないし。 


493 名前:デフォルトの名無しさん mailto:sage [2007/03/02(金) 07:55:25 ]
アンチ発病w

494 名前:デフォルトの名無しさん mailto:sage [2007/03/02(金) 08:27:13 ]
最近のバージョンはエンタープライズ向けに巨大化して使い難い
もっとシンプルな、もっとOS依存減らした組込用VCLの方向なんてのも、
市場はニッチだろうけど値段も取れて けっこうおいしいと思うんだけどな


495 名前:デフォルトの名無しさん mailto:sage [2007/03/02(金) 08:48:47 ]
かくしてDelphi 言語ではないVCL が増えていくのであった。
・・・Pascal ユーザーにDelphi ブランドを返してくれ。

アメリカ人のマーケティング関係者の考える事は異常w

496 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 19:47:10 ]
Delphi 2007 for WIN32 はもうちょっと安ければ、買いなんだけどなー。
Highlander とセットで割引とか、無いのかね。

497 名前:デフォルトの名無しさん [2007/03/04(日) 17:04:21 ]
あげ

498 名前:デフォルトの名無しさん [2007/03/07(水) 09:17:13 ]
VerUP、9月までだよね? ちょっと様子見だな。


499 名前:デフォルトの名無しさん mailto:sage [2007/03/07(水) 09:44:31 ]
Delphi for PHPは日本語版が出た時のアップグレードが6千円程度なら英語版でも買っておくんだけどなあ

500 名前:デフォルトの名無しさん [2007/03/08(木) 05:14:54 ]
Delphi 2007 for WIN32 の案内来たが

ハナっから32しか出来んのだから for WIN32 なんていらんだろう。それとも
for WIN64 あるのか?

501 名前:デフォルトの名無しさん mailto:sage [2007/03/08(木) 07:00:32 ]
Delphi 2007 for .net をお忘れなく。



502 名前:デフォルトの名無しさん mailto:sage [2007/03/09(金) 09:44:52 ]
for WIN64の予定は今のところ来年

503 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 09:58:00 ]
糞認証なかったら導入を検討しないでもないのだが

504 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 10:16:46 ]
そうだな。
.NET だの JAVAだので書かれた、役にたたん生産性向上なんとはは不要し、
認証無しで3万なら最後のバージョンアップと思って買ってもいい。

とりあえずVista対応なんて今必要じゃない。 
というかお客さんが話をふっても希望してくれん状況じゃな。
今みたいにいつ認証が消えるかわからん状態じゃHDDのコヤシにする気にもなれん

505 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 11:00:27 ]
割れ厨、涙目w

506 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 11:32:54 ]
Delphi 2007 for WIN32 Lite

・Together とか無しで.NET だのJ#だの余分なのは外せる
・ダウンロード販売のみで3万円(優待販売のみでもいいや)
・圧縮ファイルに購入時のIDでも入れといて事後認証不要

こんなのを出してくれりゃな

507 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 23:17:09 ]
・Unicodeのみ対応

508 名前:デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:51:07 ]
・正規表現標準対応

509 名前:デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:56:02 ]
却下。 そんなのは PERLで十分

510 名前:デフォルトの名無しさん mailto:sage [2007/03/20(火) 12:47:53 ]
dn.codegear.com/jp/article/34158

・Delphi言語に限らず Delphiは開発に対するアプローチ

511 名前:デフォルトの名無しさん mailto:sage [2007/03/20(火) 13:31:36 ]
dn.codegear.com/jp/article/34158
高橋さんいわく
 Delphi for PHP 英語版でもヘルプとIDEは英語だが、ソースコードは UTF-8に対応している
 なんか、デモではデータベースで日本語通すのに、イベントで初期化を入れないといけないとやっているな
 ただ、全てのコンポーネントが日本語に対応してる状態ではないとの事




512 名前:デフォルトの名無しさん [2007/03/22(木) 15:56:07 ]
3月22日〜27日の6日間だけの「期末特別キャンペーン」
って何だよ!
>期間限定で、登録ユーザー様向けのご優待価格で新規ライセンスをご提供するものです。



513 名前:デフォルトの名無しさん mailto:sage [2007/03/22(木) 16:03:26 ]
ソースはどこ?






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<110KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef