Codegear раздает RAD Studio по цене Delphi 2007 Win32.
http://tinyurl.com/38ol7e
Предложение действительно до 31 декабря 2007.

Ответ на »сообщение 630« (Сергей Перовский)
___________________________
Я с этой проблемой сталкиваюсь постоянно, и поэтому так радуюсь, что наконец Delphi станет полностью Unicode-совместимым. Потому что с ANSI-строками по настоящему многоязычную программу не сделать из-за известных ограничений.
Я надеюсь, что UTF16 поставит жирную точку в этом вопросе.

По сути, уже и все современные ОС, и подавляющее большинство БД, и интернет-протоколы, и конкурентные IDE - все поддерживают Unicode, забыв о такой вещи как ANSI-строки и кодовые страницы, используя их только для обратной совместимости. Delphi в этом плане выглядит белой вороной, надеюсь, уже недолго.

Ответ на »сообщение 629« (Aleg Azarousky)
___________________________
AnsiString (как и ShortString) не предназначены для работы с разными кодовыми страницами, и я б не хотел, чтобы их как-то дорабатывали для этого.
Вы, видимо, редко сталкивались с многоязычными текстами. А их много. И проблема эта существует. И очень хочется, чтобы решал ее компьютер, а не программист.
Та же история с базами данных: кодировка хранится в настройках драйвера БД, что не позволяет работать с многоязычными базами - должна бы хранится в каждой строке.

Ответ на »сообщение 628« (Сергей Перовский)
___________________________
А так это понятно, просто "кодировка строки" <> "кодовая страница строки типа AnsiString".
AnsiString (как и ShortString) не предназначены для работы с разными кодовыми страницами, и я б не хотел, чтобы их как-то дорабатывали для этого. Кодовые страницы - это вообще костыль с целью заставить старый добрый ASCII понимать разные (далеко не все) языки.

Ответ на »сообщение 625« (Aleg Azarousky)
___________________________
А ShortString или AnsiString в разных кодировках это разные типы?
Попробуйте сложить - получите полную ерунду, а компилятор молчит.
Да, я об этом писал чуть ниже. Компилятор должен выдавать при неявном преобразовании предупреждение (а еще лучше - ошибку).
Да нет никакого преобразования: складываем две AnsiString, а то что одна по русски, а другая по немецки указать негде. А это гораздо важнее наличия ограничений на длину.
Что там строковые переменные. При попытке распечатать исходник программы зачастую получаем крокозябры вместо русских коментариев. Т.е. кодировка самого текста ошибочно распознается Windows.

Ответ на »сообщение 626« (panda)
___________________________
Да, я понял о чем вы (name=value), но моя функция для вычленения нескольких подстрок, с разными разделителями из одной исходной, например 'aaa=bbb+ccc':
  getelem('=', 'aaa=bbb+ccc') --> 'aaa';
  getelem('+', 'bbb+ccc') --> 'bbb' и остаток 'ccc'.

Ответ на »сообщение 625« (Aleg Azarousky)
___________________________

Поверьте, предусмотреть все возможные действия над строками в стандартной библиотеке не под силу никому. Например, я часто использую функцию, которая извлекает из входной строки начало вплоть до указанного разделителя, и возвращает начальный элемент и остаток. Ее нет в RTL.
Конечно. В стандартной библиотеке обычно предусмотрены эффективные средства, а не все. Для указанного примера это - TStrings/TStringList.

Ответ на »сообщение 624« (Сергей Перовский)
___________________________

Вы же сами писали, что это во многих случаях очень неэффективно.
Поэтому я и написал о "субконтейнерах" со своим собственных форматом, где это необходимо. Опять же, с течением времени все будут постепенно приходить к Unicode, так что конвертаций будет все меньше.
Сейчас компилятор про кодировки ничего не знает :(
Известно только количество байт на символ.
Почему же: у нас уже сейчас есть AnsiString, ShortString, PChar, Utf8String, WideString, так что компилятор знает о формате строки, и способен выдать предупреждение, где происходит неявное преобразование. Если же строка будет объявляться как String, а внутренний ее формат (AnsiString, PChar, Utf8String) устанавливаться во время исполнения при присвоении строки значения, тут естественно компилятор ничем не поможет.
Подавляющее большинство операций обработки строк должно быть в стандартной библиотеке. Так, что предусмотреть придется один раз. Вряд ли это сильно скажется на объеме кода.
Поверьте, предусмотреть все возможные действия над строками в стандартной библиотеке не под силу никому. Например, я часто использую функцию, которая извлекает из входной строки начало вплоть до указанного разделителя, и возвращает начальный элемент и остаток. Ее нет в RTL.
А ShortString или AnsiString в разных кодировках это разные типы?
Попробуйте сложить - получите полную ерунду, а компилятор молчит.
Да, я об этом писал чуть ниже. Компилятор должен выдавать при неявном преобразовании предупреждение (а еще лучше - ошибку).
AnsiString (которая по умолчанию) так и работает, и ничего.
Вобщем да, но теперь размер будеть еще зависеть и от типа строки. А в случае с UTF8 - и от конкретных символов, которые она содержит. Т.е. в этом случае нельзя будет вычислить строку просто по формуле size := число_символов * sizeof(размер_символа).

Ответ на »сообщение 623« (Aleg Azarousky)
___________________________
Я б даже написал не "долго", а "всегда".
Сойдемся на "очень долго" :)
Поэтому я представляю себе Delphi-приложение как некий программный контейнер, внутри которого строки будут в формате UTF-16, а строки из всех внешних источников, будь то файлы, буфер обмена, информация из Интернет, БД и т.п., должны конвертироватся в наш внутренний формат.
Вы же сами писали, что это во многих случаях очень неэффективно.
Опять же многие ошибки поможет отловить компилятор на этапе компиляции.
Сейчас компилятор про кодировки ничего не знает :(
Известно только количество байт на символ.
Если же в любом месте программы любая строка сможет иметь любой внутренний тип (ANSI, UTFx,...), то
1. При любой операции оброаботки строк мы должны предусмотреть все возможные кодировки для строки, даже если появление некоторых кодировок в данном месте маловероятен - код будет раздуваться.
Подавляющее большинство операций обработки строк должно быть в стандартной библиотеке. Так, что предусмотреть придется один раз. Вряд ли это сильно скажется на объеме кода.
2. Отпадет возможность контроля типа строки на этапе компиляции (так как все строки будут одного типа String).
А ShortString или AnsiString в разных кодировках это разные типы?
Попробуйте сложить - получите полную ерунду, а компилятор молчит.

3. Вычисление места, занимаемого строкой, будет возможно только во время выполнения, т.к. зависит от внутреннего типа строки.
AnsiString (которая по умолчанию) так и работает, и ничего.

Ответ на »сообщение 622« (Сергей Перовский)
___________________________
Я б даже написал не "долго", а "всегда". Поскольку даже Unicode-кодировок существует несколько вариантов, и мы этого никак не избежим. Поэтому я представляю себе Delphi-приложение как некий программный контейнер, внутри которого строки будут в формате UTF-16, а строки из всех внешних источников, будь то файлы, буфер обмена, информация из Интернет, БД и т.п., должны конвертироватся в наш внутренний формат. Ну и в самой программе могут быть также некие алгоритмы (субконтейнеры), обрабатывающие строки в своем формате, требующем перекодировки.

Почему так лучше? В таком варианте все места, где происходят преобразования строк, будут строго детерминированы, так что поиск возможных ошибок будет проще. Опять же многие ошибки поможет отловить компилятор на этапе компиляции.

Если же в любом месте программы любая строка сможет иметь любой внутренний тип (ANSI, UTFx,...), то
1. При любой операции оброаботки строк мы должны предусмотреть все возможные кодировки для строки, даже если появление некоторых кодировок в данном месте маловероятен - код будет раздуваться.
2. Отпадет возможность контроля типа строки на этапе компиляции (так как все строки будут одного типа String).
3. Вычисление места, занимаемого строкой, будет возможно только во время выполнения, т.к. зависит от внутреннего типа строки.

...и т.п.

Ответ на »сообщение 620« (Aleg Azarousky)
___________________________
В Delphi 2008 String будет юникод-строка, хранящая свой размер и кол-во ссылок (по аналогии с AnsiString), и поэтому тогда за этим должен следить компьютер.
А обрабатываемые файлы еще долго будут содержать не юникод, а десятки различных кодировок. И как тут компьютеру уследить?
Минимум, от которого уйти не удасться - указывать кодировку открываемого файла.
За всем остальным должен следить компьютер, не переводя все без необходимости в юникод.

Ответ на »сообщение 616« (Денис Зайцев)
___________________________

Согласен! Не знаю, почему это ещё не сделано. Ведь есть уже похожие предупреждения: "Comparing/Combining signed and unsigned types - widened both operands".

Сделано давно в Free Pascal. И, кстати, реально помогает находить потенциальные ошибки.
Вообще FPC стоит иметь хотя бы из-за сурового компилятора.

Ответ на »сообщение 619« (Сергей Перовский)
___________________________
Если мы говорим о текущей версии Delphi, то String = AnsiString, причем в операциях со строками AnsiString в RTL предполагается, что кодовая страница совпадает с текущей кодовой страницей системы. Поэтому пока за этим должен следить человек.

В Delphi 2008 String будет юникод-строка, хранящая свой размер и кол-во ссылок (по аналогии с AnsiString), и поэтому тогда за этим должен следить компьютер.

Но это не значит, что AnsiString автоматически будет списан на свалку истории. Останутся задачи (примеры я давал), для которых он будет оптимальным решением. Не зря в Дельфе до сих пор есть ShortString - у него ведь тоже есть свои преимущества перед AnsiString на определенных задачах. Но учитывая, что эти применения в конкретной программе локализованы, и программист знает о тех местах, где происходят преобразования (ShortString <--> AnsiString <--> PChar <--> UTF8/UTF16/UTF32 strings), ему не составит никакого труда указать явное преобразование типов (т.е. сказать компилятору: все нормально, я за этим слежу)

ShortStr := ShortString(AnsiStr);

вместо отлова багов, возникших в результате неявного присвоения:

var
  ShortStr: string[10];
  AnsiStr: AnsiString;
begin
  AnsiStr := 'Привет, я - длинная строка';
  ShortStr := AnsiStr;
  ShowMessage(ShortStr);
end;

Ответ на »сообщение 617« (Aleg Azarousky)
___________________________
Я за золотую середину. И за сведение к минимуму ошибок из-за неявного присвоения.
S1,S2:string;
S1:=S1+S2;
Это какое присвоение? Если кодировки S1 и S2 несовпадают, почему за этим должен следить человек, а не компьютер?

Ответ на »сообщение 616« (Денис Зайцев)
___________________________

Не, в обоих случаях поведение должно быть одинаковым. Т.е. Runtime error - но только тогда, когда Range checking включено, если выключено - должен молча "преобразовывать".
Проверил в D7 - так и есть.
Вот, а в Turbo Delphi - так как я написал (с Range Check).
Согласен! Не знаю, почему это ещё не сделано. Ведь есть уже похожие предупреждения: "Comparing/Combining signed and unsigned types - widened both operands". Наверное, разработчики боятся, что тогда при компиляции очень многих программ появится столько предупреждений, что это отпугнёт программистов. Или, может быть, считают, что это неотъемлемая фича языка, священная корова (Assignment compatibility). Других объяснений не могу придумать.
Возможно и так. Но я так думаю лучше один раз отловить все ошибки компиляции, чем постоянно бороться с ошибками выполнения.

Ответ на »сообщение 615« (Сергей Перовский)
___________________________

Ответ на »сообщение 614« (Aleg Azarousky)
___________________________
Язык высокого уровня абстрагируется от конкретной системы команд процессора и написанный на нем алгоритм  никогда не станет оптимальным.
Это не аргумент в пользу работы исключительно на ассемблере.
Я не призываю писать все на ассемблере. Я за золотую середину. И за сведение к минимуму ошибок из-за неявного присвоения.

Ответ на »сообщение 614« (Aleg Azarousky)
___________________________

В первом случае мы получим 65535 из исходного 2147483647 из-за неявного преобразования integer --> word. Во втором случае - Runtime error.

Не, в обоих случаях поведение должно быть одинаковым. Т.е. Runtime error - но только тогда, когда Range checking включено, если выключено - должен молча "преобразовывать".
Проверил в D7 - так и есть.

Представляете, как было бы здорово, если бы компилятор выдавал хотябы предупреждение при таких неявных преобразованиях?

Согласен! Не знаю, почему это ещё не сделано. Ведь есть уже похожие предупреждения: "Comparing/Combining signed and unsigned types - widened both operands". Наверное, разработчики боятся, что тогда при компиляции очень многих программ появится столько предупреждений, что это отпугнёт программистов. Или, может быть, считают, что это неотъемлемая фича языка, священная корова (Assignment compatibility). Других объяснений не могу придумать.

Ответ на »сообщение 614« (Aleg Azarousky)
___________________________
Но если алгоритм будет абстрагироваться от внутреннего представления строки, он никогда не станет оптимальным.

Язык высокого уровня абстрагируется от конкретной системы команд процессора и написанный на нем алгоритм  никогда не станет оптимальным.
Это не аргумент в пользу работы исключительно на ассемблере.

Большинство операций над строками хуже всего выполняются над PChar из за неизвестной длины. Это не мешает использовать PChar в ОС, т.е. для подавляющего большинства приложений.

Вам не нужно делать вариантов алгоритма, кроме как для ANSI-строк в кодировке 1251, если вы обрабатываете только русские тексты в CP1251.
Попробуйте работать с текстом на русском, немецком и английском языках.

Ответ на »сообщение 613« (Сергей Перовский)
___________________________
Но если алгоритм будет абстрагироваться от внутреннего представления строки, он никогда не станет оптимальным. Вам не нужно делать вариантов алгоритма, кроме как для ANSI-строк в кодировке 1251, если вы обрабатываете только русские тексты в CP1251. Это будет оптимальным вариантом по памяти и быстродействию. Аналогично, при написании GUI для мультиязычной программы под Win32 нужно использовать UTF-16 - родной формат ОС. А при обработке XML - чтобы избежать лишних преобразований - используем UTF-8.

Вот кстати хороший пример насчет целых чисел, кого это не волнует? В Delphi есть byte, word, shortint, longint и т.п. Они разного размера, со знаковым разрядом и без. Все они нужны и используются для своих целей. Но не все так гладко в Delphi, вот простой пример:

var
  i: integer;
  w: word;
  si: shortint;
begin
  i := 2147483647;
  w := i;
  ShowMessage(IntToStr(w));

  w := 65535;
  si := w;
  ShowMessage(IntToStr(si));
end;

В первом случае мы получим 65535 из исходного 2147483647 из-за неявного преобразования integer --> word. Во втором случае - Runtime error. А если этот код попадет в некое критическое приложение? (Например, в программу начисления зарплаты :) ) Представляете, как было бы здорово, если бы компилятор выдавал хотябы предупреждение при таких неявных преобразованиях?

Ответ на »сообщение 611« (Aleg Azarousky)
___________________________
Когда пишешь сложные алгоритмы, работающие со строками, (например системы машинного перевода, проверка орфографии) ты должен ясно представлять себе с чем имеешь дело: ANSI, UTF8/26/32, UCS-2/4.
Да, должен. И это плохо. Кодировок много и для каждой приходится делать варианты алгоритма. А на самом деле алгоритмы имеют дело с последовательностью символов.
Нас же не волнует способ кодировки целых чисел. Почему должен волновать способ кодировки символов?
О кодировке необходимо думать только на входе и выходе.

Ответ на »сообщение 609« (artemiy)
___________________________
Тут тоже есть смысл: для такой большой системы как Delphi для каждого бага делать свой патч не имеет смысла - это сильно усложнит сопровождение программы. Да и не такой он и критический этот баг.

Ответ на »сообщение 608« (Сергей Перовский)
___________________________
Нет, неявное преобразование строк это зло! Когда пишешь сложные алгоритмы, работающие со строками, (например системы машинного перевода, проверка орфографии) ты должен ясно представлять себе с чем имеешь дело: ANSI, UTF8/26/32, UCS-2/4.

Представляете, если ваш алгоритм заточен на использование ANSI-строк в кодировке CP1251, а тут из какого-нибудь контрола TEdit приходит Unicode-строка, которая соединяется с другими ANSI-строками, неявно преобразуя их в Unicode, и понеслось...

Я б оставил AnsiString в том виде в котором он есть сейчас для обратной совместимости и для использования с алгоритмами, которым Unicode не нужен и даже вреден (по потреблению памяти, скорости обработки и т.п.). А весь GUI в программе, и вообще все остальное писать только с использованием Unicode.

Ответ на »сообщение 607« (Cepгей Poщин)
___________________________
По мне так он и не умирал. Хотя признаюсь честно в конце 2005 - начале 2006 были некие панические настроения, типа куда податся, на Chrome, Visual Basic или Free Pascal.
Но теперь я знаю, что Win32 будет здесь еще долго. И еще неизвестно, выиграли ли те, кто в погоне за модой кинулись писать свои проги под .NET WinForms, который фактически уже считается устаревшим.

Ответ на »сообщение 607« (Cepгей Poщин)
___________________________
Они уже лет 5 преувеличины) Delphi живее всех живых и остается ИМХО лучшей рад.
--
Да апдейт наверно вскоре появится, только очень уж растраивает скорость его выпуска. Тот же баг с контекстным меню непозволительно долго существует. Хотя выпустить патч дело 1-2 дней.

Ответ на »сообщение 605« (Aleg Azarousky)
___________________________
Unicode VCL делать надо полюбому.Сколько можно топтатся на месте?
По мне, это и есть топтание на месте. Нужно снова принципиально изменить string, включив в заголовок кодировку и отдельно длину в символах и байтах. Тогда не будет необходимости писать бесконечные преобразования при операциях со строками и множество вариантов функций для разных кодировок. Например при сложении 2 строк с разными однобайтными кодировками они должны быть автоматически преобразованы в Unicode, а тип данных не поменяется.

Ответ на »сообщение 606« (Aleg Azarousky)
___________________________
Т.Е. я так понимаю, слухи о смерти Delphi несколько преувеличены?

Кста насчет апдейта к студии. Здается мне, он будет объявлен к Code Rage II. Ждать осталось недолго - 26 ноября.

Ответ на »сообщение 604« (artemiy)
___________________________
Из 10 запросов 4 были открыты в этом году, еще 5 - летом прошлого года, когда в команду пришли свежие люди. Так что прогресс есть.

x64 в роадмапе заявлен на зиму 2008, но я где-то в новостях видел сообщение Ника Ходжеса, что этот срок все же будет отодвинут, скорее на начало 2009 года. Хотя как по мне, x64 пока не актуален. Лучше бы кросс-компиляцию для Linux сделали.

Unicode VCL делать надо полюбому. Сколько можно топтатся на месте? Вполне возможно что будет некая регрессия качества. Но наверное многие согласятся, что Delphi 2007 с последними патчами очень стабилен. И есть подозрения, что готовящийся апдейт для RAD Studio сделает этот продукт самым стабильным за всю историю Delphi. Так что учитывая такое внимание к качеству системы будем надеятся, что Delphi 2008 не будет сильно уступать 2007 версии.

Ответ на »сообщение 603« (Aleg Azarousky)
___________________________
Уважаемый, Вы уверены что топ 10 год назад был не в остоянии "открыт", по-моему эти запросы и раньше были открыты.

На счет генериков - конечно работа ведется, еще бы она не велась ведь в роадмапе указан срок ориентировочного выхода Delphi с поддержкой юникода и генериков - первая половина 2008.
А придерживаться роадмапа - это единственное что сейчас нужно Codegear.
И даже x64 запланировано на осень зиму 2008 :-)

Только боюсь я, что столь значительные нововведения приведут к очередному ветку нестабильных версий. Я боюсь думать что будет после реализации Unicode VCL.

Некоторые наблюдения. Судя по этому сообщению ( http://blogs.codegear.com/abauer/2007/11/21/38841/ ) Алена Бауэра, в Delphi, которая в разработке, уже появились типы с параметрами (generics).

На этой странице в Quality Central ( http://qc.codegear.com/wc/qcmain.aspx?p=10 ) есть Топ 10 наиболее популярных возможностей, которые хотели бы видеть разработчики в новой версии Delphi. Интересно, что ВСЕ 10 этих запросов открыты, а значит работа по ним уже ведется. Эта ситуация кардинально отличается от того, что было еще год назад. Поезд тронулся?

И последнее. Здесь ( http://qc.codegear.com/wc/qcmain.aspx?d=8802 ) находится запрос на добавление кросс-компиляции для Linux и OSX в Delphi. Странно, что за него еще никто не отдал голосов. Поддержим?

Ответ на »сообщение 601« (Егор)
___________________________

Может кто знает: Программа которая в Delphi7 весила 1584КВ после компиляции в Delphi2007 стала весить 1787 КВ.
Скомпилируйте ее в Delphi 3 - будет еще меньше.

С чем это связанно? (код мною не менялся)
С "распуханием" VCL и RTL. Поскольку прирост с каждой версией не очень большой, жить это не мешает.

Может кто знает: Программа которая в Delphi7 весила 1584КВ после компиляции в Delphi2007 стала весить 1787 КВ.
С чем это связанно? (код мною не менялся)

Ответ на »сообщение 598« (Егор)
___________________________

поиском по исключительно Delphi пользоваться невозможно, его просто нет в списке языков. Выдаёт примеры только на С++ и бейсике.
Это - да, там совсем все плохо.

а про контекстный поиск я совсем молчу, Button1 не понимает, надо TButton.
Хм... у меня работает. Delphi 2007 Update3 без Help Update.

А "help update" не подскажете где взять?
Отмотайте несколько сообщений назад - как раз про него было обсуждение.


Ответ на »сообщение 599« (Бел Амор)
___________________________

Есть он там: Language: Delphi
Конечно. В D2006 и D2007 разный формат справки.

Ответ на »сообщение 598« (Егор)
___________________________

Буду говорить о Turbo (D2006)

>>> поиском по исключительно Delphi пользоваться невозможно, его просто нет в списке языков.

Есть он там: Language: Delphi

>>> Выдаёт примеры только на С++ и бейсике.

А вот примеров там, похоже, вообще нет...

>>> а про контекстный поиск я совсем молчу, Button1 не понимает, надо TButton.

Если речь идёт о коде, то и более ранние версии вроде такого не понимали. Если речь идет о том, что в дизайнере не работает F1 на выделенный элемент, то это исправляется одним из хотфиксов.

P.S. А справка там действительно отвратная...

Ответ на »сообщение 597« (panda)
___________________________
Ответ на »сообщение 596« (Егор)
___________________________
Совсем нет или только в поиске?
А если help update накатить на Delphi 2007?

Совсем-то есть.., в дебрях.., но как найти то, что мне надо?
поиском по исключительно Delphi пользоваться невозможно, его просто нет в списке языков. Выдаёт примеры только на С++ и бейсике.
а про контекстный поиск я совсем молчу, Button1 не понимает, надо TButton.

А "help update" не подскажете где взять?

Ответ на »сообщение 596« (Егор)
___________________________

Совсем нет или только в поиске?
А если help update накатить на Delphi 2007?

Вопрос по поводу справочной системы в Delphi 2006/7.
Почему в ней есть все языки кроме Delphi? Зачем мне С++, С#, Java, JScript, VB?
Что мне, оставлять D7 ради справки? Или у меня D2007 обрезанная?

Ответ на »сообщение 593« (artemiy)
___________________________

Видимо они поленились сделать патч, а просто запаковали всю обновленную хелп-систему.
Так оно и есть (это было написано в письме от CodeGear).

Сегодня отсюда http://blogs.codegear.com/nickhodges/2007/11/15/38977/ узнал, что в Питере по прежнему работает команда разработчиков Кодгир.
Интересно, чем они там занимаются (Delphi? Together?) Кто нибудь из команды может рассказать?

Вышел CodeGear RAD Studio 2007 Help Update 1.
http://cc.codegear.com/Item/25163

Improvements in Help Update 1:
In the VCL:
Events are now listed as Events, not Properties.
IntraWeb components link to the website of VCL for the Web.
AdoDbxClient information has been updated.
Help is included for .NET SDK.
Delphi code examples have been added or edited in the following namespaces:  ActnList, AppEvnts, Classes, ComCtrls, DataBkr, DB, DBClient, Graphics, System, and SysUtils,
C++ code examples have been added or edited in the following namespace:  ComCtrls, Controls, and System.
In the Delphi Language Guide, an error was corrected about Win32 supporting generics.
Blackfish SQL information has been updated.
Some content has been restored that was missing from Delphi 7.
Help for command line utilities has been restored from Delphi 7 and C++Builder 6.

Прикольно. Только почему он так много весит?) Видимо они поленились сделать патч, а просто запаковали всю обновленную хелп-систему.

Borland Developer Studio 2006 (FULL EDITION -  на 2 DVD) -
СУПЕР!!!

Ответ на »сообщение 587« (al_mt)
___________________________
Эта информация обсуждается в другой теме:
http://www.delphikingdom.com/asp/talktopic.asp?ID=377

Триала пока нет.

CodeGear выпускает Delphi for PHP
http://www.cnews.ru/news/line/index.shtml?2007/02/27/237889

Давно пора! Ни кто не знает где скачать хотя бы триал?

Ответ на »сообщение 582« (Aleksandr)
___________________________

Лицензии на Делфи много дороже лицензий Микрософта. Поэтому в нашей конторе переход с Делфи 5 проходит на второй фреймворк дот Нета. Старый код поддерживается на 5 версии..

Пока на второй переходите, уже третий вышел. Скоро опять платить придется.
О ценах:

Microsoft® Visual Studio® Professional 2005 Win32 English CD/DVD
$799.00
Upgrade Version
$549.00

Delphi 2006 Professional
$1,090.00
Upgrade
$460.00

Ценник Борланда
http://shop.borland.com/dr/sat5/ec_Main.Entry17c?SID=39696&SP=10024&CID=0&PID=&PN=29&V1=31047844&V2=31047844&CUR=840&DSP=&PGRP=0&ABCODE=&CACHE_ID=0
Ценники MS
http://www.microsoft.com/products/info/default.aspx?view=22&pcid=515c9859-958b-4433-b4f9-91f37258ca2f

Ответ на »сообщение 581« (Aleksandr)
___________________________

Как вы думаете, сколько будет стоить организации перейти с одной версии Делфи на другую? Я имею ввиду купить лицензии, потратить время на переобучение программистов (согласитесь, разница между 7 версией и 2005 существенная). Или вы считаете, что лицензии ничего не стоят, и уж тем более ничего не стоит время программистов?
Как вы думаете, сколько будет стоить организации перейти с VB 6 на VB.Net? Я имею ввиду купить лицензии, потратить время на переобучение программистов (согласитесь, разница между 6 версией и 2003/2005 существенная). Или вы считаете, что лицензии ничего не стоят, и уж тем более ничего не стоит время программистов?

Ответ на »сообщение 574« (Марат Сафин)
___________________________
Ответ на »сообщение 567« (panda)
___________________________

Конечно. А сколько будет стоить переход на на новую технологию?
Я думаю стоимость перехода не будет больше стоимости перехода на .Net, а веть в полне возможно через какое то время придется. Вам повезло, что вы не программист VB. Тем более что Вас ни кто не заставляет переходить на dbExpress.
И как мне убедить разработчиков, которые ужу уверились в том, что ADO - намного стабильнее, чем dbExpress?
Я так понимаю это Вы их убеждали в этом, так с Вас и спрос зачем вы заказчиков вводите в заблуждение. Я например ни где не видел сравнения ADO и dbExpress по количеству ошибок.
Драйвер dbExpress для MS SQL Server работает поверх OLE DB.
В том то и дело что ADO работает тоже по верх OLE DB и там также ошибки OLE DB складываются с ошибками ADO.

Лицензии на Делфи много дороже лицензий Микрософта. Поэтому в нашей конторе переход с Делфи 5 проходит на второй фреймворк дот Нета. Старый код поддерживается на 5 версии..

Ответ на »сообщение 579« (Марат Сафин)
___________________________

Ответ на »сообщение 576« (panda)
___________________________

Когда Вам нечего сказать, Вы начинаете переходить на оскорбления?
Если мои слова оскорбили Вас прошу прошения я не хотел.
Почитайте мои посты на Круглом Столе и Базарной площади. Я всячески пропагандировал dbExpress.
Тогда я не понимаю ваших высказываний по поводу dbExpress о том какой он глючный.
Я уже устал повторять: сравните исходный код dbExpress в Delphi 7 до и после апдейт пака (Delphi 7.1).
Возможно в Delphi 7.x были ошибки в dbExpress но уже вышли D2005, D2006 и выходит D2007, а вы до сих пор ведёте разговор о прошлых ошибках. Конечно многие до сих пор пишут программы на Delphi 7 но это их выбор, если люди не хотят использовать более свежие версии продукта то должны соглашаться с ошибками в Delphi 7. Конечно в свежих версиях тоже есть ошибки, но всё таки есть и прогресс.
Я например ни где не видел сравнения ADO и dbExpress по количеству ошибок.
Вам я не собираюсь ничего доказывать.

Я не просил доказывать, что то лично мне это веть открытый форум. Если у Вас есть такое сравнение будет интересно посмотреть не только мне.
Как вы думаете, сколько будет стоить организации перейти с одной версии Делфи на другую? Я имею ввиду купить лицензии, потратить время на переобучение программистов (согласитесь, разница между 7 версией и 2005 существенная). Или вы считаете, что лицензии ничего не стоят, и уж тем более ничего не стоит время программистов?
И кто оплатит время на исправление текущего программного продукта, ибо НИ РАЗУ ни ОДИН ПЕРЕХОД на более старшую версию не проходил без тог, чтобы НЕ НАДО БЫЛО ВНОСИТЬ ИСПРАВЛЕНИЯ В СТАРЫЙ КОД, потому что он с новой версией НЕ РАБОТАЛ!!!

Ответ на »сообщение 579« (Марат Сафин)
___________________________

Возможно в Delphi 7.x были ошибки в dbExpress но уже вышли D2005, D2006 и выходит D2007, а вы до сих пор ведёте разговор о прошлых ошибках.
Может Вы все-таки почитаете то, что я пишу? Еще раз: "В Delphi 7.1 Borland внесла ряд багов в исходный код dbExpress. Эти баги НЕ были исправлены до версии 2006 включительно". Т.е. ошибки не прошлые, а существующие. D2007 я не видел, ничего сказать про нее не могу в этом плане. 
А про 2005 лучше вообще не вспоминайте, у нас на работе до сих пор все кусают локти, что мы ее купили в свое время.

Ответ на »сообщение 576« (panda)
___________________________

Когда Вам нечего сказать, Вы начинаете переходить на оскорбления?
Если мои слова оскорбили Вас прошу прошения я не хотел.
Почитайте мои посты на Круглом Столе и Базарной площади. Я всячески пропагандировал dbExpress.
Тогда я не понимаю ваших высказываний по поводу dbExpress о том какой он глючный.
Я уже устал повторять: сравните исходный код dbExpress в Delphi 7 до и после апдейт пака (Delphi 7.1).
Возможно в Delphi 7.x были ошибки в dbExpress но уже вышли D2005, D2006 и выходит D2007, а вы до сих пор ведёте разговор о прошлых ошибках. Конечно многие до сих пор пишут программы на Delphi 7 но это их выбор, если люди не хотят использовать более свежие версии продукта то должны соглашаться с ошибками в Delphi 7. Конечно в свежих версиях тоже есть ошибки, но всё таки есть и прогресс.
Я например ни где не видел сравнения ADO и dbExpress по количеству ошибок.
Вам я не собираюсь ничего доказывать.

Я не просил доказывать, что то лично мне это веть открытый форум. Если у Вас есть такое сравнение будет интересно посмотреть не только мне.

Баг в QC
http://qc.codegear.com/wc/qcmain.aspx
Введите в поле вверху справа "unicode" и жмите кнопку "Go To Report"

Ответ на »сообщение 551« (Aleg Azarousky)
___________________________

Если кто пользуется Firebird в своих проектах, голосуйте за добавление поддержки Firebird в DBX4 (DBExpress 4):
http://qc.codegear.com/wc/qcmain.aspx?d=40916

Спасибо всем, кто голосовал.
Буквально за два дня эта проблема взлетела на 2-е место среди наиболее востребованных среди пользователей Delphi.

Ответ на »сообщение 574« (Марат Сафин)
___________________________

Я так понимаю это Вы их убеждали в этом, так с Вас и спрос зачем вы заказчиков вводите в заблуждение.
Когда Вам нечего сказать, Вы начинаете переходить на оскорбления?
Почитайте мои посты на Круглом Столе и Базарной площади. Я всячески пропагандировал dbExpress. Это раз. И я говорил не о заказчиках - им то как раз все равно, какая технология используется в ПО, я говорил о программистах, которые каждый день чертыхаются, глядя на непонятную ошибку (про которую гугл выдает: "нестабильный баг dbExpress"). Это два.
Еще нужны факты? Я уже устал повторять: сравните исходный код dbExpress в Delphi 7 до и после апдейт пака (Delphi 7.1).
Я например ни где не видел сравнения ADO и dbExpress по количеству ошибок.
Вам я не собираюсь ничего доказывать.

Ответ на »сообщение 572« (Aleg Azarousky)
___________________________

Просто раз речь зашла о ADO, ADO --> ADO.NET, VB --> VB.NET - общего ничего не находите?
Нет, не нахожу. Я был из тех, кто заявлял Борланду: "Нам не нужен .NET, мы просто хотим лучшее средство разработки под Win32".

Ответ на »сообщение 567« (panda)
___________________________

Конечно. А сколько будет стоить переход на на новую технологию?
Я думаю стоимость перехода не будет больше стоимости перехода на .Net, а веть в полне возможно через какое то время придется. Вам повезло, что вы не программист VB. Тем более что Вас ни кто не заставляет переходить на dbExpress.
И как мне убедить разработчиков, которые ужу уверились в том, что ADO - намного стабильнее, чем dbExpress?
Я так понимаю это Вы их убеждали в этом, так с Вас и спрос зачем вы заказчиков вводите в заблуждение. Я например ни где не видел сравнения ADO и dbExpress по количеству ошибок.
Драйвер dbExpress для MS SQL Server работает поверх OLE DB.
В том то и дело что ADO работает тоже по верх OLE DB и там также ошибки OLE DB складываются с ошибками ADO.

Ответ на »сообщение 565« (panda)
___________________________

DAC - это что?
Возможно я ошибся в названии я просто давненько уже натыкался на объекты доступа базе данных но там потдерживалась только Access (возможно Microsoft Jet)
MDAC = ADO вообще-то.
Здесь вы не правы, MDAC это пакет разных технологий доступа от Микрософт который включает и ADO
OLEDB - это низкоуровневый протокол, через который работает и ADO.
Так OLEDB это технология доступа к данным или нет?
ADO.NET - технология для другой платформы (.NET, а не Win32).
Это и расстраивает что это новая технология, ведь разговор начался с вашей фразы А через пару лет появится Delphi 2009, где будет еще одна технология Это значит что Microsoft и Borland идут схожими путями.
Итого имеем 2 (две) технологии. Сколько их у Borland, сможете посчитать?
Если так считать то у Borland технологий BDE(так же устарела как и ODBC), dbExpress (можно сказать конкурент ADO), BDP(надстройка над ADO.NET)

самая лучшая к тому времени. Я, честно говоря, устал от такой политики Borland.
Вы смеётесь да, посмотрите на Microsoft как они расхваливают Microsoft Vista.

Ответ на »сообщение 571« (panda)
___________________________
Просто раз речь зашла о ADO, ADO --> ADO.NET, VB --> VB.NET - общего ничего не находите?

Ответ на »сообщение 568« (Aleg Azarousky)
___________________________

Ага. А Visual Basic 6 и Visual Basic .Net - это тоже ПОЧТИ одно и тоже... Только почему-то у бейсик-программеров куча проблем возникла с переходом.
Вы издеваетесь или как?
Мы тут вообще-то обсуждаем средства программирования под Win32.

Ответ на »сообщение 540« (Jack Of Shadows)
___________________________

Вот и печальное завершение, уже подумывают о "Дельфи для PHP". Докатились.
Они забыли основное правило бизнеса. Если ты не идешь вперед, то значит ты идешь назад. На месте стоять не получается.
Почему назад?
Возможно, получится неплохой фреймворк для веб-разработки, приближенный к дельфовой по скорости и комфорту программирования.

Риторический вопрос: почему микрософт в АСП.Нет 2.0 так и не добавил функционал вставки новой строки в грид? :)) Толпы кодеров вынуждены пользовать гриды третьих фирм. Добавили копонент-меню. Не прошло и трех лет...

Ответ на »сообщение 567« (panda)
___________________________

Конечно. А сколько будет стоить переход на на новую технологию? И как мне убедить разработчиков, которые ужу уверились в том, что ADO - намного стабильнее, чем dbExpress?
$399. :)
Риторический вопрос. Все познается в сравнении. Если DBX4 действительно такой, как о нем пишут в CG, почему бы и нет? Кроме того, насколько я понимаю Microsoft больше не будет развивать ADO не для .NET. Т.е. вам рано или поздно придется переходить на что-то другое. Если на ADO.NET - о линейке продуктов для Win32 можно забыть.

Насчет глюков OLE DB не понял - как они относятся к DBX?
Драйвер dbExpress для MS SQL Server работает поверх OLE DB.
Да, я понимаю. Тут выход только один: если не хотите глюков OLE DB - используйте другой сервер БД.

Ответ на »сообщение 565« (panda)
___________________________

DAC - это что? MDAC = ADO вообще-то.
OLEDB - это низкоуровневый протокол, через который работает и ADO.
ADO.NET - технология для другой платформы (.NET, а не Win32).

Итого имеем 2 (две) технологии. Сколько их у Borland, сможете посчитать?
Ага. А Visual Basic 6 и Visual Basic .Net - это тоже ПОЧТИ одно и тоже... Только почему-то у бейсик-программеров куча проблем возникла с переходом.

Ответ на »сообщение 563« (Aleg Azarousky)
___________________________

Но я думаю Вы согласитесь: иногда иметь исходники хорошо спроектированной библиотеки с возможностью "захода" в них при отладке гораздо лучше самой хорошей и подробной документации. Которую как заведено мало кто читает.
Конечно. А сколько будет стоить переход на на новую технологию? И как мне убедить разработчиков, которые ужу уверились в том, что ADO - намного стабильнее, чем dbExpress?

Насчет глюков OLE DB не понял - как они относятся к DBX?
Драйвер dbExpress для MS SQL Server работает поверх OLE DB.

Ответ на »сообщение 560« (Марат Сафин)
___________________________

Вам больше нравится политика Microsoft: ODBC, DAC, ADO, ADO.NET, OLEDB и это только те технологии которые я вспомнил на вскидку?
DAC - это что? MDAC = ADO вообще-то.
OLEDB - это низкоуровневый протокол, через который работает и ADO.
ADO.NET - технология для другой платформы (.NET, а не Win32).

Итого имеем 2 (две) технологии. Сколько их у Borland, сможете посчитать?

Ответ на »сообщение 561« (Cepгей Poщин)
___________________________

Что именно сломалось в 7.1, честно говоря, не заметил.
Сходите в тему по продуктам Turbo - я там приводил пример. Ошибка совершенно дурацкая, но исправлять ее до сих пор не собираются (внесли в D7 Update pack).

Ответ на »сообщение 559« (panda)
___________________________

Угу. А dbExpress-драйвер для MS SQL - это черный ящик, который
а) не документирован
б) совмещает в себе все глюки Microsoft OLE DB и свои.

Поймите, мне очень нравится dbExpress. Но чем дальше развивается Delphi, тем больше проблем с ним возникает. И как их решать - не всегда понятно.
DBX 4 по-определению не "черный ящик", поскольку будет поставляться с исходными кодами, как и VCL. Насколько он документирован - я еще не видел. Но я думаю Вы согласитесь: иногда иметь исходники хорошо спроектированной библиотеки с возможностью "захода" в них при отладке гораздо лучше самой хорошей и подробной документации. Которую как заведено мало кто читает. :)

Насчет глюков OLE DB не понял - как они относятся к DBX?

Ответ на »сообщение 558« (panda)
___________________________

А через пару лет появится Delphi 2009, где будет еще одна технология, самая лучшая к тому времени. Я, честно говоря, устал от такой политики Borland.
Никому не хочется переходить на новую технологию, если и старая хорошо работает. Но вот вы пишете: ADO. А ведь сейчас уже есть ADO.NET 2.0, у которой с ADO для Win32 общее только название.

В плане поддержки старых технологий Борланд/CodeGear наголову выше Microsoft. Иногда эта поддрежка получается даже в ущерб развитию. Я б например хотел бы иметь Unicode VCL уже сейчас, пусть даже за счет отсутсвия поддержки Win95/98.

Ответ на »сообщение 555« »сообщение 556« С Delphi6 предпочитаю работать с DBExpress Следует читать "Начиная с версии Delphi6...". Что именно сломалось в 7.1, честно говоря, не заметил.

Ответ на »сообщение 558« (panda)
___________________________

Ответ на »сообщение 553« (Aleg Azarousky)
___________________________

А через пару лет появится Delphi 2009, где будет еще одна технология, самая лучшая к тому времени. Я, честно говоря, устал от такой политики Borland.
Вам больше нравится политика Microsoft: ODBC, DAC, ADO, ADO.NET, OLEDB и это только те технологии которые я вспомнил на вскидку?

Ответ на »сообщение 554« (Aleg Azarousky)
___________________________

Но ADO, как и любая технология от Microsoft - это черный ящик! Да, этот ящик хорошо документирован. Да, есть множество примеров его использования. Но когда вы забираетесь поглубже, пытаетесь использовать транзакции, откаты, многопользовательскую поддержку, многотабличные зависимости, сложные вложенные SQL-запросы, автоинкрементные поля, начинаются мелкие и не очень проблемы, которые иногда сложно устранить.
Угу. А dbExpress-драйвер для MS SQL - это черный ящик, который
а) не документирован
б) совмещает в себе все глюки Microsoft OLE DB и свои.

Поймите, мне очень нравится dbExpress. Но чем дальше развивается Delphi, тем больше проблем с ним возникает. И как их решать - не всегда понятно.

Ответ на »сообщение 553« (Aleg Azarousky)
___________________________

сорвалось :(

Говорить заранее конечно тяжело, но то что я читал о DBX 4 говорит о том, что это будет лучшее решение из всех, что когда-то предалагал Борланд: BDE, IBX, ADO, BDP...
А через пару лет появится Delphi 2009, где будет еще одна технология, самая лучшая к тому времени. Я, честно говоря, устал от такой политики Borland.

Ответ на »сообщение 555« (Cepгей Poщин)
___________________________

У меня сложилось противоположное мнение. С Delphi6 предпочитаю работать с DBExpress.
Сергей, Вы не заметили, что я указал 7.1 и более позние версии (а не 7.0)? В ветке про Turbo Delphi я рассказывал (некоторое время назад), как Borland сломала dbExpress.

Ответ на »сообщение 552« (panda)
___________________________
Посмотрев DBX в Delphi 7.1, 2005 и 2006 (TD), я решил переходить на ADO. У меня сложилось противоположное мнение. С Delphi6 предпочитаю работать с DBExpress.
А вот от ADO остался неприятный осадок. Надо было сделать программку, которая читала одну табличку из Access. Сложность в том, что она должна была работать на очень разных компах и с очень непродвинутыми пользователями, т.е. установка должна происходить по нажатию одной кнопки. Мои бодания были достойны кисти поэта ..., удалось добиться почти 100% устанавливаемости, но при этом в некоторых случаях переставала работать другая программа. С установкой DBX проблем ни когда не возникало, и размер дистрибутива гораздо меньше.

Ответ на »сообщение 552« (panda)
___________________________
Я сейчас тоже использую ADO в парочке небольших програмок, работающих поверх MS Access. Но ADO, как и любая технология от Microsoft - это черный ящик! Да, этот ящик хорошо документирован. Да, есть множество примеров его использования. Но когда вы забираетесь поглубже, пытаетесь использовать транзакции, откаты, многопользовательскую поддержку, многотабличные зависимости, сложные вложенные SQL-запросы, автоинкрементные поля, начинаются мелкие и не очень проблемы, которые иногда сложно устранить.

А новый DBX 4, ПОЛНОСТЬЮ переписанный на родной Дельфе, будет поставлятся с исходниками, и предоставлять подробный и понятный лог всех действий с БД (почитайте ссылки, которые я приводил). В общем я бы не спешил с окончательными выводами.

Ответ на »сообщение 552« (panda)
___________________________
Говорить заранее конечно тяжело, но то что я читал о DBX 4 говорит о том, что это будет лучшее решение из всех, что когда-то предалагал Борланд: BDE, IBX, ADO, BDP... И не я один так считаю, вот обзор с "Дельфи+"
http://www.delphiplus.org/articles/review/codegear-delphi-2007.html

Хотя BDE и dbGo также останутся, по крайней мере в Delphi 2007.

Ответ на »сообщение 551« (Aleg Azarousky)
___________________________

Ну их нафиг. Посмотрев DBX в Delphi 7.1, 2005 и 2006 (TD), я решил переходить на ADO.

Если кто пользуется Firebird в своих проектах, голосуйте за добавление поддержки Firebird в DBX4 (DBExpress 4):
http://qc.codegear.com/wc/qcmain.aspx?d=40916

Возможно вы уже знаете, что в новой Дельфи в качестве технологии сопряжения с базами данных будет использоваться новая версия DBX 4. Она заменит DBX 3 и BDP (Borland Data Provider). Причем исходники DBX4 для Win32 и .NET общие.
http://blogs.codegear.com/steveshaughnessy/archive/2007/02/16/31865.aspx
http://blogs.codegear.com/NickHodges/archive/2007/02/17/31874.aspx

А сегодня Ник сказал, что исходники DBX4 (кстати ПОЛНОСТЬЮ переписанные на чистой Дельфе) будут поставляться с Дельфи! Более того, возможно также будут поставляться исходники драйверов DBX4 для Interbase и MySQL!

Michael Swindell сегодня отметил на форумах, что "There will not be any Turbo editions coming from Spacely". Судя по всему, обновлений линейки Turbo не будет релиза студии, который должен состояться где-то во второй половине года.

Ответ на »сообщение 546« (Denis)
___________________________

Вопрос всем кто зарегистировался  на Delphi Field Test Program.
...

Отбой, проблема решена.

Вопрос всем зарегистировался  на Delphi Field Test Program.
Я тоже зарегистрировался , скачал последний билд, но поставить не могу - где взять Product License Key для инсталлятора?
Помогите плиз, хожу как кот вокруг сметаны :-(((

Два новых скриншота Delphi Spacely:

http://www.bobswart.nl/Weblog/Blog.aspx?RootId=5:872

http://blog.marcocantu.com/blog/spacely_screen_shot.html

Из второго скриншота можно сделать вывод, что CG-овцы добавили компонент для вистовского TaskDialog'а. Хотя, может, они его установили сторонним методом, но вряд ли.

Ответ на »сообщение 543« (artemiy)
___________________________
Одно исправление (см. »сообщение 507«) я заметил!
А вот другие досадные ошибки проигнорированы: »сообщение 394 в теме №372 на БП« »сообщение 357 в теме №372 на БП«
Будем ждать...

P.S. Кстати указанная ссылка у меня не работает. Надо зайти на http://info.borland.com/06/bds/bds2006_reg_updates_down.html и ткнуть кнопку в столбце ftp

Кодегир выпустил новые фиксы для БДС и турбо!
6 новых фиксов: 10a-10f.

вот новый ролуп, включающий в себя эти фиксы
http://altd.borland.com/download/bds/bds_2006/hotfixes/hotfixrollup2/BDS2006HotFixRollup2.exe

редейм
http://bdntv.borland.com/pix/NickHodges/HotFixRollup2Readme.txt

BDS2006 Update 2 Hotfix 10a
Description of updates that are included in this hotfix:
This hotfix contains a fix for the source code editor.  If the source code contained
accented or international characters, viewing the code as text and then returning to
the file format would erroneously reset the source code to default ANSI, thereby losing
the accented or international characters.

The source code (.pas) might become corrupt, especially if the source code was
larger than 64K and if the accented or international characters occurred only after
the intial 64K.

Quality Central Tracking Number(s): 32936, 32844
Internal Tracking Number(s): 241502, 241552
===============================================================================

BDS2006 Update 2 Hotfix 10b
Description of updates that are included in this hotfix:

This fix incorporates the following enhancements and fixes:

- The enhancement suggested in QC Report # 26063 to improve the SOAP
  deserialization of multiref objects and arrays.
 
- The WSDL importer now exposes elements with 'maxOccurs="unbounded"'
  as arrays and the SOAP runtime handles the conversion to and from XML. (QC #35512)

- TXSDateTime (and other TXSxxxx types) can now be serialized as XML attributes (QC #10969)

- The WSDL importer now handles schemas included or imported by the schema
  embedded within a WSDL.

- An uninitialized TXSDateTime will default to the value of "0001-01-01T00:00:00" instead of
"1899-12-30T00:00:00.000".
 
- The WSDL published by Delphi applications was updated to be more compliant with
  the style expected by WSDL2Java importers.
 
- The SOAP runtime properly restores enumerated identifiers that were renamed
  because of conflicts with Delphi keywords or directives.

Quality Central Tracking Number(s): QC #26063, QC #33512, QC #10969
Internal Tracking Number(s): RAID #241798, #241801, #242796
===============================================================================

BDS2006 Update 2 Hotfix 10c
Description of updates that are included in this hotfix:

Removes the length limitation on search paths.  Specifying a large number of deeply
nested directories could exceed an internal limit.


Internal Tracking Number(s): RAID #242012
===============================================================================

BDS2006 Update 2 Hotfix 10d
Description of updates that are included in this hotfix:

This hotfix addresses the issue of Korean characters in the code editor initiating
unwanted cold folding and causing access violations. 

Quality Central Tracking Number(s): 35357
Internal Tracking Number(s): 242562
===============================================================================
BDS2006 Update 2 Hotfix 10e
Description of updates that are included in this hotfix:

This hotfix contains a fix for the VCL form designer to allow the F1 help key
to query the help system for the selected component.
===============================================================================

BDS2006 Update 2 Hotfix 10f
Description of updates that are included in this hotfix:

This fix enables all COM\ActiveX menu items and wizards that are in the
Pro version of Delphi.

Ответ на »сообщение 541« ()
___________________________

Ответ на »сообщение 540« (Jack Of Shadows)
___________________________

Это особенно полезно, когда впереди - пропасть. Инновации? Ну-ну.
У меня на работе как то было тяжелое положение на столько тяжелое, что я написал заявление об увольнении и тяжелое положение стало нормальным и зарплату повысили.
Это я к тому, что иногда в тяжелом положении нужно сделать шаг в пропасть, что бы стать на голову выше.

Ответ на »сообщение 540« (Jack Of Shadows)
___________________________

Они забыли основное правило бизнеса. Если ты не идешь вперед, то значит ты идешь назад. На месте стоять не получается.

Это особенно полезно, когда впереди - пропасть. Инновации? Ну-ну.

Ответ на »сообщение 539« (Anton Filatov)
___________________________
Ну чем это хорошо или плохо наверное надо спросить у самих Борланд, которые в 1995 году не испугались выпустить совершенно новый язык Дельфи, несмотря на то на рынке уже были популярные VB и С++.
Борланд удачно выстрелил именно потому что смотрел вперед, а не плелся позади фаворитов.

К сожалению на этом их инновации и завершились. Они задоили "золотую корову" дельфи до смерти, почивая на лаврах одноразового успеха. И ни разу не рискнули за все эти годы выйти на рынок с очередной инновацией.
Видимо после ухода Андерса Хейлсберга, инноваторов у них не осталось.
Вот и печальное завершение, уже подумывают о "Дельфи для PHP". Докатились.

Они забыли основное правило бизнеса. Если ты не идешь вперед, то значит ты идешь назад. На месте стоять не получается.

Ответ на »сообщение 532« (Jack Of Shadows)
___________________________

Жаль что они ведутся на коньюктуру и создают новый Дельфи для PHP - того что популярно, невзирая на то куда движется программирование.

А чем это плохо? На этом рынке именно клиенты решают, что сейчас популярно, а вовсе не CG и не "правильность" языка программирования. Потому что клиенты приносят деньги, а CG - коммерческая компания. А малопопулярные, но "правильные" языки пусть энтузиасты сами для себя разрабатывают и продвигают.

Ответ на »сообщение 537« ()
___________________________
Даже страшно становится.
А вы не бойтесь. Учиться не страшно. :))

Ответ на »сообщение 536« (Jack Of Shadows)
___________________________

PHP был создан в 1994 году каким то программистом (не специалистом в области языков программировнаия) для того чтобы заменить его перловые скрипты для веба.

У Вас очень глубокие познания. Даже страшно становится.

Ответ на »сообщение 535« ()
___________________________
А кто может определить, где зад, а где перед?
Я могу определить :))
PHP был создан в 1994 году каким то программистом (не специалистом в области языков программировнаия) для того чтобы заменить его перловые скрипты для веба. PHP означает "Personal Home Page" Tools. То есть скрипт для Васей Пупкиных для создания их "хомяков" как на жаргоне называются домашние странички.
Этот язык создавался как один большой швейцарский нож где есть "все что нужно". Причем это "все что нужно" невероятно разрастается от версии к версии.
Это ТОЧНО шаг назад даже по сравнению с таким ретроградом как паскаль.
...хотя это зависит наверное от того в какую сторону вы смотрите :))

Ответ на »сообщение 534« (Jack Of Shadows)
___________________________

Правильно, однако куда бы оно не двигалось, оно не движется назад (PHP) :))

А кто может определить, где зад, а где перед? И почему обязательно движение должно быть вдоль линии? "Не суди, да не судим будешь" (Евангелие от Матфея)

Ответ на »сообщение 533« ()
___________________________
Программирование движется не в одном направлении.
Правильно, однако куда бы оно не двигалось, оно не движется назад (PHP) :))

Ответ на »сообщение 532« (Jack Of Shadows)
___________________________

Жаль что они ведутся на коньюктуру и создают новый Дельфи для PHP - того что популярно, невзирая на то куда движется программирование.

Программирование движется не в одном направлении. Как бы кому ни хотелось одного единственно правильного направления.