Ответы:- По поводу Дельфи - это единственный язык высокого уровня, который я знаю. Поэтому в своих долгосрочных планах я буду ориентироваться именно на него. Скажу сразу, что в планы входит изучение Си и использование специфической библиотеки классов ObjectARX (Это чисто для создания приложений под АвтоКАД).
- Все нижесказанное ограничивается моим опытом и 5-летней работой с AutoLISP.
- Я могу повторяться, это ввиду того, что я не имею опыта подобных изложений.
Просьба не обращать на это внимания и отнестись с пониманием
) Если это вам нужно!!
Недостатки, продолжение:3. Собственно ТехМаршрут задуман был именно как "редактор файла БД Access". Свою задачу он выполнил, хотя и на начальном программистском уровне. Однако дальнейшее развитие системы, что будет описано ниже в него уже не вписывается.
4. Работа вся идет через 1. Оно конечно правильно, только работает он не с БД, а с файлами. С текущими - на машине пользователя, с архивными - копирует из сетевой папки с сервера. В принципе доступ к этой папке есть у всех пользователей сети, иначе программа не смогла-бы ложить туда файлы! И это не есть ГУТ!!
Мои мысли по поводу реализации! (если в моих мыслях есть смешные или некорректные описания , то смотрите выше, я там уже признался в своем незнании терминологии, и приблизительном ориентировании.)Мысль 1: Единая БД предприятия пока на эту задачу. И организация системы клиент-сервер. Эта мысль ГЛОБАЛЬНАЯ, в смысле все должно реализовываться не вручную с файлами, а через сервер. Тут много ньюансов. Сервер БД и организация клиент-сервер для меня пока темный лес, но внутри зреет чувство, что это есть правильное решение!
Мысль 2:
Родная, вынашивалась уже 1.5-2 года, но в связи с тем что рук-ву нужны конкретные рез-ты и в сжатые сроки реализации не получили. Но параллельно мы искали информацию. Отойти от раздельной работы приложений по формированию ТП.
----- Напомню:
Раздельное формирование было на этапе 2-3. Сначала создавался файл БД ТП (tpp). Один tpp на один ТП. Затем он, посредством текстового файла - совершенно дикой структуры - передавался в 3 (АвтоКАД). Там запускалась ЛИСП программа, которая читала этот файл и преобразовывала во внутреннюю структуру. В дальнейшем по этим данным и запросам пользователей создавался "ОКОНЧАТЕЛЬНЫЙ" документ ТП(dwg). Т.е. такой, который можно печатать и нести на подпись. Таким образом работа с ТП была линейная. Забыл что-то внести в tpp, либо исправляй в dwg, либо выходи из АвтоКАД-а и исправляй в tpp, с последующим запуском АвтоКАД-а, созданием передаточного файла, чтением его и пересозданием того листа - что некорректен. Гимморр! И в результате для ТП нужны 2 файла tpp и dwg.
-----
Т.е. формируется ТП в одной среде. Сколько будет файлов неважно, основная цель целостность данных, а не разбиение ее по частям. Средой был выбран АвтоКАД. Под него можно сделать программы на ЛИСП(хотя полноценную работу, типа с БД, тут не сделаешь), можно подключить программы ARX - специальный DLL файл, создавать который можно с использованием ObjectARX. Правда для версии АвтоКАД-а 14 можно было на Дельфи сделать. А теперь покупать надо у одного разработчика, потому что в новой версии изменили содержание основных экспортируекых функции этой DLL-ки. А можно сделать внешнее приложение (COM-сервер), к которому я буду обращаться из VisualLISP.
Собственно это уже идея де-факто. Создавать мы будем именно СОМ-приложение для работы с БД. А вот как использовать - есть 2 варианта:
1. Вызывать из VisuslLisp.
2. Создать модуль ARX, который будет использовать уже готовый СОМ-объект и экспортировать для работы в АвтоКАДе. Т.е. прослойка между СОМ и АвтоКАД. Вполне возможно, что начальных сведений об Си хватит, чтобы написать ARX приложение для связи с СОМ.
Реализацию создания СОМ возложить на Дельфу.Мысль 3: ТехАрхив(1) должон работать не с файлами а с серверной БД. И еще создаваться будут не документы, а нечто вроде ярлыка, в котором будет прописано, что за объект, какие данные ему принадлежат, какие файлы содержать будет(если файловое расположение), какие права кто имеет на этот документ.
Авторизация должна быть привязана к сетевому имени пользователя. Используется Novell, вот новелловские имена и должны быть отправной точкой. Запуск приложения для редактирования/просмотра "документа" заключаться должен в
следующем: ТехАрхив просто передает ID-документа программе редактору/просмотровщику с текущим именем пользователя. Сама программа за необходимыми данными обращается к серверу БД. Т.е. ТехАрхив играет роль координирующей программы или рабочего стола пользователя.
Мысль 4: Все-таки желательно перенести один ТП в один файл. Если реализация будет файловая. Т.е. не будет единого файла dwg с окончательным документом и данных ТП ввиде tpp-файла. Варианты организации:
-Первый. Одним из полей документа ТП будет форма. В процессе создания документа, можно нажать кнопку «Оформить документ». Создается документ во временном каталоге под именем – индекса документа (для примера – номер документа). Затем он сохраняется в поле БД.
-Второй. В документе будет хранится эскиз и расположение текстовых записей на листах оформления.
-Третий. DWG-файл один, он хранится в поле шапки ТП, а не как предыдущие варианты в поле операции. Вызывается в процессе запуска. Это тоже минус. Поскольку файл может быть нехилый под несколько Мб.
-Четвертый. это не слияние, а отдельные файлы именно эскизов на операцию.
Первые 3, будут реализованы ввиде объекта ОЛЕ или поля с данными(не помню, вроде BLOB-поля) этой таблицы. Но однозначно, что dwg-чертеж должен быть. А в каком виде и где лежит - другой вопрос.
Мысль 5: Организация работы ТехМаршрута. Отойти от операций. Пусть будут ДОКУМЕНТЫ, у которых будут соответствующие свойства. Из документов и будет состоять ТП.
----- Подробности
Под документами я подразумеваю объекты со своими методами и свойствами и своей иерархией. Визуальной составляющей, событиями и связью с БД. Это относится к аспекту программировани и организации работы приложения. Например объект - документ "операция 100". Могут быть состояния: (нормирована, подписана, в разработке и пр..) Родительский объект ТП. и пр... тут нужно составлять список свойств и методов, событий и состояний для каждого объекта.
Вот чего не знаю, можно-ли сделать визуализацию объекта. Т.е. при обращении с целью редактирования текущего объекта, чтобы отразилась форма соответствующая данному классу. Для чего это нужно? - Красиво, много видов документов, которые нельзя привести к единому виду.
Тут вопрос, как определять, какие данные БД соответствуют объекту? Как их считыват? На второй есть нечто вроде ответа. Должен быть визуальный компонент - объект, который отражает связь с БД и в который встраиваются собственно ДОКУМЕНТЫ, запросы которых и будут обращены к нему.
Структура вроде дерева: Шапка ТП(связь с БД, Данные, связь с документами)
|-Документ1(маршрутная карта)
|-Документ2(операция 10)
...
Структура иерархии объектов: Объект документ
|-Документ общий на ТП
| |-Документ маршрутная карта
| |-Документ ведомость оснастки
| |...
|-Документ операция
| |-Документ операция токарная
| |-Документ операция с ЧПУ
| |-Документ текст в маршруте
| |...
|-Документ прочие
-----
Уфф, снова выдохся... Теперь про эксперименты:
Эксперимент 1: работа с объектами начало
Цель: Определить направление работы с объектами и методику создания управляющих элементов. Связь объектов с управляющими элементами и работа с событиями
- Создать 2-3 объекта с определенными состояниями.
- Сделать форму с управляющим элементом, в котором и будут содержаться объекты. В зависимости от действий над ними должны сами изменять свое состояние.
З.Ы. Не знаю, стоит писать про результаты и исходники эксперимента?
