Рассматривали, но есть ограничения: 1. Программа инженерная и заточена на работу на локальной рабочей станции. 2. Переделывать придётся ВСЁ. 3. Совместимость со всеми старыми наработками критична.
Вызовы opc da и так в отдельной библиотеке сделаны. Я использовал и в delphi и lazarus компонент virtualtreeview для редакторов свойств, сигналов. Удобная штука.
Application глобальный в пределах одного исполняемого файла (не процесса), т.е. он у каждой DLL загруженной вообще-то свой будет. В Delphi всё обходится без такой инициализации, в Free Pascal в Linux — надо в каждой DLL так делать, если там внутри формы есть.
Портировать задача посильная, но вообще всё сильно зависит от используемых библиотек.
У LabView своя ниша, у нас своя которая с ними пересекается лишь частично. Основное назначение нашего пакета — создание комплексных моделей динамики энергетических установок, включая также и разработку моделей теплогидравлических сетей.
Объективно да — в Delphi работать мне лично удобнее. Поэтому и делал общую кодовую базу — чтобы при изменении в под Delphi автоматом они были в Linux-версии. То есть сейчас если я исправляю что-то в коде — сначала делаю в Delphi, потом после изменений проверяю собираемость и работу под Linux — жму кнопку пересобрать проект там и проверяю так ли оно работает как и в Windows.
При портировании дефайны в основном идут в заголовках и системно-зависимом кода (например при работе с COM-объектами, для некоторых вещей аналогов в линуксе просто нет, например OPC DA). В невизуальном коде расчётных библиотек их мало. Заказчиков на линукс-версию действительно не особо много, но они есть и хотят попробовать. При таком варианте портирования как я делал фактически VCL код старый неизменен и программа дописывается в текущем режиме без разрывов. TMX компоненты мы не использовали, использовали некоторые из JVCL, так что в чём-то было проще. Я за лазарь не агитирую, но по крайней мере что-то сделать работающее получилось. Я не считал подробно сколько у меня строк именно моего кода, но модулей более 900. Трудоёмкость например нашего проекта при частичном переписывании на Java составила 3 года * 3 человека и результат по качеству так себе на выходе был — работало хуже, это без меня делали другие люди. Вообще тут в принципе основное это то, что при портировании оказалось, что можно архитектуру сохранить и использованные технические приёмы разделения программы на части.
Пожалуйста! Пользуйтесь. Возможно я ещё выложу некоторые материалы и исходники наработанные по этому вопросу позже. Из этой статьи приложение было убрано, т.к. кода много.
Для домашнего использования мы бесплатно ключ выписывает. Для мелких задач тоже — делаете заявку и мне в почту кидаете или на официальную. Если бы с нуля делал именно сейчас для gui наверное был бы qt. Но не факт, потому что них коммерческая политика лицензирования не особо дешёвая, да и говорят переход с версии на версию небезударный. Я знаю точно что я бы НЕ использовал — java. На прошлой работе часть моей системы на неё переписали и вышло сильно хуже исходной версии на delphi, да ещё и jni вызовы не быстрые…
Нет. Исходники у меня сейчас одни на всё. 2 файла форм пришлось откорректировать руками после конвертации (замена компонентов), но они редко меняются и это не трудоемко.
Зарплата устраивает. Переписывать на другом стеке это минимум 5 лет работы и долботни будет больше намного, да и текущие средства разработки под наши задачи устраивают. Необходимо обеспечивать совместимость проектов между версиями по и непрерывную поддержку. Программа достаточно сложная и писалась не один год, а главное она вполне боевая и продаваемая.
А их мало которые различаются. Честно говоря тупо лень было и так быстрее получилось. Проблемы основные были с выбором библиотеки 2д графики под линукс и забавными приколами с памятью и многопоточностью.
Вопрос мегаспорный. Это скорее выбор инструмента под задачу и под человека. По сути если писать подобный нашему софт с требованиями скорости работы, кроссплатформенности и нативной интеграции с некоторыми внешними библиотека и на фортрана то выбор невелик — c++ и qt и как не странно Free Pascal с реализацией некоторых критических мест на си. На одной из прошлых моих работ мою систему 3 года переписывали на java и на редкость криво это сделали, хотя я им qt тогда советовал, на что мне ответили что сложно типа на qt. С другой стороны я знаю программы на qt которые разработчики не могут на линукс перетащить почему-то таким же образом. По поводу выбора инструментов под задачи разработки сапр вообще можно подискутировать.
Ну статью могу послать. Если подскажете куда именно. Изменений то в компонентах только в tee chart pro за который фирма 500 баксов заплатила. А разработчикам лазарус эти особенности недурно было бы в справку внести.
Рассматривали, но есть ограничения: 1. Программа инженерная и заточена на работу на локальной рабочей станции. 2. Переделывать придётся ВСЁ. 3. Совместимость со всеми старыми наработками критична.
Вызовы opc da и так в отдельной библиотеке сделаны. Я использовал и в delphi и lazarus компонент virtualtreeview для редакторов свойств, сигналов. Удобная штука.
Портировать задача посильная, но вообще всё сильно зависит от используемых библиотек.
Если вы хотите её помучать пишите в личку или почту.
Для домашнего использования мы бесплатно ключ выписывает. Для мелких задач тоже — делаете заявку и мне в почту кидаете или на официальную. Если бы с нуля делал именно сейчас для gui наверное был бы qt. Но не факт, потому что них коммерческая политика лицензирования не особо дешёвая, да и говорят переход с версии на версию небезударный. Я знаю точно что я бы НЕ использовал — java. На прошлой работе часть моей системы на неё переписали и вышло сильно хуже исходной версии на delphi, да ещё и jni вызовы не быстрые…
Нет. Исходники у меня сейчас одни на всё. 2 файла форм пришлось откорректировать руками после конвертации (замена компонентов), но они редко меняются и это не трудоемко.
Вообще опыт разработки и внедрения системы на протяжении 17 лет сам по себе интересен.
У меня все несколько сложнее — требуется полная совместимость, ну и объем исходников большой.
Зарплата устраивает. Переписывать на другом стеке это минимум 5 лет работы и долботни будет больше намного, да и текущие средства разработки под наши задачи устраивают. Необходимо обеспечивать совместимость проектов между версиями по и непрерывную поддержку. Программа достаточно сложная и писалась не один год, а главное она вполне боевая и продаваемая.
А их мало которые различаются. Честно говоря тупо лень было и так быстрее получилось. Проблемы основные были с выбором библиотеки 2д графики под линукс и забавными приколами с памятью и многопоточностью.
У меня delphi 10.3.3 не вылетает вроде. Code typhon может но редко крайне и это чаще происходило из за заваливания вообще всей операционки сначала.
Вопрос мегаспорный. Это скорее выбор инструмента под задачу и под человека. По сути если писать подобный нашему софт с требованиями скорости работы, кроссплатформенности и нативной интеграции с некоторыми внешними библиотека и на фортрана то выбор невелик — c++ и qt и как не странно Free Pascal с реализацией некоторых критических мест на си. На одной из прошлых моих работ мою систему 3 года переписывали на java и на редкость криво это сделали, хотя я им qt тогда советовал, на что мне ответили что сложно типа на qt. С другой стороны я знаю программы на qt которые разработчики не могут на линукс перетащить почему-то таким же образом. По поводу выбора инструментов под задачи разработки сапр вообще можно подискутировать.
Ну статью могу послать. Если подскажете куда именно. Изменений то в компонентах только в tee chart pro за который фирма 500 баксов заплатила. А разработчикам лазарус эти особенности недурно было бы в справку внести.
В линуксе что надо сделать описано.
Легко. Делаете модуль с формой и в винде он работает. Чтобы окна были в той же группе что и главное application.handle := тоже самое в головном модуле