Здравствуйте, AltCtrlDel, Вы писали:

НС>>О чем проект?

ACD>АСУ ТП

Ох. Тогда даже и не знаю. Наверное лучше всего джава будет.

Здравствуйте, FWP, Вы писали:

ACD>>В C# не хотелось бы, как бы потом кроссплатформенность не приспичила бы.
FWP>Если в проекте нет ничего круто навороченного (низкоуровневое, платформозависимое), то думаю MONO потянет проект практически без переделок.

Только С UI вопросы. Придется сразу на GTK# ориентироваться.

Здравствуйте, AltCtrlDel, Вы писали:

ACD>Да, можно морду на хтмыле делать, благо щас для жабы фреймвёков под это как грязи.

Не советую. Натрахаешься по самое нехочу.

Здравствуйте, aloch, Вы писали:

a> По поводу Linux — думать о переносимости "просто так", без конкретной задачи от заказчика, конечно можно. Но, вдруг, они вместо линукса захотят всех на iPad перевсети?

Дельфя, как раз таки, умеет iOS Mac OS, кстати, тоже. Вот линукс пока не умеет, но обещают.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, AltCtrlDel, Вы писали:

ACD>>Да, можно морду на хтмыле делать, благо щас для жабы фреймвёков под это как грязи.

НС>Не советую. Натрахаешься по самое нехочу.
Нет. GWT избавит от 99.99% html-го/javascript гемора. Насчет грязи- не в курсе. Мне известно GWT, JavaFX- Java, Silverlight- C#, Flex- ActionScript, при этом у только у Java есть кросс-платформа и есть JNI.

Здравствуйте, ArtemGorikov, Вы писали:

НС>>Не советую. Натрахаешься по самое нехочу.
AG>Нет.

Да.

AG> GWT избавит от 99.99% html-го/javascript гемора.

Но не избавит от их глюков и тормозов. Для АСУТП, где типичным является отображение больших схем с кучей мигалок и глюкалок, это может и вовсе стать showstopper'ом.

AG> Насчет грязи- не в курсе. Мне известно GWT, JavaFX- Java, Silverlight- C#, Flex- ActionScript, при этом у только у Java есть кросс-платформа и есть JNI.

А у шарпа есть Моно и P/Invoke.

Здравствуйте, hattab, Вы писали:

H>Кроссплатформа там уже есть, но лучше ее пока не трогать и подождать Delphi XE3.

С XE2 проблемы? Или в XE3 что-то очень хорошее ожидается?

AG>Нет. GWT избавит от 99.99% html-го/javascript гемора. Насчет грязи- не в курсе. Мне известно GWT, JavaFX- Java

SmartClient/SmartGWT, Apache Click, ZK Web Library — это жава. А ещё есть толстые клиенты на jscript+генераторы кода, типа qooxdoo. Там всё представление крутится в браузере, ему только данные подливать через json[P[P]]. для конкретно этого проекта я такое использовать не буду, а вообще хочу попробовать. При этом на сервере остаётся база, бизнес-логика, это можно даже и на сях.

A> Хотят (вполне логично) чтоб под win64 фунциклировало.
A>Не совсем понятно с логичностью. Большинство 32-х битного софта вполне себе функционирует под 64-битной виндой.

Там BDE и Oracle 8. Всё это не идёт под 64. Новый оракл покупать не хотят — дорого очень. Так что переделки в любом случае немалые.

Здравствуйте, AltCtrlDel, Вы писали:

AG>>Нет. GWT избавит от 99.99% html-го/javascript гемора. Насчет грязи- не в курсе. Мне известно GWT, JavaFX- Java

ACD> SmartClient/SmartGWT, Apache Click, ZK Web Library — это жава. А ещё есть толстые клиенты на jscript+генераторы кода, типа qooxdoo. Там всё представление крутится в браузере, ему только данные подливать через json[P[P]]. для конкретно этого проекта я такое использовать не буду, а вообще хочу попробовать. При этом на сервере остаётся база, бизнес-логика, это можно даже и на сях.
Это какая-то экзотика. "ему только данные подливать через json" — очень, очень оптимистичный взгляд
Использовать на сервере C++ imho непрактично- ловить утечки и падения, изобретать свой велосипед с масштабированием. Если, конечно, в железе ограничения нет. Лучше Java или Python. Причем у Python есть Tornado- классная штука. Или поиграться с FreePascal, если получится отрезать бизнес-логику без глобальных изменений кода.

Здравствуйте, AltCtrlDel, Вы писали:

ACD>Доброго времени суток, все!

ACD>Сделал я один проект (большой) ещё в 9ых, с BDE ещё. Сам потом на плюсы с жабой перебрался. А этот проЭкт потихоньку поддерживал. Ну и доподдерживался. Хотят (вполне логично) чтоб под win64 фунциклировало. Наверняка менее затратно, в смысле времени, мне будет купить то, во что делфи превратила шарашка со звучным названием эмбаркадеро, разобраться чё там вместо ВDE заюзать. Но по ощущениям, это мне как привязать себе деревянную ногу (может я неправ). Само то по себе новое изучить я всегда за, но была бы у него перспектива. Другой вариант – конвертнуть в c++/java/ещё чего. В C# нехотелось бы, как бы потом кроссплатформенность не приспичила бы. Объёмная, по любому работа. Но нужно выбирать в куда конвертить (и чем, кстати?), в смысле частично как то же автоматизируется сей процесс?
ACD>Пишу сюда, т.к. тема флеймовая. Писать на форумы по конкретным языкам смысла нет – там всегда будет хорош тот язык, на какой форум пишишь , эт понятно. А так то я открыт для нового. И гуи приложения не обязаны будут 1:1 походить на старые.

BDE -> ADO

AG>Использовать на сервере C++ imho непрактично- ловить утечки и падения, изобретать свой велосипед с масштабированием.

Многие так думают. Но под десктоп то на сях пишут, и ничего. Просто раньше редко у кого был свой веб-сервер, арендовали у хостеров. И те, естественно, нативный код к себе не пускали. А сейчас школота дома сервера держит, обычное дело. Вот с тех времён и остались фреймвёки для создания веб-интерфейса почти только на скриптах и на жаве. Поэтому делать представление веб-приложения на сях — это изобретать велосипеды, да. Всё остальное можно, в умелых руках никакой падучести. апачи то с нжинксами на чём написаны? Аха.

AG> Если, конечно, в железе ограничения нет. Лучше Java или Python.

Нет. Только не Python. У меня к нему аллергия.

Здравствуйте, Alex912, Вы писали:

A> H>Кроссплатформа там уже есть, но лучше ее пока не трогать и подождать Delphi XE3.

A> С XE2 проблемы? Или в XE3 что-то очень хорошее ожидается?

С XE2 проблемы. FireMonkey сырая — жуть. Андроид обещали в скором времени, возможно к XE3 успеют

ACD>Сделал я один проект (большой) ещё в 9ых, с BDE ещё. Сам потом на плюсы с жабой перебрался. А этот проЭкт потихоньку поддерживал. Ну и доподдерживался. Хотят (вполне логично) чтоб под win64 фунциклировало. Наверняка менее затратно, в смысле времени, мне будет купить то, во что делфи превратила шарашка со звучным названием эмбаркадеро, разобраться чё там вместо ВDE заюзать. Но по ощущениям, это мне как привязать себе деревянную ногу (может я неправ). Само то по себе новое изучить я всегда за, но была бы у него перспектива. Другой вариант – конвертнуть в c++/java/ещё чего. В C# нехотелось бы, как бы потом кроссплатформенность не приспичила бы. Объёмная, по любому работа. Но нужно выбирать в куда конвертить (и чем, кстати?), в смысле частично как то же автоматизируется сей процесс?
ACD>Пишу сюда, т.к. тема флеймовая. Писать на форумы по конкретным языкам смысла нет – там всегда будет хорош тот язык, на какой форум пишишь , эт понятно. А так то я открыт для нового. И гуи приложения не обязаны будут 1:1 походить на старые.

А чем Free Pascal с Lazarus наперевес не нравится?

Здравствуйте, AltCtrlDel, Вы писали:

AG>>Использовать на сервере C++ imho непрактично- ловить утечки и падения, изобретать свой велосипед с масштабированием.

ACD>Многие так думают. Но под десктоп то на сях пишут, и ничего. Просто раньше редко у кого был свой веб-сервер, арендовали у хостеров. И те, естественно, нативный код к себе не пускали. А сейчас школота дома сервера держит, обычное дело. Вот с тех времён и остались фреймвёки для

Под виндо- десктоп, еще и на C++ — это или из разряда экзотики в наше время. Новое часто или веб, или Java Web Start (JNLP), с требованием только винды.

EOH>А чем Free Pascal с Lazarus наперевес не нравится?

Я, в последнии годы, от Delphi то был далёк, не точно от его бесплатных заменителей. Просто не в курсАх, насколько оно совместимо, неглючно и т.п.

AltCtrlDel was thinking very hard :

> Свои компоненты тоже правил. Изменений немного, но когда пакеты
> большие (типо RxLib), то замучаешся.

как ни странно, но RxLib живой — http://sourceforge.net/projects/rxlib/

Здравствуйте, AltCtrlDel, Вы писали:

ACD>Я, в последнии годы, от Delphi то был далёк, не точно от его бесплатных заменителей. Просто не в курсАх, насколько оно совместимо, неглючно и т.п.

Где-то начиная с версии 0.9.28 и 0.9.30 оно стало достаточно неглючным и в разработке и в работе, по крайней мере, пробовать что-то сделать на Lazarus вполне можно.

Насчет же совместимости, там совместимость с Delphi далеко не 100%, могут потребоваться заметные переделки. Сам язык FreePascal достаточно хорошо совместим с языком Delphi, есть некоторые специальные опции компилятора для некоторых вещей в плане освместимости. Тут проблем быть не должно.

Но вот визуальная и системная библиотека LCL совместимы где-то так условно на 70%, очень многие вещи делаются иначе. Например, функции печати, есть некоторые отличия в мультипоточной работе. Для вызова программ можно использовать CreateProcess, но лучше класс TProcess и т.д. Или например, все строки с визуальных компонент, типа TEdit идут в utf8, но в системные RTL передавать надо системной кодировке, поэтому даже для вызова FileExist надо писать что-то вроде FileExists(UTF8ToSyS(FileName)) — если в именах файлов используются национальные символы.

То есть, повозиться с портированием придется основательно.

M>в системные RTL передавать надо системной кодировке, поэтому даже для вызова FileExist надо писать что-то вроде FileExists(UTF8ToSyS(FileName))

недайтохобох! И никакой поддержки COM/ActiveX наверняка. Нет уж. Кросплатформенность, сейчас не первая необходимость. Пока воздержусь от этого фрипаскаля.

Здравствуйте, AltCtrlDel, Вы писали:

M>>в системные RTL передавать надо системной кодировке, поэтому даже для вызова FileExist надо писать что-то вроде FileExists(UTF8ToSyS(FileName))

ACD>недайтохобох!

Ну не так страшно как кажется, просто надо внимательнее быть с кодировками. Одни проблемы убраны, другие появились.

ACD> И никакой поддержки COM/ActiveX наверняка.

Да вполне поддерживается COM/ActiveX. Естественно, если их использовать явно, никакой кроссплатформенности, кроме как в винде 32/64 (и то есть нюансы) не будет.