[DEM]

Родилась идея, о создании бесплатного аналога программ Арабат, Кристал, Вест и отдельных модулей НормКада....
Данный проект можно сделать с открытыми исходниками а разработку его вести на основе ГитХаба или Google Code....
В качестве языка программирования предлагаю принять VB.net т.к. он все таки победил в теме....
Можно было конечно принять матерный, но к сожалению, тогда придется проект делать закрытым, и исходники хранить на флешках в защищенных от доступа детей местах...
Прошу высказывать свои пожелания и предложения к данному проекту...

PS. Прошу всех кто согласен участвовать в проекте отписаться в личку....

Список участников:
DEM
bargool
RrRR
ябс
Cosinus
swell{d}
Akim_1989
Djur
Ratmir
Yasnogor
P1@t0n
GradRusStroy
gabidullin

PS. Всем заинтересованным, во включении каких то программ, прошу заполнить форму, чтобы можно было добавлять программу....

[DEM]

Дык по пробуй найти вариант запуска своего экзеника с определенными параметрами...
По сути вот это Батник запуска..

Код:

[Выделить все]

python.exe module1.py -u ХХХ -f ХХХ

Где -u и -f ключи а ХХХ это значения...
То есть грубо говоря твой экзшеник надо будет запускать вот так...

Код:

[Выделить все]

test_moment.exe -q ХХХ -L ХХХ

Он должен будет определить с какими ключами его запускали и использовать их....

[DEM]

В результате обсуждения с Димой и bargool
Родился следующий документ и предварительный интерфейс программы....
Я уж совсем было отчаялся, и думал уже отказаться от использования Лазаруса в пользу Vb.net но потом понял что смысла в полном отображении отчета на предварительной вкладке нету(просто у Лазаря очень мало вьюеров), возможно потом перейдем и на другую платформу в принципе переделать там не сложно будет, главо обкатать основные принципы обмена данными между оболочкой и расчетным модулем....

[zamtmn]

Наведу чуток критики:
DEM, описание интерфейса конечно хорошо, но

Координаты расположения элемента

нафиг не нужно, ты пробовал таким образом руками нарисовать сложный интерфейс? Имхо должны быть описаны группировки элементов и порядок их расположения, а еоординаты должны вычисляться в рантайме.
Ты описываешь интерфейс и он у тебя взаимодействует с "расчетным модулем", помоему если описывать отдельно данные и отдельно интерфейс будет гораздо гибче - модуль использует данные для расчета, данные отображаются в интерфейсе. В итоге модуль никак не завязян на интерфейс и ему пофиг на его реализацию - в браузере или форме лазаруса или вообще модуль запущен из консоли и данные вводятся руками

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

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

[DEM]

Сообщение от zamtmn нафиг не нужно, ты пробовал таким образом руками нарисовать сложный интерфейс? Имхо должны быть описаны группировки элементов и порядок их расположения, а координаты должны вычисляться в рантайме.

Попрошу пример, я как бы не очень понимаю о чем ты говоришь, я просто хотел в начале использовать для ввода данных Грид, но потом понял что это будет не очень хорошо....
Сейчас есть идея задействовать для этого дела IpHtml-панель, а интерфейс делать в html, там же задавать события, сейчас мне осталось разобраться как обрабатывать события в Html, пример нашел уже, сперва думал не получится, теперь понимаю что это возможно....

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

Тут одна фишка есть как ты знаешь, у строителей довольно большой сортамент....
Поэтому будут комобоксы которые будут взаимосвязаны, если мы предположим выбрали швеллер, то во втором комбобоксе будут все швеллера, если выбрали двутавр, то будут сечения двутавров....
Для этого я думаю лучше всего сделать следующее, если мы выбрали двутавр, то оболочка сообщает расчетному модулю(тут возможно несколько вариантов, либо расчетный модуль запускается сразу с программой и ждет команд, либо его запускаем каждый раз заново), что select_dvutavr расчетный модуль обрабатывает эту команду и отправляет список сечений двутавров....
Потому как в интерфейсе подобную взаимосвязь сделать будет довольно сложно...
А в расчетном модуле, это будет библиотечная функция.....
Т.к. ему самому надо будет обращаться к библиотечной функции сортамента и получать геометрические характереситики этих двутавров или еще чего то....
Можно конечно в Лазаре тоже сделать модуль для считывания списков сортамента и т.п. из библиотеки, но оно нам надо???
Пусть каждый делает свою часть работы....

PS. Нашел программу которую можно было бы использовать для расчета МКЭ в нашем проекте....
Для плоских схем подойдет как нельзя лучше, исходники предоставляются....
Нужны специалисты в Делфях.....
Вот прога Mke-Win2009 http://www.win-ni.narod.ru/Mke3.htm
Глянул вроде так очень даже ничего, и самое главное сразу НАША, Российская, а не Голандская...

[Kinzer]

DEM, Может лучше создать сразу нормальную базу данных в MySQL или чем-то другом и даже сделать маленькую интерактивную программку для пополнения бд в интерактивном режиме. А потом уже подключать к лазарю. Если будете что-то менять будет легче перестраиваться.
По поводу МКЭ вот хороший пост, если не видели. http://s.arboreus.com/2008/03/free-s...ving-pdes.html

[DEM]

И учитывая, что GNU/Linux — сегодня главная платформа для численных расчётов, это неудивительно. К сожалению, не все, кому приходится впервые сталкиваться с численными расчётами знают об этих программах. Чаще всего на слуху пара названий коммерческих продуктов с закрытым исходным кодом, ограниченными возможностями расширения и астрономической ценой. Этим мини-обзором я хочу исправить такую ситуацию и рассказать о свободных программах. Я надеюсь, этот обзор будет полезен тем, кто начинает заниматься численными расчётами и ищет подходящее программное обеспечение.

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

[Кулик Алексей aka kpblc]

Offtop: Не смог удержаться:

Сообщение от DEM БД на фиг не надо

Ну-ну, блажен кто верует, ему тепло.

[DEM]

Кулик Алексей aka kpblc
Просто не каждому разработчику объяснить как с этой БД работать, да и зачем если лучше чтобы было проще и понятнее работать....
Твой сарказм не уместен...

[Кулик Алексей aka kpblc]

DEM, во-первых, "как работать" - проблема нормального документирования и / или (для особо одаренных) нормального интерфейса. Во-вторых, без нормальной БД не менее 50% твоих программ скажут ква, не успев открыть глазенки. В особо тяжелых случаях работать будет каждая сама по себе без возможности нормальной передачи данных. Охота такое словить? Вперед, мешать не стану.

[gomer]

Если уж так хочется отчеты, можно в опен офис все сделать, правда там сдк черт ногу сломит, зато не надо никаких связок, ткнул меню, в форме забил исходные данные, нажал кнопочку и отчет готов, с формулами и со всем остальным

[Chardash]

Offtop:

Сообщение от gomer нажал кнопочку и отчет готов

это можно и в ворд, функция - рассылки, создается ексель файл, там все формулы и тд и вордовский, в котором то же, но в виде нужного отчета.

[DEM]

Кулик Алексей aka kpblc
Не моих программ, а тех кто их разрабатывает...
Для получения данных из таблиц cvc есть простые модули, не проще ли воспользоваться ими, чем работать с бд...
Ведь проще и понятнее когда вот она есть папка где лежат файлы они называются определенным образом и т.д. в них есть таблицы ВЕТРа и т.п. откуда ты получаешь значения...
Чем устаналивать MySQL потом заполнять её поддерживать и документировать, нет тут уж извольте...
gomer
По части отчетов, ты не прав, лучше использовать docx, к тому же договорились что ни каких дополнительных программ не устанавливать, все должно работать с флешки.....

[gomer]

Сообщение от DEM По части отчетов, ты не прав, лучше использовать docx, к тому же договорились что ни каких дополнительных программ не устанавливать, все должно работать с флешки.....

docx - это, фактически, спиределанный odt, это раз, есть портабле опен офис, причем официальный, это два
Питон - это хорошо, поначалу, но когда люди попросят хлеба, а они непременно это сделают рано или поздно, то от питона придется отказаться, в пользу того же паскаля, к тому же придется писать собственный SDK.
Все равно, для получения отчетов нужно будет иметь или опен или мс офис, либо искать внятные библиотеки, в первом случае может и можно найти бесплатную, во втором - сомневаюсь

[zamtmn]

DEM
Я когдато выше по топику уже спрашивал статический будет интерфейс или динамический, тогда вроде был статический, сейчас стал динамический)) Загрузка вариантов из модуля - плохое решение, лучше иметь 2 комбобокса с разным содержимым (но заранее определенным) и управлять их видимостью (причем управление видимостю лучше отдать интерфейсу, например разместив швеллер и двутавр на разных вкладках) Взаимодействие программа-модуль нужно делат как можно проще, иначе написание модуля будет мУкой

Сейчас есть идея задействовать для этого дела IpHtml-панель, а интерфейс делать в html,

Модуль должен быть независим от реализации гуя. Ты сейчас напридумываешь хитрое взаимодействие гуй-модуль, в итоге выйдет что проще сделать гуи внутри модуля.
Придумывать нужно не описание и реализацию гуя, а описание того что будет запрашивать модуль от оболочки, как и на чем эти запросы визуализируются не важно.

[Kinzer]

gomer,

Сообщение от gomer от питона придется отказаться, в пользу того же паскаля,

Серьезно? На питоне такого рода программу вполне можно написать.
Про odt согласен. Тем более что последние версии Офиса Майкрософта его поддерживают.
И что здесь все понимают под отчетами? Их писать можно хоть в .тхт , .odt, .doc,.docx. А юзеру предоставить возможность выбора. Вы же не хотите реализовывать конструктор отчетов? Сначала вообще нужно забить на рисунки и формулы и реализовать все отчеты в .тхт. Создаете файл с любым разрешением и пишете туда всю информацию какую нужно. В теории офис для этого нужен только чтобы проверить результат.

Сообщение от DEM Для получения данных из таблиц cvc

Наверное, csv файлы все же. От Comma-Separated Values. Вопрос в масштабируемости, возможности внесения корректировок и удобстве работы. Захотел юзер добавить свое наименование и что дальше? Лезть ему и писать в блокнотике или открывать тот же Эксель и редактировать их в ручную. С таким успехом можно написать все в макросах для Экселя и забыть.

Сообщение от DEM Чем устаналивать MySQL потом заполнять её поддерживать и документировать, нет тут уж извольте...

Вы не поверите, но заполнять вам придётся вручную и csv файлы. Вот только сведете количество ошибок при заполнении к минимуму. Не знаю что именно вы имеете в виду под документированием и поддержкой, но поверьте, когда у вас будут сотни csv файлов вы еще намучаетесь.

[Chardash]

да, питон или фортран, или то и другое. и лучше всего, все чтобы крутилось на Django. тогда интерфейсом не нужно вообще заморачиваться (несложно сделать css и html при необходимости), он лайн расчет.

[DEM]

Сообщение от zamtmn DEM Я когдато выше по топику уже спрашивал статический будет интерфейс или динамический, тогда вроде был статический, сейчас стал динамический)) Загрузка вариантов из модуля - плохое решение, лучше иметь 2 комбобокса с разным содержимым (но заранее определенным) и управлять их видимостью (причем управление видимостю лучше отдать интерфейсу, например разместив швеллер и двутавр на разных вкладках) Взаимодействие программа-модуль нужно делат как можно проще, иначе написание модуля будет мУкой Модуль должен быть независим от реализации гуя. Ты сейчас напридумываешь хитрое взаимодействие гуй-модуль, в итоге выйдет что проще сделать гуи внутри модуля. Придумывать нужно не описание и реализацию гуя, а описание того что будет запрашивать модуль от оболочки, как и на чем эти запросы визуализируются не важно.

Не знаю, но я по моему сразу говорил что потребуется изменять, значения одного некоторых элементов в процессе расчета....
между прочим и ваш модуль для этого тоже подойдет, если там дать возможность запроса к расчетному модулю....
А в написании ничего сложного не будет, т.к. сортамент и команды которые он выдает будет библиотечной функцией....
Вариант еще сделать 2 функции, одна будет Лазаре обрабатывать форму и получать список профилей, а другая будет в Питоне или еще где либо....
PS. Ребят обсуждение уже прошло, сейчас идет реализация и разруливание некоторых нюансов, можете не стараться и не писать свои посты по части какой стандарт принять в качестве вывода отчета и т.п. Так же не обсуждается уже формат БД, SQL модуля не будет, на этом этапе проекта, возможно когда то он будет добавлен, а пока он не нужен....
Делайте свою программу и реализовывайте в ней свои задумки....

[zamtmn]

между прочим и ваш модуль для этого тоже подойдет, если там дать возможность запроса к расчетному модулю.... А в написании ничего сложного не будет, т.к. сортамент и команды которые он выдает будет библиотечной функцией....

Там это сделано не запросом в модуль, а описанием нужных параметром в отдельном файле. Собственно что я и предлагаю: вместо связки гуи-модуль иметь 2 связки гуи-параметры модуля и параметры модуля-модуль. Что позволит не меняя структуру модуля прикрутить к нему любой гуй и к существующему гую прикрутить любой модуль. Для описания взаимодействия гуи-параметры модуля разработать некий API или SDK - кому как угодно.

[DEM]

Да я понял что у тебя есть файл описания шум модуля, но не будем же мы туда весь сортамент запихивать.....
Можно конечно и API сделать, но не проще ли будет тогда чтобы сортамент просто выбирался из папки в которой есть файлы с определенными названиями и структурой....
Но проще по моему мнению обращаться к расчетному модулю за данными...
Постараюсь выложить через неделю свой вариант...
Если сможешь подготовить свой то можно будет обсудить преимущества вариантов и дальше доделать...
Просто понимаешь там же надо будет и картинки сделать и на форме, и придется запрашивать для этого расчетный модуль...

[zamtmn]

Да я понял что у тебя есть файл описания шум модуля, но не будем же мы туда весь сортамент запихивать.....

Я и предлагаю всё это продумать и структурировать. Возможно я не понимимаю что такое сортамент, но помоему это такойже тип данных как интегер или флоат, только перечислимый. Т.е. в параметрах модуля оговариваем что он будет использовать длину балки в виде флоат, и размер швеллера из которого сделана балка из дискретного ряда значений, которые определены в программе и это определение одно на все расчетные модули.