Lookup посредством drop[combo] (11.07.04)

Clarion, Clarion 7

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Ответить
Гость

Сообщение Гость »

Приветствую Всex!

Hа новой работе долго не приходилось ничего писать, и тут подкинули
халтурку. С ужасом понял, что не могу сделать простейшего.

5508, clarion, шаблоны частично русифицировал под себя

Задача стандартная: список персонала и несколько вспомогательных
справочников с параметрами - звания, должности, выполняемые работы и
т.п. В основной базе хранятся коды параметров, в справочниках - коды и
названия. Все справочники связаны с базой по 1:many.

В форме для add/update/delete нужно сделать выбор параметров из списков
с возможностью дополнения. Пока сделал lookup trigger button, которая
вызывает соответствующую BrowseСправочник или SelectСправочник, но это
некрасиво.
Пытаюсь вставить file-loaded dropbox, он вставляется и даже позволяет
выбирать значения, значения нормально пишутся в базу, но при вызове
записи из базы для изменения, в дропбоксе - пустая строка.

Как установить дропбокс на нужное значение? А без embed-ов можно?

Для более предметного разговора:

База
Staff file,pre(STF)
Names string
Seat byte !должность
...

Справочник
Seats file,pre(SEATS)
SeatName string
SeatCode byte

Для базы и для справочника есть ключи по stf:code и seats:seatcode, по
которым и строится relation.

Успехов и здоровья.
--
C.A.
Написал: ClaList(2)
Гость

Сообщение Гость »

В форме в списке файлов указаны связи (есть ли открытие связанных с базой справочников)?

--
Best regards,
Чаплыгин mailto:chapligin@fromru.com
Написал: ClaList(2)
Гость

Сообщение Гость »

Есть.
В аттаче - образец ситуации. Пока не вписал в UpdateStaff embed, взятый
из рутины FLD5:FillList, который ищет совпадение в очереди для
дропбокса, и принудительно ставит prop:selected, так и не удалось
показать нужное значение в дропбоксе.
Может я что-то неправильно делаю?

Sergei Agarkoff grayman2000@mail.ru
Написал: ClaList(2)
Гость

Сообщение Гость »

Привет !

Добавь в секцию данных переменную, например Loc:ID String 20.
Подставть имя этой переменной в поле "USE" dropbox (самое первое).
Все.

Удачи !
ТАТА
Гость

Сообщение Гость »

Во-первых я использую DROP DOWN COMBO BOX. В качестве переменной ввода STA:RankID, наполнение из RAN:RankID. Под DROP DOWN COMBO BOX вывод звания из справочника. Закладка Action, кнопка Embeds в обработка событий в поле после сгененрированного кода вставляю
ForceRefresh = True
DO RefreshWindow
и все!
Пример АПП в аттаче. По - моему нормально работает. Мало того, при массовом вводе оператор может запомнить коды званий и вводить цифрами!
(Запомнить от практики, а не заучивать!)
Такие списки просто вставлять, из ручных вставок только обновление экрана! Использую для маленьких и простых списков. Если выбор чего-то сложного - только BrowseСправочник или SelectСправочник. Например настройка набора услуг на лицевой счет для квартплаты. Надо для выбора показать услугу, соц.норму по услуге и по какому тарифу эта соц.норма, указать и цыфровые значения и краткие названия!
Информации как раз на строку по ширине экрана! Выборка в строку из трех справочников!
Или выбор услуг для какой - то обработки (10 из 20 возможных) - это 10 вызовов одного BrowseСправочник или SelectСправочник.

--
Best regards,
Чаплыгин

(Добавление)
Во-первых я использую DROP DOWN COMBO BOX.
Речь шла не об этом изрващенном контрол-шаблоне (в виде, предложенном велосипидистами он просто не подлежит использованию - ИМХО), а об FileDrop-шаблоне.
В качестве переменной ввода STA:RankID, наполнение из RAN:RankID.
В цивилизованном мире в 99% случаев делается следующее:
1. Показывается "Наименование", содержащееся в справочнике.
Причем показывается в этом же поле, а не в каком-то дополнительном!
2. Сохраняется в базе "Код", содержащийся в справочнике.

Т.е. нужно показывать в списке RAN:RankName, а сохранять (а следовательно выполнять позиционирование и прочие настроки на старте процедуры) RAN:RankID.
Пример АПП в аттаче. По - моему нормально работает.
А по моему ненормально.
Мало того, при массовом вводе оператор может запомнить коды званий и вводить цифрами!
(Запомнить от практики, а не заучивать!)
Точно! нефиг расслабляться ему! пусть учит коды!
Такие списки просто вставлять, из ручных вставок только обновление экрана!
Просто - потому что неправильно. По своей практике обратил внимание,
что зачастую простые решения очень часто неправильные ;-)

--
Best regards,
Vadym mailto:vadim@softcreator.com
ICQ: 82308757
Речь шла не об этом изрващенном контрол-шаблоне (в виде, предложенном велосипидистами он просто не подлежит использованию - ИМХО), а об FileDrop-шаблоне.
Именно так. Combo подразумевает автоматическое дополнение справочника,
что мне совсем ни к чему.
Т.е. нужно показывать в списке RAN:RankName, а сохранять (а следовательно выполнять позиционирование и прочие настроки на старте процедуры) RAN:RankID.
Мой вопрос сформулирован лучше, чем у меня самого :)
Это реально сделать средствами стандартных шаблонов?

--
С.А.


(Добавление)
Пример АПП в аттаче. По - моему нормально работает.
Посмотрел, спасибо.
Работает, увы, совсем не так, как мне нужно.
Оператор не должен знать про какие-то коды, и уж тем более вводить их
вручную.
Подобную функциональность у меня сейчас обеспечивает string + trigger
lookup button, а хочется чтобы было красиво - выппадающий список и
ничего лишнего.
Вообще, вся эта возня затеяна с одной целью: понять, можно ли это
сделать стандартными шаблонами и с минимумом (а лучше - вообще без)
ембедов. Либо я что-то делаю неправильно, либо это невозможно. С
ембедами делается довольно просто, но не хочется жестко привязываться,
потому как кроме званий из справочников должно выбираться еще несколько
параметров и в разных формах. Писать для каждой ембеды - это можно сразу
удавиться.
Судя по дискуссии, стандартные clarion не позволяют такого. Жаль. :(

--
С.А.

То, что я пробовал делать с выпадающими списками в стандартных шаблонах, мне очень не нравилось. Но это было очень давно и последние версии от SV я не смотрел.

С уважением,
Владимир Смелик vovs@bigfoot.com

(Добавление)

Я делал для DropList из ШВС след. образом:

1) заводил лок. переменную, соотв. Locate полю в DropList'e, делал ее
в качестве Use-переменной для DropList.
2) в EMBED для NewSelection после GET...
вставлял строку принуждительноо присвоения значения Locate поля USE
переменной.
3) Значения ключевого поля записывемого из справочника, задаем в
закладке Action. Соотвественно заполяемое поле и поле справочника.

Например: в дроп листе выводится поле ENT:Title
заводим Title - лок. переменная, делаем ее USE.
в EMBED: Title=FLD5::ENT:Title

может можно как-то и подругому - но так точно работает

--
Mfg,
Anton mailto:ustim@web.de

Я всегда делал переменную из базы (редактируемая запись базы) в качестве Use-переменной для DropList! Тогда всегда на корректировке автоматом связанные справочники готовы! Только делал дополнительное отображение рядом с полем DropList символьных наименований выбранных значений!

--
Best regards,
Чаплыгин

Что-то я не понял, как это - "рядом символьное отображение"?
Дублирование информации из дропбокса или как? Можно пример такого app/dct ?

--
С.А.

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

--
Best regards,
Чаплыгин

(Добавление)
Например: в дроп листе выводится поле ENT:Title
заводим Title - лок. переменная, делаем ее USE.
в EMBED: Title=FLD5::ENT:Title
AU> может можно как-то и подругому - но так точно работает
По другому можно сделать проще ;)
создавать локальную переменную, совпадающую в типом целевой переменной и на входе процедуры иметь эту переменую пустой (так будет в случае не-AUTO переменной). Никаких дополнительных вставок кода не нужно.
В стандартных шаблонах нужно изголяться с присвоениями - как, пардон уже не помню (ибо задача решена один раз и давно).

Уточнение - естественно это переменная должна использоваться как USE-переменная
;)

--
Best regards,
Vadym

То ли я тупой, то ли как, но каким образом в эту пустую переменную
попадет значение из базы? Или для присваивания нужен отдельный embed?

--
С.А.

А смотри ШВС. Там есть "Чем заполнять" и "Что заполнять".
Т.е. сам в шаблоне указываешь связываемые поля.
Что-то я не понял, как это - "рядом символьное отображение"?
Дублирование информации из дропбокса или как? Можно пример такого app/dct
?
Смею предположить, что в ДропЛисте лежит список кодов, а рядом показывается расшифровка. На всякий случай рядом с компом оператора на стене наклеены простыни с кодами справочников.

С уважением,
Владимир Смелик
Т.е. сам в шаблоне указываешь связываемые поля.
Ну так это же есть и в стандартных шаблонах в actions для file-loaded
droplist? Или нет?

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

--
С.А.

(Добавление)

А чем не нравится когда в ДропЛисте лежит список кодов, а рядом показывается расшифровка? Если в ДропЛисте только расшифровка по - вашему лучше? Или пользователь будет меньше листать ДропЛист?

--
Best regards,
Чаплыгин

Оператору не нужны коды! Они создаются по autoincrement при формировании
справочника. Список воинских званий сравнительно невелик, да и оператор, как бы это сказать...

--
С.А.

Ну почему сразу не нравится? Просто другой подход к инетрфейсу. Как логическое развитие данного подхода могу предложить еще более простой в реализации вариант - избавить пользователя от какого-то невнятного поля наименования, а предложить ему просто вводить код в entry-поле.
И ему по-кайфу м программер не напрягается.

--
Best regards,
Vadym

Да и вообще... Должно быть четкое разделение ролей:
Поставщик данных - тот, кто порождает данные.
Кодировщик данных - тот, кто работает со всякими рубрикаторами и кодификаторами, выполняет некоторую входную проверку данных.
Оператор - тот, кто вводит уже закодированные данные.

При такой схеме оператору вообще не нужны все эти мнемонические справочники. Он набивает только цифры.

Впрочем, такая схема применялась во времена, когда были Постановщики задачи, Алгоритмисты, Программисты и
Операторы.

С уважением,
Владимир Смелик

(Добавление)

Пример из моей практики: НЕ моя программа по материалам, один из пользователей влепил болты под другим кодом с тем же названием.
Другой пользователь сделал операцию с болтами, и обратился ко мне за помощью - не сходится отчет! В программе высвечивались коды материала и я нашел причину!
Если следовать рекомендациям "НЕ показывать коды!", а только наименования - как искать причину в такой ситуации, как найти операцию с болтами под другим кодом и таким же названием?
При редактировании любой записи название будет одно и то же!
Я не рассматриваю ограничение на повтор названия - может быть ситуация, когда ограничение не допустимо или не возможно... не об этом речь! Если drop down combo box - можно вводить код, можно выбирать из списка - как кому нравится! Если пользователь часто выбирает из списка одни и те же материалы(или что то еще), он постепенно запомнит эти коды и будет их вводить сразу! Не выбирая из списка! Экономя время на набивке больших объемов данных!
И совсем не надо оклеивать стены тем, что высвечивается в ДропЛисте!

--
Best regards,
Чаплыгин
Написал: ClaList(2)
Гость

Сообщение Гость »

Hi.

Видишь ли. Обычно наименование делается уникальным. Если это болт, то это "Болт М8х100 ГОСТ...". Если кто-то влепил не тот болт, то это вопрос его премии. А в твоем случае код судя по всему не автоинкрементный, а смысловой.
Тогда он по сути есть часть наименования и он от него д.б. неотделим.

Если пользователь часто выбирает из списка одни и те же позиции, то можно сделать сортировку по частоте использования или по времени последнего использования или некую комбинацию из них. Такую штуку лучше делать отдельной таблицей с привязкой либо к рабочему месту либо к пользователю, чтобы тот, кто вбивеет болты не мешал тому, кто вбивает гайки. Может быть даже и с привязкой к окну и полю. Или IntelySence. Или как у ВЯ в CWPlus.
он постепенно запомнит эти коды и будет их вводить сразу! Не выбирая из списка! Экономя время на набивке больших объемов данных!
Можно и так. А можно так организовать локатор и поиск что коды запоминать не придется.

WBR, Nick Tsigouro mailto:nick@arsis.ru

(Добавление)

Здравствуйте!

Извините, что влез в Ваши обсуждения, но у меня возник попутный вопрос.
Очень часто на практике встречается ситуация, когда в форме Update как в поле DropList так и в его всплывающем списке требуется отображать информацию о нескольких полях в комбинированном виде.
Например, есть справочник отчетных периодов: Quarter (принимает значения 0,
1, 2, 3, 4), Year. Такие же поля присутствуют в таблице, в которой требуется добавить/изменить запись. В комбинированном виде значение в DropList, к примеру, надо отобразить так: "1 квартал 1999 год" или просто "2000 год" (если Quarter = 0). Как изменять формат отображения данных в всплывающем списке, я предполагаю. Заводится локальная переменная. А в списке отображать не поля таблицы, а эту переменную. Далее при построении очереди DropList корректно ее инициализировать.
Но как сделать так, чтобы при изменении записи после открытия Update-формы DropList отображал уже комбинированый вид в соответствии со значениями изменяемой записи?

Заранее благодарен.
Ситуация C55H, ABC
С уважением, Семен Попов

(Добавление)
Ну почему сразу не нравится? Просто другой подход к инетрфейсу. Как логическое развитие данного подхода могу предложить еще более простой в реализации вариант - избавить пользователя от какого-то невнятного поля наименования, а предложить ему просто вводить код в entry-поле.
И ему по-кайфу м программер не напрягается.
А можно пример в студию?
Я думаю, что не мне одному будет интересно взглянуть на работающий примерчик такого подхода.

--
С уважением,
Владимир Урбанский mailto:uvm@tut.by

Написал: ClaList(2)
Гость

Сообщение Гость »

Но как сделать так, чтобы при изменении записи после открытия Update-формы DropList отображаменять поле отчетного периодал уже комбинированый вид в соответствии со значениями изменяемой записи?
Что-то я не пойму. Ты позволяешь в форме менять поле отчетного периода? Т.е. можно данные одного периода перенести в другой? Может лучше сделать это поле вообще Readdonly - дать строкой и все.

WBR, Nick Tsigouro

Да, в моей задаче все именно так и происходит. Я позволяю пользователю редактировать отчетный период, хотя бы из-за того, чтобы была возможность исправить ошибку с отчетным периодом, которая произошла, например, при добавлении записи (допустим, пользователь был невнимателен).
Сейчас, для того, чтобы у меня после открытия формы при изменении записи отображался отчетный период в комбинированном виде, делаю что-то подобное,
что описывалось в этой теме выше. Размещаю рядом с DropList String-контрол, в котором отображаю после открытия отчетный период, используя текущий буфер.
И далее отслеживаю выбор отчетного периода в DropList. Хотелось бы не использовать для этого дополнительный контрол.

Семен Попов
Судя по дискуссии, стандартные clarion не позволяют такого. Жаль. :(
RTFM. Хотя бы по стандартным шаблонам.

WBR, Nick Tsigouro

Здравствуйте, Сергей!
Когда-то я не стал заморачиваться и ввел "внутренний стандарт" :D
Примерно так. Справочник имеет реквизиты:
ID - по нему строятся все ссылки и он не доступен для изменений пользователем, по нему Primary ключ keyID;
Kod - некий числовой код, иногда может быть не нужен, но, увы, стандарт...
По нему ключ keyKod.
Name - наименование;
NameK - мач-код (или как его там правильно), который короткий OVER на наименование в целях поиска, по нему ключ keyName.
Далее нарисовал небольшой Control-шаблон, который состоит из нескольких контролов:
приглашение, код (entry), кнопка выбора, наименование (string) с оконтовкой
(group).
Под код и наименование формируются локальные переменные (автоматически,
конечно).
Далее на закладке Action указываем нужные значения:
Primary-ключ справочника (это можно было опустить);
ключ справочника по коду;
смещение в этом ключе (если вдруг справочник составной);
поле наименования в справочнике;
процедура выбора;
поле-ссылка на справочник (содержащая его ID);
флаг "автоматический выбор".

Если "Автовыбор", то проваливаемся в таблицу выбора, не допуская прямого ввода кода.
Чаще всего юзеру нужно "одинаково", чтобы лишний раз голову не напрягать.
Нужны ему коды - он на них смотрит, не нужны, не смотрит. А если не нужны и их нет, а в других местах есть, то это может привести в замешательство :D
И никакой ручной писанины.
Все вышеизложенное глубокое ИМХО.

С уважением,
Вячеслав Черников

(Добавление)
А можно пример в студию?
Да ты что - это же стебалово было ;)
Ну сам подумай - предлагать оператору работать с кодами - вот я и творчески развил эту идею.

--
Best regards,
Vadym
Да, в моей задаче все именно так и происходит. Я позволяю пользователю редактировать отчетный период, хотя бы из-за того, чтобы была возможность исправить ошибку с отчетным периодом, которая произошла, например, при добавлении записи (допустим, пользователь был невнимателен).
Па-адажди. Отчетные периоды ведь не добавляются как бог на душу положит.
Второй квартал может идти только после первого. Поэтому, при попытке добавить, просто спрашиваем у юзера: "Вы действительно хотите добавить сводку за ... кв. ... г.?". И все. Никакого произвола. И что там собс-но руками делать? Просчет данных по базе и все.
Сейчас, для того, чтобы у меня после открытия формы при изменении записи отображался отчетный период в комбинированном виде, делаю что-то подобное, что описывалось в этой теме выше. Размещаю рядом с DropList String-контрол,
И не нужен дроп. Лукап кнопка, которая видна только юзеру с соотв. правами.

WBR, Nick Tsigouro

Нет, ты меня не понял. Правильно, отчетные периоды - это неприкосновенная информация. В той таблице, в которой изменяется запись (не в справочнике), я позволяю изменять и отчетный период - RCD:Quarter,RCD:Year. А уж допускаю значения для этих полей в форме Update из справочника отчетных периодов (ACPNSI:Quarter, ACPNSI:Year, ACPNSI:BeginPeriod (начало периода),ACPNSI:EndPeriod(окончание)). Для этого использую DropList на справочник. Проблема в том, чтобы при открытии формы для изменения записи DropList сам вставал на запись в справочнике с соответствующим отчетным периодом и отображал ее в комбинированном виде.

Семен Попов
Нет, ты меня не понял. Правильно, отчетные периоды - это неприкосновенная ...
Имено так я и понял.
В той таблице, в которой изменяется запись (не в справочнике), я позволяю изменять и отчетный период - RCD:Quarter,RCD:Year.
Не понимаю, зачем? Что вообще в этой табличке делать руками? Это все равно, что цифирькм репорта потом в ворде править.

WBR, Nick Tsigouro

(Добавление)

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

Семен Попов
Написал: ClaList(2)
Ответить