[DEM]

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

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

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

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

[DEM]

Сообщение от Boxa Как в старом добром линуксе... консольная утилита и ГУЙ к ней =)

НУ фактически так и будет получатся, т.к. Питон в консоли будет висеть...

[Нитонисе]

Сообщение от DEM Подбор арматуры в балке, на основе СКАДовского отчета, или определение армирования в оболочечных элементах.... Все тоже самое фактически, что делает ваша программа ЖаБэ, но только на основании таблиц эксель...

Возможно мы немного о разных вещах говорим. Подход в программировании, когда код, выполняющий одни и те же действия не переписываятся всякий раз, когда делается новая программа, а берется из предыдущей работы - входит в концепцию объектно-ориентированного программирования, которая на сегодняшний день выглядит наиболее продвинутой. На практике это реализуеция так - допустим мы написали функцию, определяющую площадь прямоугольника, которая принимает в качестве аргументов стороны этого прямоугольника - Rectangle(a,b). Как работает функция пользователь даже может не знать, ему главное знать какие типы аргументов она принимает и что возвращает. На простых примерах все выглядит просто, но на сложных, когда, скажем, вам надо будет в функции реализовать расчет многопролетной балки - все гораздо сложнее. Впрочем я не хочу сказать, что ООП ненужно. Напротив - нужно, только надо понимать, что с ООП начинающие программисты не справятся.
Но какую бы функцию мы не писали, для работы с ней потребуется интерфейс. И он будет оконным. Для подавляющего количества расчетных программ это единственно приемлемый вариант. Например если делать интерфейсную часть к работе функции Rectangle - нужно сделать окошко с двумя полями для ввода, куда будут вводиться стороны прямоугольника, кнопку активирующую расчет и окошко, демонстрирующее результат. Без оконного интерфейса не обойтись, используете вы функцию единократно или хотите пакетно обработать 1000 прямоугольников, просто во втором случае интерфйс будет другим, но все равно оконным. И что важно - он должен быть удобным. Нормкад - пример неудачного оконного интерфейса.

[DEM]

Сообщение от Нитонисе Но какую бы функцию мы не писали, для работы с ней потребуется интерфейс. И он будет оконным. Для подавляющего количества расчетных программ это единственно приемлемый вариант. Например если делать интерфейсную часть к работе функции Rectangle - нужно сделать окошко с двумя полями для ввода, куда будут вводиться стороны прямоугольника, кнопку активирующую расчет и окошко, демонстрирующее результат. Без оконного интерфейса не обойтись, используете вы функцию единократно или хотите пакетно обработать 1000 прямоугольников, просто во втором случае интерфйс будет другим, но все равно оконным. И что важно - он должен быть удобным.

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

Сообщение от Нитонисе Нормкад - пример неудачного оконного интерфейса.

НУ дык если бы автор сделал ввод в нормальной форме, а не последовательный ввод данных....
Не с помощью AutoIT я переделал один из расчетов, но эт такой геморой если честно...
Плюнул на это дело и снес НормКАД...

[zamtmn]

Нитонисе
>>У меня вопрос - как вы будете задавать эти данные a,b,c для каждого кабеля?
В идеале с чертежа. и отчет не чертеж. Не в идеале - допустим из csv для упрощения. Главное чтоб у пользователя был выбор, а не только красивый гуй.

>>Впрочем я не хочу сказать, что ООП ненужно. Напротив - нужно, только надо понимать, что с ООП начинающие программисты не справятся.
Вы малость искажаете функцию ооп. Да написал пользователь Rectangle(a,b). А автор обсуждаемой тут программы написал класс ХитрыйРасчетчик - который является оберткой над любым пользовательстим Rectangle(a,b), Triangle(a,b,c) и т.п. умеет поставлять им входные данные и принимать их от пользовательской функции. Этот ХитрыйРасчетчик входные данные берет из класса АбстрактныйДобытчикДанных. И в нужные моменты на место АбстрактныйДобытчикДанных подставляются его наследники - ДобытчикДанныхИзГУЯ или ДобытчикДанныхИзCSV. Както так - пользовательская функция и ХитрыйРасчетчик вообще не имеет представления что и откуда, просто считают, отдают результаты и принимают входные данные.

[Нитонисе]

Сообщение от zamtmn В идеале с чертежа. и отчет не чертеж.

"С чертежа на чертеж" - это весьма и и весьма узкая область применения. Я вот например не представляю для чего нужна система "с чертежа на чертеж" для расчета жб сечения на изгиб. Это же могу отнести к 95% других инженерных расчетов. Ну а те 5% которые остались - задачка не для средних умов. Это надо быть профессиональным программистом. Ну если конечно вести речь о чем-то серьезном.

[zamtmn]

Нитонисе
Идеалы у всех разные, поэтому и нужна отвазка от одного единственного источника данных в виде ГУЯ

[Brandashmыg]

Сообщение от Нитонисе Ну а те 5% которые остались - задачка не для средних умов. Это надо быть профессиональным программистом.

Не согласен. 5% - это все графоаналитические задачи. Тут и шпунт по Якоби, и Шахунянц, и круглоцилиндрические поверхности скольжения. В них таки очень удобно задавать данные прямо по чертежу.

[DEM]

Сообщение от nikе Что касается механизма UNDO - REDO, то есть действительно ++ в использовании OpenOffice, потому, что он там есть. Если хочется сделать свой механизм, можно поискать в сети. Изнутри он может работать следующим образом. Держать данные программы в объекте класса. При вызове любой функции редактирования менять части этого объекта и записывать его полностью в другой класс, который содержит в себе стеки прямого и обратного вызовов. Записывая изменяемый объект в стек в полном объеме мы с одной стороны упрощаем кодирование и уменьшаем количество ошибок, с другой стороны не экономим память...

А может проще поступить, опрашивать форму на предмет состояния инпутов, раз в 30 секунд, и сохранять эти значения....
И так сохранять предположим до 30 раз, а дальше память очищается от более ранних данных....

[zamtmn]

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

[Нитонисе]

Сообщение от Brandashmыg Не согласен. 5% - это все графоаналитические задачи. Тут и шпунт по Якоби, и Шахунянц, и круглоцилиндрические поверхности скольжения. В них таки очень удобно задавать данные прямо по чертежу.

Непонятно с чем вы не согласны. С тем, что задач, для которых исходными данными может быть чертеж и результатом расчета тоже чертеж - всего 5%? Ну так на самом деле я думаю что таких задач еще меньше. Лично мне за 7 лет работы конструктором ни разу не приходилось считать ничего из этого - "шпунт по Якоби, и Шахунянц, и круглоцилиндрические поверхности скольжения". Зато расчетов, для которых оконный интерфейс ввода данных является наиболее удобным - провел тьму.

[ETCartman]

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

На практике я много скачал например бесплатных программ с "оконным интерфейсом" но всегда оказывается проще написать простую функцию к электронным таблицам чем использовать эти программы (даже если я знаю что они протестированы и считают более менее верно). Дело в том что данные для расчета в большинстве случаев попадают к вам уже из какой то программы, где они уже введены (например вы строете модель в Wolsink Framework или scad-Lira) и вбивать их второй раз (то есть фактически вручную переносить усилия, сечения, длины) - это непроизводительно. К примеру у вас есть башня или какая то стальная конструкция. Вы построили модель, задали сечения и нагрузки, получили усилия. Там 100-200 минимум элементов которые нужно проверить. Если я использую программу с оконным интерфейсом - мне все надо забивать повторно вручную для проверки и переподбора этих элементов. Либо использовать модули самих расчетных программ (о которых мы говорим что они не всегда верно считают и не выдают нормальный подробный отчет). Я например делаю так - перегоняю нужные мне данные в электронные таблицы. Из текстового файла результатов или по другому. В электронных таблицах (в большинстве случаев я использую эффективные открытые программы - такие как LibreOffice) я произвожу расчет сразу всех 100 элементов. Функции мне выдают одно (коэффициент использования) или много (промежутачные выдачи) значений. Код у меня перед глазами - я могу закооментировать его и подшить к отчету (по американским правилам не важно в чем вы считали а важно что вы подробно описываете процесс, что откуда взялось). На написание функции я трачу грубо говоря от часа до дня. Как правило если уже есть кирпичики (например характеристики сечений, разные коэффициенты) то их надо просто пересобрать. Сам расчет всех 100 элементов занимает минут 10. С экспортом имортом- быстрой проверкой и собственно вычислительным процессом. Дополнительные вводимые данные тут минимальны (для стальных элементов - длина, усилия и сечения уже есть, задается только расчетное сопротивление стали и коэффициенты приведения длины которые как правило задаются по группам и просто). Самое главное - я вам скажу что в 100% случаев конструкция меняется в процессе работы по тем или иным причинам. И формально следует производить новый расчет. И производить его в электронных таблицах просто. А в оконном интерфейсе те дни и часы пока я вручную вытаскивал все данные из одной программы и вставлял в другую придется повторять. А работа эта скажем так очень неинтересная. Поэтому оконные интерфейсы при найденном мной способе мне не нужны просто даром. Хоть они золотом расписаны и хоть мне даже приплачивать за них будут. вот в кратце вам объяснение.

[Нитонисе]

Сообщение от ETCartman Дело в том что данные для расчета в большинстве случаев попадают к вам уже из какой то программы, где они уже введены

А если я проектирую кирпичный дом и мне надо выполнить расчет индивидуальной монолитной перемычки. В какой программе данные для расчета "уже введены", чтоб я мог их скормить функции ПосчитатьЖелезобетоннуюБалку()?

[DEM]

Нитонисе
В ту же электронную таблицу в которой рассчитаны 100 элементов....

[Нитонисе]

Сообщение от DEM В ту же электронную таблицу в которой рассчитаны 100 элементов....

То есть мне надо данные для этой балки забить в эксель? Это лучше чем в специализированном оконном интерфейсе?

[nikе]

DEM

А может проще поступить, опрашивать форму на предмет состояния инпутов, раз в 30 секунд, и сохранять эти значения.... И так сохранять предположим до 30 раз, а дальше память очищается от более ранних данных....

Проще всего реализовать UNDO - REDO полностью записывая в память состояние объекта. Можно конечно в памяти хранить последовательность отдельных команд редактирования, но в этом случае придется на каждую прямую команду писать антикоманду, что невсегда представляется возможным или тривиальным.
Количество состояний можно не ограничивать, его и так ограничит объем оперативки. Память можно очищать при нажатии на кнопку сохранить. Что касается 30 сек - программа пропустит промежуточные состояния, вдруг вы за это время успеете удалить с десяток таблиц или веток в дереве?

zamtmn

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

Имея объект, легко написать функции его представления в GUI, функции его архивирования (чтения записи в файл). Что касается запоминания состояния интерфейса - можно ли представить себе браузер без кнопки назад - вперед? Или частый выбор из очень большого и разветвленного дерева?

[DEM]

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

[nikе]

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

[DEM]

nikе
Так никто и не отказывается от таблиц...
Другое дело что не нужен такой сложный алгоритм для UNDO - REDO как это реализовано в автокаде или Ворде...

[ETCartman]

Сообщение от Нитонисе А если я проектирую кирпичный дом и мне надо выполнить расчет индивидуальной монолитной перемычки. В какой программе данные для расчета "уже введены", чтоб я мог их скормить функции ПосчитатьЖелезобетоннуюБалку()?

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

[Нитонисе]

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

Во-первых сразу вопрос - откуда берется ведомость перемычек? Вы о той, которую дают на чертежах? Ну так в этих ведомостях процентов 5 нужной информации для расчета каждой перемычки. Да и вообще, как вы собрались "скармливать" расчетным функциям ведомость перемычек из автокадовского чертежа? Ну а во-вторых, мне не надо всю ведомость считать. У меня 200 стандартных перемычек и 3 индивидуальные. Мне надо их запроектировать. Откуда ж взять данные для расчета, если ввод их куда либо не предусмотрен?