Думаю что многое если не всё зависит от самих данных и от того, что с ними следует делать.Хорошо, тогда я конкретизирую задачу.
При закрытии транзакции все открытые, а так же созданные и добавленные в базу объекты базы (наследники DBObject, т.е в том числе и Table) становятся недействительными. Т.е. твой table1out действителен только внутри транзакции.Извиняюсь. Просто однажды словил ошибку и, как уже сейчас понял, неправильно ее интерпретировал.
Ну ты даёшь. Это совсем не имеет отношения к данной теме.Александр Наумович, Ну как это не имеет?? Я вижу самую прямую связь!!
Упрощенная концепция кода выглядит примерно так:У меня не выходило, я подумал, что неправильно передаю таблицу между методами!
Поэтому для того, для чего ты хочешь её использовать, следует хранить не саму таблицу (Table), а её ObjectId, и при необходимости его открывать.У меня, кстати, получилось сохранить саму таблицу.
У меня, кстати, получилось сохранить саму таблицу.Еще раз. После завершения транзакции объект участвующий в транзакции недействителен. Вплоть до Fatal Error при обращении к нему. Тебе просто крупно повезло. В других условиях или на другой версии AutoCAD/другом PC и т.д. не повезет. Крайне не рекомендую так делать.
Разве это не схожие вещи?То что разрешено для string не разрешено для Table. Поэтому я был совершенно прав, говоря что многое зависит от самих данных.
Еще раз. После завершения транзакции объект участвующий в транзакции недействителен. Вплоть до Fatal Error при обращении к нему. Тебе просто крупно повезло. В других условиях или на другой версии AutoCAD/другом PC и т.д. не повезет. Крайне не рекомендую так делать.Крайне прислушиваюсь к Вашему совету.
То что разрешено для string не разрешено для Table. Поэтому я был совершенно прав, говоря что многое зависит от самих данных.Все как обычно. Всегда Ваш первый ответ, даже если сразу не кажется решением темы, то спустя "подумал" уже кажется.
Раньше я писал свой программный код в один метод и бед не знал.Ну если Вы решили навести порядок - то я бы Вам рекомендовал по возможности избавится от методов которые используют внешние переменные - есть аргументы - есть возвращаемое значение - ими и оперируйте.
Но, когда кода становится слишком много, править/дописывать что-то в данный метод становится настолько сложно, что я решил навести порядки во всем, что написано, пока не стало поздно.
Так вот, вопрос по поводу обмена переменными между методами, суть:
Иногда, когда несколько методов используют одни и те же переменные, я делаю так (объявляю их в классе):
Ну если Вы решили навести порядок - то я бы Вам рекомендовал по возможности избавится от методов которые используют внешние переменные - есть аргументы - есть возвращаемое значение - ими и оперируйте.Тем более, что в данном случае это всего лишь ObjectId таблицы.
Раньше я писал свой программный код в один метод и бед не знал. ;)Изобретение велосипедов дело интересное но малоэффективное.
Но, когда кода становится слишком много, править/дописывать что-то в данный метод становится настолько сложно, что я решил навести порядки во всем, что написано, пока не стало поздно.
Ну если Вы решили навести порядок - то я бы Вам рекомендовал по возможности избавится от методов которые используют внешние переменные - есть аргументы - есть возвращаемое значение - ими и оперируйте.Я так и сделал уже. С таблицами иначе и не выходит. А вот работать со списками и декларировать их в классе крайне неудобно. Спасибо за совет, который укрепил веру в правильный выбор. Очень ценю.
Тем более, что в данном случае это всего лишь ObjectId таблицы.И еще в шапке темы вопрос касался списков, точнее пример был со списками.
Изобретение велосипедов дело интересное но малоэффективное.Спасибо. Обязательно просмотрю. Просто, как правило, форум эффективней с позиции трудозатрат. Здесь получаешь конкретные ответы от опытных товарищей, делаешь выбор и дальше с этим работаешь.
Эти вопросы возникают у каждого программиста, и они уже были систематизированы, обдуманы, выработаны методы решения.
Решение твоих проблем в книгах "Чистый код" или "Совершенный код".
1. CreateTable1(pr.Value);Забавно, но у меня в коде так и сделано. :)
CreateTable2(pr.Value);
быстро просматривая твой код, возможно стоит избежать дублирования и вынести один единственный метод CreateTable,
который всегда принимает Point3d и доп параметры, тут стоит определиться что он будет принимать.
Например CreateTable(Point3d insertPoint, string str1, string str2),
Возможно CreateTable(Point3d insertPoint, string[] str),
Или так CreateTable(Point3d insertPoint, ObjectId tableId),
2. Перепиши InsertTables к примеру так:Идею понял! Забавно! Обязательно поэкспериментирую!
var insertPoint = GetPoint();
if (insertPoint!=null)
{
ObjectId tableId = CreateTable(insertPoint, ObjectId.Null);
CreateTable(insertPoint, tableId );
}
Т.е. запрос точки вынеси в отдельный метод GetPoint() так удобнее читать сам метод InsertTables.
проверка точки так не выйдет, это всего лишь схема изменения, додумай сам до конца.
3. InsertTables вынеси первым методом в классе,Понял. А реально, ведь удобней! Спасибо! Очевидные вещи, конечно. Но, пока сам дойдешь.. Спасибо за ценные советы!
потом GetPoint(), затем CreateTable().
т.е. стартовую функцию класса ставь вначале, затем расположи в порядке обращения к методам чисто читать удобнее.
Если переменные хранятся в одном месте и тебе заранее неизвестны, например параметры таблицы, например ты не знаешь будет ли цвет когда либо или нет.Как же все вариативно и интересно!! Здорово.
то можешь создать класс TablePropertyes туда сразу добавить точку вставки и передавать его в метод построения CreateTable(TablePropertyes) так ты получишь параметры, которые сможешь дополнять независимо от основной логики программы, и дополнять CreateTable в зависимости от доступных параметров.
Конкретно, в коде, что я пишу, есть метод который считывает инфу с блоков, он создает около 10 списков, затем я их использую в методе создание спецификации, а потом с самой спецификацией и списками с метода, который считывает инфу с блоков, работаю в методе создание ведомости расхода стали. В общем, много возвращаемых значений), но, в принципе, ничего страшного, пережить это можно.Мне хорошо знакомо о том что Вы пишете. У меня еще помимо ведомостей, и оптимизация раскроя и чертежи КМД, и задание на ЧПУ распиловки и фрезеровки, и учет и обработка полезных остатков и пр. Мой Вам совет - ни в коем случае не привязывайте Ваши ведомости к блокам (имеется в виду на логическом уровне). Что там за инфа с блоков на 10 списков? У меня, например, всей инфы - имя блока и далее список параметр(или атрибут) - значение. Создайте структуры (классы - что Вам ближе) которые всесторонне будут описывать ваш конечный продукт, а как и из чего получать результат это вопрос второй. Вполне возможно, вскоре это будут не только блоки из автокада, а например еще и проводки из 1С, и формат выходных таблиц будет совсем другим и не только для "человеческого" прочтения. И если вернуться к заголовку темы - общих переменных в коде при всем этом у меня нет ни одной, не для того чтоб Вас в чем-то убедить - просто вот не понадобились.
Мой Вам совет - ни в коем случае не привязывайте Ваши ведомости к блокам (имеется в виду на логическом уровне). Что там за инфа с блоков на 10 списков? У меня, например, всей инфы - имя блока и далее список параметр(или атрибут) - значение. Создайте структуры (классы - что Вам ближе) которые всесторонне будут описывать ваш конечный продукт, а как и из чего получать результат это вопрос второй.ИМХО, очень правильный совет! Гуглить MVC (https://ru.wikipedia.org/wiki/Model-View-Controller)
Мой Вам совет - ни в коем случае не привязывайте Ваши ведомости к блокам (имеется в виду на логическом уровне).Так, я совсем не понял, что значит не привязываться на логическом уровне?
Что там за инфа с блоков на 10 списков?Это списки типа диаметр, класс арматуры, длина и прочее
Создайте структуры (классы - что Вам ближе) которые всесторонне будут описывать ваш конечный продуктДа, но для этого мне нужна входная информация в виде списков, иначе конечный продукт будет пустым. Или я что-то не так понимаю?
И если вернуться к заголовку темы - общих переменных в коде при всем этом у меня нет ни одной, не для того чтоб Вас в чем-то убедить - просто вот не понадобились.Я прекрасно понимаю, что такое "еще помимо ведомостей, и оптимизация раскроя и чертежи КМД, и задание на ЧПУ распиловки и фрезеровки, и учет и обработка полезных остатков и пр." и не понимаю, как тогда это реализовано? Откуда берется инфа о металле? Где все это хранится? Как пользователь изменяет что-то?
Так, я совсем не понял, что значит не привязываться на логическом уровне?Не правильно делать связку блок - выходная таблица. Должна быть некая модель выходных данных никак не завязанная на блоки, а описывающая конечные сущности, а все ведомости, сводные таблицы и пр. должны получаться из нее. Так-же модель должна и заполняться данными.
Откуда берется инфа о металле? Где все это хранится? Как пользователь изменяет что-то?Тут есть варианты, лично у меня все данные (включая те самые блоки) хранятся в СУБД (если конкретно то MSSQL). Вся инфа заносится (редактируется) через соотв. GUI + естественным образом получается автоматически - те-же полезные остатки, после "утверждения" складом автоматом используются в последующих раскроях при выполнении всех условий "подходимости" + этикети + документы на списание и пр. - все автоматом вытекает из "предыдущих" фаз. по мере прохождения технологического. процесса - в теории можно сразу расписать все от и до, но в реальности это возможно далеко не ко всем данным - так как есть брак материала, брак при производстве, человеческий фактор и пр. Естественно необходимо учесть в модели (а затем и реализовать в GUI) "ручную" правку и учет этих данных.
Должна быть некая модель выходных данных никак не завязанная на блоки, а описывающая конечные сущности, а все ведомости, сводные таблицы и пр. должны получаться из нее. Так-же модель должна и заполняться данными.Кажется, я понимаю, о чем идет речь.
Тут есть варианты, лично у меня все данные (включая те самые блоки) хранятся в СУБД (если конкретно то MSSQL). Вся инфа заносится (редактируется) через соотв. GUI + естественным образом получается автоматически - те-же полезные остатки, после "утверждения" складом автоматом используются в последующих раскроях при выполнении всех условий "подходимости" + этикети + документы на списание и пр. - все автоматом вытекает из "предыдущих" фаз. по мере прохождения технологического. процесса - в теории можно сразу расписать все от и до, но в реальности это возможно далеко не ко всем данным - так как есть брак материала, брак при производстве, человеческий фактор и пр. Естественно необходимо учесть в модели (а затем и реализовать в GUI) "ручную" правку и учет этих данных.Думаю, для меня это будет следующим уровнем. Пока очень много непонятного.
Его довольно просто доработать, для взаимодействя с внешней БД.хотя формально xml это тоже внешняя БД - но я думаю что автор имел в виду именно реляционную.