Здравствуйте, rkcsoft, Вы писали:
R>За последнюю неделю это уже вторая тема по этому поводу. И, признаться, в предыдущей я топил за то, чтобы коллега остался на Delphi и никуда не дёргался.
R>Но вмешались обстоятельства.
R>Вкратце. Был SOAP сервис, написанный, изначально, на Delphi XE7. Постепенно, с доработками, он мигрировал до Tokyo. И вот потребовалось внести новые изменения, но даже простая перекомпиляция уже работающих исходников в Delphi Rio приводит сервис в нерабочее состояние с маловразумительными сообщениями об ошибках.
R>В общем устал бороться с ветряными мельницами. Посоветуйте какими путями и как мигрировать с Delphi в светлое будущее.
R>О проекте: есть расчётная (не визуальная часть), она перепишется довольно легко, за месяц-полтора. Проблема в другом. Есть почти 600 *.dfm с логикой (в основном юзабилити, рабочей логики нет) и 150 отчетов FastReport. Всё это писалось с 2007 года. Кто виноват и что Как быть? Есть идеи?
Я бы вынес этот сервис в отдельное приложение и переписал на C#. Таким образом начав постепенно уходить с дельфи.
Здравствуйте, icezone, Вы писали:
I>он такой уже давно I>чтобы это понять не нужно было покупать Tokyo и Rio
Да как-то не требовался дебаггер в большом объёме. Весь критичный код был написан и отлажен давно.
А вот в этом году пришлось его переписать, впервые за 10 лет. И все радости дебага в Delphi Rio пришлось прочувствовать...
Странно, что эту проблему на том же скуле не обсуждают. Там куча людей гнобит все новое от Эмбы, но про проблемы отладки ни разу не видел постов...
Здравствуйте, rkcsoft, Вы писали:
R>Странно, что эту проблему на том же скуле не обсуждают. Там куча людей гнобит все новое от Эмбы, но про проблемы отладки ни разу не видел постов...
у всей линейки XE одна и та же проблема — AV вылетает нет там, где оно реально произошло
сперва бесило, потом привык
Здравствуйте, rkcsoft, Вы писали:
R>О проекте: есть расчётная (не визуальная часть), она перепишется довольно легко, за месяц-полтора. Проблема в другом. Есть почти 600 *.dfm с логикой (в основном юзабилити, рабочей логики нет) и 150 отчетов FastReport. Всё это писалось с 2007 года. Кто виноват и что Как быть? Есть идеи?
Я думаю шарп.
Есть FastReport.net — проверить как он переварит файлы шаблонов.
Для dfm нарисовать свой конвертер. Юзабилити логика скорее всего на чем-то унифицированном реализована? Тоже значит можно будет сконвертировать относительно малой кровью.
R>Есть две проблемы:
R>1. Почти 600 dfm и 150 отчетов. Их быстро на html не переведешь. А хочется быстро, хотя бы в пределах полугода.
За полгода я бы написал конвертер DFM в то, что нужно, хоть в кьют, и конвертер кода из паскаля в плюсики, на 179 день запустил бы их и через полчаса получил бы результат
Здравствуйте, Grayscaler, Вы писали:
G>Есть FastReport.net — проверить как он переварит файлы шаблонов.
FR не переварит. Все отчеты нужно с 0 переписывать. FR был старой версии, 2 чего-то там, до юникода. На юникод мигрировали своими силами. Новый формат вообще с FR не совместим. И, если честно, вообще жалею, что с FR связался по молодости. Там такой говнокод, просто ужас. В начале это было бесплатно (в РФ в конце 90-х вообще весь софт был бесплатен), а потом купил лицензию. Но мигрировать не стал, увидев исходники (четвертая версия была тогда). Хотелось обнять и плакать.
Здравствуйте, Grayscaler, Вы писали:
G>Для dfm нарисовать свой конвертер. Юзабилити логика скорее всего на чем-то унифицированном реализована? Тоже значит можно будет сконвертировать относительно малой кровью.
Здравствуйте, Marty, Вы писали:
M>За полгода я бы написал конвертер DFM в то, что нужно, хоть в кьют, и конвертер кода из паскаля в плюсики, на 179 день запустил бы их и через полчаса получил бы результат
Уже тоже стал подумывать об этом. Ничего сложного, на самом деле, перевести dfm в WinForms. С кодом будут трудности, но это уже легче, тут компилятор подскажет где, что и как.
Спасибо!
P.S. 2 Grayscaler. А у тебя твой личный Help&Manual по прежнему на Delphi?
O>Вполне вероятно что WPF поможет, предполагаю что 600 dfm, достаточно однотипные, а в WPF достаточно легко сделать автогенерацию форм по объектной модели.
WPF после Delphi очень убогая вещь. Frame-ов нет. Забудь про идею написать автоконвертер. Особенно если будешь MVVM следовать. Dependency property — тоже ещё то удовольствие будет.
O>>Вполне вероятно что WPF поможет, предполагаю что 600 dfm, достаточно однотипные, а в WPF достаточно легко сделать автогенерацию форм по объектной модели.
MZ>WPF после Delphi очень убогая вещь. Frame-ов нет. Забудь про идею написать автоконвертер. Особенно если будешь MVVM следовать. Dependency property — тоже ещё то удовольствие будет.
Громко, но не похоже на истину. Так как как раз делал подобное автогенерируемые формы на основе метаинформации.
А какую роль выполняют фреймы в делфи ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
O>>Вполне вероятно что WPF поможет, предполагаю что 600 dfm, достаточно однотипные, а в WPF достаточно легко сделать автогенерацию форм по объектной модели.
MZ>WPF после Delphi очень убогая вещь. Frame-ов нет. Забудь про идею написать автоконвертер. Особенно если будешь MVVM следовать. Dependency property — тоже ещё то удовольствие будет.
Вот честно — сколько строк кода Вами написано в WPF-проектах?
1) Весь WPF — он про реюзабельные windowless-контролы и есть, с самого начала. Контрол может нести в себе другие контролы, те — свои вложенные контролы и т.п. Есть контрол-площадка "делай что хочешь" под названием ContentControl. Есть Grid, который настраивается не хуже HTML-фреймов (а в ячейки можно класть те самые контент-контролы либо что-то ещё по вкусу, со склейкой ячеек строк-столбцов как захочется).
2) Конвертация — для простых случаев выглядит, конечно, несколько многословно, но! Когда окунаешься чуть дальше Hello-world, понимаешь что это они ещё мало навернули — кое-где хочется дополнительных биндингов на параметры, не везде поддерживаются мульти-конвертеры и т.п.
3) Что не так с MVVM? В своё время в Delphi очень не хватало аналогичного подхода чтоб "из коробки" сразу был.
4) Dependency property — согласен, толстый такой бюрократ. Иногда вставляет палки в колёса, что сразу и не поймёшь кто виноват.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, MonsterZam, Вы писали:
MD>2) Конвертация — для простых случаев выглядит, конечно, несколько многословно, но! Когда окунаешься чуть дальше Hello-world, понимаешь что это они ещё мало навернули — кое-где хочется дополнительных биндингов на параметры, не везде поддерживаются мульти-конвертеры и т.п.
Спросил про Фому (аналоги frame-oв из Delphi), а ответили про Ерёму.
MD>3) Что не так с MVVM? В своё время в Delphi очень не хватало аналогичного подхода чтоб "из коробки" сразу был.
MZ>Спросил про Фому (аналоги frame-oв из Delphi), а ответили про Ерёму.
Так что за фреймы в дельфи, какую роль они выполняют ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
MZ>>Спросил про Фому (аналоги frame-oв из Delphi), а ответили про Ерёму.
O>Так что за фреймы в дельфи, какую роль они выполняют ?
Типа контейнеров с контролами и кодом, не знаю как сейчас, но мы еще в Д7 отказались от них.
Перешли на обыкновенные формы, которые можно использовать как хотели использовать фреймы, одни плюсы.
Здравствуйте, rkcsoft, Вы писали:
R>За последнюю неделю это уже вторая тема по этому поводу. И, признаться, в предыдущей я топил за то, чтобы коллега остался на Delphi и никуда не дёргался.
R>Но вмешались обстоятельства.
R>Вкратце. Был SOAP сервис, написанный, изначально, на Delphi XE7. Постепенно, с доработками, он мигрировал до Tokyo. И вот потребовалось внести новые изменения, но даже простая перекомпиляция уже работающих исходников в Delphi Rio приводит сервис в нерабочее состояние с маловразумительными сообщениями об ошибках.
R>В общем устал бороться с ветряными мельницами. Посоветуйте какими путями и как мигрировать с Delphi в светлое будущее.
R>О проекте: есть расчётная (не визуальная часть), она перепишется довольно легко, за месяц-полтора. Проблема в другом. Есть почти 600 *.dfm с логикой (в основном юзабилити, рабочей логики нет) и 150 отчетов FastReport. Всё это писалось с 2007 года. Кто виноват и что Как быть? Есть идеи?
Я думаю надо успокоиться и по нормальному портировать проект на Rio.
Это самый короткий и дешевый вариант.
Здравствуйте, itlab, Вы писали:
I>Все остальное это значит писать почти с нуля.
А мое имхо, надо было годик подождать, после релиза.
Всегда так стараюсь делать, тк нафига детскими болячками своим проектам болеть, пусть другие поносят и рвут на попе волосы, за год в 99% все устаканется, будут патчи или какие то решения.
У меня свободного времени нет, что бы быть тестером, да еще и за свои деньги.
Абракадабра, на сколько я вижу, вообще не тестирует свои продукты.
Раньше Борланд был синоним качества, во всем.
Теперь же только материться хочется.
Впихнули DUnit, но сами ни им, ни другими продуктами тестирования абсолютно не пользуются.
Складывается ощущение у них даже девочки-студентки нет на UI.
Здравствуйте, AWSVladimir, Вы писали:
AWS>А мое имхо, надо было годик подождать, после релиза.
Это с Windows так можно делать. А с любой IDE так не получится. И Delphi, и Visual Studio, и Eclipse и даже JetBrains со своей кучей сред под все языки выпустят кучу обновлений и новых релизов. Оставаться на старом нельзя. Мир изменился. Да, не во всем в лучшую сторону, но увы.
И, в продолжение.
Да нет, Эмба тестирует. Но скромно так. Изменения. Регресс игнорирует. Это общая тенденция, перекладывать тестирование на пользователей. Так дешевле. Например, мне вчера пришло приглашение принять участие в тестировании Rio 10.3.2. Вроде бы и хорошее дело предлагают. Но времени нет. А потом я буду материться, что что-то не работает... В общем человеческий фактор во всём. В 90-е и начало нулевых было иначе. ИМХО — было лучше. Но рассудит только время.
