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

[JohnSUN]

kompilainenn, это не поможет... Там путаница в терминологии и вера в старый миф о всемогуществе баз данных.

Реально база в этой кухне не нужна (задачи, которые нужно решать, чисто организационные и расчетные) и даже вредна (возни много, а толку не будет).

...сейчас то что будет создано должно быть без ФИО и адреса, можно только город. Меня на производстве это устроит, для изготовления, а вот менеджеров... И на кой такой "архив"?
Поэтому "базой" назвал условно, по привычке. Возможно будет только программа для генерации строки параметров и печати договора.

И здесь bbv62 абсолютно прав (опыт не пропьёшь, знания накопленные годами не потеряешь).
Облегчить жизнь конторе могла бы связка нескольких шаблонов:
1. Шаблон Спецификации - заготовка Calc'овской книги-калькулятора. Один заказ = одна книга. Книга содержит сведения об одном объекте, одном клиенте - поэтому "базой данных" не является, вычищать персональные данные из неё не потребуется. (Нет, специалисты по наездам и здесь могут докопаться, но они и к бумажному архиву могут претензии изобрести). Задача этой книги:
а) собрать на листе ввода все информационные поля для печати текста Договора,
б) получать, обновлять, поддерживать в актуальном состоянии сведения о стоимости комплектующих и услуг (то ли с веб-сервиса запрашивать, то ли регулярно в центральном офисе обновляться, то ли ещё как - это, пожалуй, единственное место, где действительно нужна будет база данных.)
в) предоставить возможность удобного ввода разнообразных параметров объекта, которые служат основанием для расчетов
г) в приемлемое время (секунд 5-10, не больше) выполнять расчет всех вычисляемых параметров и стоимости материалов/работ
д) собирать в удобном месте (обычно на последнем листе) все данные, которые будут использоваться остальными шаблонами.
2. Шаблон Договора - заготовка Write'ровского документа с текстом типового договора, в котором помечены места вставки переменных значений (на форуме разбирались самые разные варианты заполнения таких полей - вариантов масса). Все данные, разумеется, должны браться из "калькулятора" - место ввода исходных данных одно!
Возможно, таким же образом организуется и печать Спецификации. Ну, если bbv62 сейчас скажет, что это в принципе не возможно, что для каждого объекта Спецификация уникальна, стандартизировать этот документ никаким образом нельзя - то и говорить дальше не о чем: нельзя, так нельзя.
3. Файл передачи данных - тот самый, о котором говорилось в топикстарте:

...И (!) - получения строки параметров в любом формате (txt, csv, xls xml и пр.), которая на производстве импортируется в базу PLM (порядка 70 параметров).

Всё? Вроде бы всё...
И куда здесь можно воткнуть с пользой для дела базу данных, заготовку которой мы видим в ТС?
Потому и "Комментариев нет"...

[bbv62]

Я, конечно, видел экстрасенсов по телевизору, на цыганок по-молодости нарывался с их "чтением по лицу" - в каком кармане деньги лежат и, даже, сколько их...
Компактно изложены все мои мучения за полтора года въезжания в тему. Сначала пытался всё это воплотить в Экселе. Многочисленные запросы в макросах и встроенных функциях, после определённого набранного уровня сложности, начинали жутко тормозить и зависать, запросы глючить, графика (вывод эскизов (картинок)) по запросу - отваливаться. Вспомнив насколько подобные задачи стабильней решались в Акцессе (в бытность работы на стройках Первопрестольной приходилось быстренько пересчитывать конструкции по фактическим замерам и материалам) начал было в ём. Остановила стоимость внедрения.
Перекинулся на ОПЕН. Не думаю, что Калк работает проворней Ёкселя, да и встроенных функций (прежде всего по отбору) - меньше. Всё-равно от писанных макросов не уйти. Поэтому решил, таки, сорганизоваться в Base. К тому ж есть надежда что проблему "Персональных данных" удасться решить (или обойти) организационно - а тут готовый аппарат для архива.
Вот, собственно, и вся логика. Хотя подход (и предыдущие разработки) абсолютно дилетантские и я готов поменять свои установки на более разумные. Цена вопроса?! Предыдущие платные изыскания профессиональных программистов оказались абсолютно непригодными. (Самих программеров даже не видел, хаять не буду. Может им задачу ставили некорректно)

[JohnSUN]

Сначала пытался всё это воплотить в Экселе.

Один из немногих фокусов, которые умеет Эксель и до сих пор, кажется, не умеет Calc - рисование картинки из списка выбора. Ставший уже классикой прикол Владимира Захарова "Светофор" - один из примеров как должно бы было быть...
Насколько я себе представляю внешний вид Спецификации, картинка - как минимум одна - там должна быть. Как безгеморройно реализовать в Calc'е выбор одной картинки из нескольких и последующее отображение только её одной - не знаю, тут крепко подумать надо... Возможно, эта тема опять будет реанимирована
Всё остальное - выбор данных из таблиц и использование их в формулах - Calc'у по силам.

[bbv62]

Всё остальное - выбор данных из таблиц и использование их в формулах - Calc'у по силам.

ЧЕМ CALC АКТУАЛЬНЕЙ?
Предполагается процесс как последовательное (может хаотичное) продвижение по изящным формам. Взяча вариантов выбора из "наружных" таблиц, редактируемых, при необходимости, из центрального офиса. Печать отчёта (договора со спецификацией) в Райтере. Временное (до исполнения договора - установки) подпольное хранение всех данных ...предполагается (на локальном компе конкретного офиса).
ПОЧЕМУ КАЛК ЛУЧШЕ?!

[JohnSUN]

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

Последний - а иногда и единственный - вопрос клиента: "Во что это выльется?.." Что во время замера, что при разговоре в офисе - он будет интересоваться окончательной суммой.
Поэтому замерщик или менеджер должны иметь возможность быстро эту самую сумму подсчитать и озвучить.
"Считать" - задача калькулятора. Задача базы - запомнить и сохранить.
Имеешь полное право заставить считать и Base. Даже Writer, если его стукнуть кнопкой F2, будет считать.

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

[bbv62]

быстро эту самую сумму подсчитать

можно лишь при условии Полного заполнения всего договора и учёта ВСЕХ действующих скидок и постоянных и персональных и акционных. И тот "ИТОГО", который "больше всех получает" получается лишь после нажатия последней кнопки.
Разницу в ценах того или иного варианта комплектации легко продемонстрировать в соответствующей выбору форме, а в Калке и Экселе придётся метаться по таблицам. ...Не?

[JohnSUN]

Ладно, отвлеклись...
С самого начала ты спрашивал про вот это:

Код Выделить Развернуть

REM По нажатию кнопки открыть форму, имя которой указано в "Дополнительной информации"
Sub openFormByTag(oEvent)
Dim cWhat As Long ' Что будем открывать - константа офиса "Форму"
Dim oModel As Variant ' Модель текущей формы, в которой кнопку жмём
Dim sName As String ' Имя формы которую нужно открыть
Dim oCtrl As Variant ' Контроллер - именно он займётся открыванием следующей формы
Dim newForm As Variant ' Следующая форма как объект
Dim record As Variant ' Данные новой формы
cWhat = com.sun.star.sdb.application.DatabaseObject.FORM
oModel = oEvent.Source.getModel()
sName = oModel.Tag
REM Карабкаемся к истокам:
REM         кнопка форма все_формы документ база
oCtrl = oModel.Parent.Parent.Parent.Parent.getCurrentController()
newForm = oCtrl.loadComponent(cWhat, sName, FALSE)
REM Если бы не необходимость привязывать каждую открывающуюся форму к коду заказа,
REM на этом можно было бы и остановиться.
REM У открывшейся формы наоборот - закапываемся вглубь:
REM          документ слой_с_формами все_формы первая_из_них
record = newForm.getDrawPage().getForms().getByIndex(0)
  record.Filter = """КодЗаказа""=" + oModel.Parent.getInt(0)
REM Фильтр сработает и что-то покажет, если это "что-то" есть
REM Поэтому при создании нового заказа, сразу после того как станет известен "КодЗаказа",
REM ты должен сразу же подополнять все нужные таблицы записью с этим кодом...
End Sub

[bbv62]

 

[JohnSUN]

Не плачь, не всё так плохо...
Просто соберись с мыслями, сформулируй  и ещё раз переспроси...

[bbv62]

На работе шибко грузанули, отвлёкся... на неделю.
Я ведь только «Кнопочку» просил! Никак не ожидал какие недра могут вскрыться.
Самый банальный вопрос — а где название открываемой формы вставить?
Понимаю — что надо присвоить имя переменной «sName» - но, где? Особенно смущает «sName = oModel.Tag». (один из переводов «Tag»=болтающийся конец). Так бы, ничтоже сумяшеся, воткнул «sName = «Замер»» аккурат в этом месте.
По лингвистике: 1. Что такое «cWhat» - нигде описания не нашёл.
2. was bedeutet "...константа офиса "Форму""
3. Больше всего напугала фраза «REM ты должен сразу же подополнять все нужные таблицы записью с этим кодом...». Таблицы данных (фактически разбитую «главную» таблицу) я предполагаю связывать этим кодом по мере заполнения этапов приёмки заказа.
По поводу кодов заказа. Действительно он должен присваиваться только при окончательном выборе варианта исполнения, а заполнение вести на стержне абстрактного ID-шника. Поиск же нужных записей (иногда и через полгода с соответствующим пересчётом стоимости) придётся вести по ФИО (нельзя хранить) или НИКу (погоняло), который заказчик может за это время и забыть. Хотя у него должны оставаться распечатки.
4. Почему record.Filter = """КодЗаказа""=" + oModel.Parent.getInt(0) так много кавычек?

PS. Старушка User
тычется в подушку Macroshку ,
и только слышно:
«Саша JohnSUN ! —
Душка!»

[bbv62]

Кстати, если выполняю « воткнул «sName = «Замер»» аккурат в этом месте» - соответствующая форма открывается, но не переходит к нужной записи и не создаёт новую с нужным кодом.
Без правки вообще встаёт.

[JohnSUN]

Я ведь только «Кнопочку» просил! Никак не ожидал какие недра могут вскрыться.

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

Самый банальный вопрос — а где название открываемой формы вставить?

"У-у-у, как всё запущено..." (с) М.Жванецкий. См. картинку - обойдёмся без лишних слов.

(один из переводов «Tag»=болтающийся конец). Так бы, ничтоже сумяшеся, воткнул «sName = «Замер»» аккурат в этом месте.

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

По лингвистике: 1. Что такое «cWhat» - нигде описания не нашёл.
2. was bedeutet "...константа офиса "Форму""

Читаем код и комментарии... натыкаемся на длинную фигню "com.sun.star.sdb.application.DatabaseObject.FORM"... Вбиваем эту штуку  строку поиска и получаем исчерпывающую информацию

3. Больше всего напугала фраза «REM ты должен сразу же подополнять все нужные таблицы записью с этим кодом...». Таблицы данных (фактически разбитую «главную» таблицу) я предполагаю связывать этим кодом по мере заполнения этапов приёмки заказа.
По поводу кодов заказа. Действительно он должен присваиваться только при окончательном выборе варианта исполнения, а заполнение вести на стержне абстрактного ID-шника. Поиск же нужных записей (иногда и через полгода с соответствующим пересчётом стоимости) придётся вести по ФИО (нельзя хранить) или НИКу (погоняло), который заказчик может за это время и забыть. Хотя у него должны оставаться распечатки.

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

Код Выделить Развернуть

INSERT INTO "Замер" ("КодЗаказа") VALUES (<Код Нового Заказа>)
Это не сложно: пишешь один раз - выполняется всегда

4. Почему record.Filter = """КодЗаказа""=" + oModel.Parent.getInt(0) так много кавычек?

Ну, это общепринятый синтаксис для строк - чтобы Бэйсик не подумал, что строка уже закончилась, когда он нарвется на следующую кавычку, кавычки внутри закавыченной строки удваивают. А то что сам КодЗаказа нужно брать в кавычки - это требование Base... Если бы ты все таблицы и поля обзывал заглавными латинскими буквами, то кавычки и не понадобились бы... но тогда кроме тебя в этой базе уже никто бы не разобрался..


PS. За стих - глубокое мерси... "Ржу-нимагу, пешиисчо..."

[bbv62]

"У-у-у, как всё запущено..."

- это когда было, и сгнило. Органики в моёй куче никогда не было, поэтому запУститься не может. Просмотрел ключевое слово "кнопки".
Решение для меня радикальное!
"исчерпывающую информацию" - там тоже этого ругательства нет (побуквенно, во-всяком случае). И с моим "Hande hoch!" сорокалетней давности такая исчерпывающая превращается в избыточную информацию.
Насчёт "широкой" таблицы - был это у меня первый позыв. НО ОНА ТАКАЯ НЕУДОБНАЯ! Хотя пользователю то с ней как раз дела иметь не придётся. Зато в разбитых таблицах наглядно группы данных просматриваются. Похоже - это единственный плюс.
Но и описанный минус тоже вроде 1. Дополнительно для просмотра запросы городить - смысла не вижу. Короче - ещё подумаю.
Самое главное - макрос то работает. Но ограничивается открытием нужной формы.
А вот открытия нужной строки, или созданием новой с интересующим ID - нет! Или я опять что-то не вижу.
PS. Стих не мой - любимый ВВ. Аккурат 100 лет назад написал.

[JohnSUN]

"исчерпывающую информацию" - там тоже этого ругательства нет (побуквенно, во-всяком случае). И с моим "Hande hoch!" сорокалетней давности такая исчерпывающая превращается в избыточную информацию.

Ну как же нет! Вот же она - ненашим по белому написано const long FORM = 2;
Когда мы контроллеру говорим "Быстро открой нам штуку с именем sName!.." мы должны ему еще и разжевать, в каком разделе базы этот самый sName искать. Для этого используется первый параметр в loadComponent. Можно было бы просто написать двоечку, но это не правильно... Вдруг в следующем выпуске офиса они изменят политику и в качестве этого параметра нужно будет указывать, например, слово "foms"... А так мы указываем имя константы (вся эта длинная беда - com.sun.star.sdb.application.DatabaseObject.FORM - это константа, которую офис знает всегда). И что бы там в политиках не менялось - макрос будет работать.

Насчёт "широкой" таблицы - был это у меня первый позыв. НО ОНА ТАКАЯ НЕУДОБНАЯ! Хотя пользователю то с ней как раз дела иметь не придётся. Зато в разбитых таблицах наглядно группы данных просматриваются. Похоже - это единственный плюс.

О! А теперь - сюрприиииииз!.. Кроме как с таблицами Base умеет работать еще и с такой хитрой штукой, как "запрос". Ты создаёшь неудобную широкую таблицу... По этой таблице делаешь пачку запросов. Каждый запрос содержит КодЗаказа и какие-то поля из широкой таблицы... Ну, например, те, которые будут использоваться в форме Замер. И теперь создаешь формы на основании этих запросов. Будешь смеяться - всё то же самое, но в глазах не рябит от обилия столбцов... А об основном хранилище данных - большой широкой неудобной таблице - можешь забыть. Она будет выполнять свою задачу - хранить данные - и всё.

Дополнительно для просмотра запросы городить - смысла не вижу.

Послушайся совета - присмотрись внимательнее... "Ты его не видишь, а он там есть" (с) Ян Арлозоров

А вот открытия нужной строки,

Это потому что строки такой нет...

или созданием новой с интересующим ID - нет!

А эту задачу никто и не ставил - это не задача для "кнопки открытия формы с продолжением" (с) bbv62

[bbv62]

1.  Сохранение записи.
2. «запоминание» значения поля «КодЗаказа»
3. Открытие соответствующей кнопке формы
4. Открытие (создание) в этой форме записи с этим кодом.
Вообще создалось впечатление что я изобретаю велосипед

Как же нет!? первый пост (не великий).
По поводу грамматики (лингвистики, тазерауса или чего-то такого) - не верю что можно запомнить столько "устойчивых выражений" на нептичьем языке. Догадываюсь, что там расписано 75% моих потребностей (может и 100%). А вот как ими пользоваться - не приложусь. Начиная с англицкой мовы, на которой всё расписано. Help, Питоньяк, и прочие не помогли в определении поиска нужного. Даже правильно построить поиск запроса ни разу не удалось. (За прошедшие 2 недели всосал около 600 страниц непонятного текста - всё всуе). Похоже всё решает непрерывная долголетняя практика.
ПОЭТОМУ ПЫТАЮСЬ ПОСТРОИТЬ СВОЙ ПРОЕКТ НА ОЧЕВИДНЫХ (ШКОЛЬНЫХ) ПРИЁМЧИКАХ С МИНИМАЛЬНЫМ ВКРАПЛЕНИЕМ ГЛУБОКИХ РЕШЕНИЙ.