Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2003.02.13;
Скачать: [xml.tar.bz2];

Вниз

Как создать справочник?   Найти похожие ветки 

 
Сергей   (2003-01-17 13:32) [0]

Уважаемые знатоки Delphi!
Пожалуйста, поделитесь примерчиком создания справочника.
Задача (возможно стандартная, но, к сожалению, достойного примера,
я пока не нашёл): Есть таблица A, состоящая из двух полей: fCode (числовое)
и fName (строка 50 символов), и таблица B, которая, среди прочих, имеет
поле fA (числовое). Надо сделать так, чтобы при просмотре
записей таблицы B пользователь вместо значения её поля fA видел
значение поля fName из таблицы A (по связке B.fA=A.fCode), а при
редактировании таблицы B вместо редактирования её поля fA показывался бы
полноценный справочник (то есть содержимое таблицы A, которое тут же
можно редактировать (добавлять, изменять, удалять)!!!), из которого пользователь
может выбрать нужную запись, и тогда значение поля fCode из этой выбранной
записи должно попасть в поле fA редактируемой записи таблицы B.
Понимаю, что на создание даже простенького примера, нужно потратить время.
Но, может быть, кто-то хотя бы принцип создания такого справочника опишет.
Всем откликнувшемся заранее благодарен!
Сергей.
Мой e-mail: book_dsn@mail.ru.


 
Delirium^.Tremens   (2003-01-17 13:44) [1]

Блин, из всей этой пурги, (как я понял) следует что нужна классическая связка master-detail "один-ко-многим" и SQL запрос для ее просмотра с использованием левого соединения. Это в любой, самой глупой, книжонке о БД есть.

А свой e-mail я не скажу :-)


 
Sergey13   (2003-01-17 13:48) [2]

Серега, тезка, возьми любую книжку по Делфи и посмотри. То что ты написал - это классика жанра. Об этом во всех книгах и пОлно и доступно. И посмотри примеры к Делфе, там наверняка есть. Нормальный ответ на твой вопрос - это несколько страниц - вряд ли кто тебе даст. Вопрос простой - ответ длиный. 8-(


 
Сергей   (2003-01-17 13:51) [3]

Проблема, как раз не в связке, а в организации внесения информации не ручками, а с использованием справочника, в котором информацию можно изменять по ходу!!!


 
gek   (2003-01-17 13:54) [4]

Ну добавь кнопку "редакия" и показывай что душе угодно


 
Сергей   (2003-01-17 13:56) [5]

Вот, я то и хочу узнать как правильно добавить эту кнопку и возвратить выбранный результат.


 
Sergey13   (2003-01-17 13:58) [6]

Что значит "правильно"? Как работает - так и правильно.


 
passm   (2003-01-17 14:08) [7]

Сергей (17.01.03 13:56)> В гриде поле со значением из справочника и ByttonStyle = cbsEllipsis и ReadOnly = True.
При клике на кнопку/нажатии (Enter or Shiht+Enter... as You like)... и т.д. и т.п. :)


 
MsGuns   (2003-01-17 16:02) [8]

Сабж, ИМХО, не совсем корректен. Подразумевалось, видимо, создание не справочника, а удобного (для юзера, ессно), интерфейса работы с ним, включая добавление "на лету", т.е. без лишних клацаний на меню "Справочники" и т.д.

Сам справочник и панель с контролами (простыми типа TEdit) надо соорудить в виде формы, отрываемой модально. При открытии формы надо позиционироваться на входной ключ, если он передан из гол.формы как значение соотв. поля тек.записи осн.таблицы (Locate). "Путешествие" по гриду справочника обычным способом.
По дв.клику (или кнопке или попапу) юнит справочника "снимает" значения полей тек.записи спр-ка и записывает их в переменные (я это делаю через рекорд), после чего форма закрывается. Гол.прога проверяет значения рекорда и, если они не пустые, записывает что надо куда надо (при простом выходе из спр-ка рекорд заполняется типа пробелами).
Панель служит для редактирования-добавления в справочник и в обычном режиме не видна. Вкл-ся по спец.контролу "Добавить"/"Изменить". Котнролы панели не должны быть напрямую связаны с таблицей справочника. При открытии панели они чистятся при добавлении или заполняются данными тек.записи при редактировании. Есть еще 2 контрола: "Записать" и "Отменить". Если выбран первый, то делаешь проверку корректности и дублирования ключей (поиск по спр-ку Locate`ом) и если все нормальненько, даешь таблице ReadOnly=false, и далее по контексту, после чего передаваемый в гол.форму рекорд заполняется как при простой выборке и закрывается и панель и форма. Да, замены-вставки предпочтительнее делать запросами. Если нажата "Отмена", просто прячешь панель.


 
Сергей   (2003-01-17 18:16) [9]

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


 
atmamont   (2003-01-17 18:20) [10]

Всем, кто не понял - человек хочет сделать так, как это сделано в 1С:Предприятии.


 
Сергей   (2003-01-17 18:24) [11]

atmamont, совершенно верно! 1С-Предприятие в плане интерфейса для меня сейчас является эталоном, к которому надо стремиться, но как это сделать - пока, к сожалению, не знаю.


 
MsGuns   (2003-01-17 18:26) [12]

>Сергей (17.01.03 18:16)

Вызываемая форма может иметь методы, которые вызываются вызывающими формами, например, вкл/откл фильтр. Для того, чтобы проверить, надо ли это делать (мод.форма может быть в этот момент невидима), достаточно просто проверить ее св-во Visible.

Чтобы форма не вызывалась модально, но была видна, достаточно присвоить FormStyle := fsStayOnTop, а если она уже такова, но надо ее "положить на верх", то BringToFront

А вообще-то для справочника я бы не советовал использовать немодальную форму. Работа со справочником - вещь достаточно ответственная и юзер должен так же к этому и относиться.


 
Delirium^.Tremens   (2003-01-17 18:30) [13]

Пять часов продолжалось изобретение велосипеда. Вы бы уж хоть какое-нибудь 2С:Предприятие мастерили, а лучше 3С. Там, в "Потрепаться" народ свои операционки пишет и просит кусочек примера :-)


 
MsGuns   (2003-01-17 18:33) [14]

>Сергей (17.01.03 18:24)
>atmamont, совершенно верно! 1С-Предприятие в плане интерфейса для меня сейчас является эталоном, к которому надо стремиться, но как это сделать - пока, к сожалению, не знаю.

А вот это зря,- не той дорогой идете, товарищ !
Интерфейс 1С перегружен чрезвычайно, много контролов, которые 99% юзеров если и кликают, то после этого лезут под стол от страха или благим матом зовут программера. Далее. Внешне все кажется клево, но механизм обмена данными с физ.таблицами (как впрочем и сами таблицы) совершенно корявый. Вот почему более чем на 3-х компах без MS SQL сервера и энтей 1С просто не работает.
1С - отличный пример красивой обертки, в которую завернут кусок г... (не говорю про все реализации 1С.Предприятие, но про базовую- точно)

Впрочем, это все - ИМХО 8))



 
Delirium^.Tremens   (2003-01-17 18:35) [15]

MsGuns © (17.01.03 18:33)

> Интерфейс 1С перегружен чрезвычайно, много контролов, которые
> 99% юзеров если и кликают, то после этого лезут под стол
> от страха или благим матом зовут программера

Это кто как сконфигурировал и 1С за чужие кривые руки не отвечает (у самой кривые)


 
MsGuns   (2003-01-17 18:39) [16]

>Delirium^.Tremens © (17.01.03 18:35)

Я же дал сноску - базовый


 
Сергей   (2003-01-17 18:40) [17]

На самом деле, если понимаешь, что хочешь сделать, то больших проблем в 1С нет, а удобство присутствует.


 
MsGuns   (2003-01-17 18:50) [18]

>Сергей (17.01.03 18:40)
>На самом деле, если понимаешь, что хочешь сделать, то больших проблем в 1С нет, а удобство присутствует.

Еще одно заблуждение. Интерфейс - с некоторыми оговорками ДА, но вот НОРМАЛЬНО функционирующую БД с возможностью масштабирования и развития в дальнейшем - ни за что !
1С - это прежде всего хорошее (и, пожалуй, единственное) средство для "заушного" горе-программиста (или того, кто себя таковым считает) за пару-тройку месяцев научиться быстро и без хлопот "рубить" деньгу с доверчивых ламеров-клиентов, пожлобившихся заказать нОРМАЛЬНЫЙ софт для своей конторы.

В этом плане 1С как СРЕДА программирования, действительно, равных себе не знает !



 
Jeer   (2003-01-17 23:07) [19]

Вкратце могу рассказать как делаю.

Базовая форма (на основе которой создаются потомки) обладает методами посылки и приема сообщений (как в основную, так и модальные и дочерние формы,) а также широковещательным сообщением.
Протокол сообщений (читай правила передачи команд и параметров) в моем случае определяется так:
- команда(ы - скрипт), т.е что делать.
- блок параметров
Пример
"cmd=8;id=1234"
Команда 8 - позиционирование (locate)
На запись с id=1234

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

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




 
ЮЮ   (2003-01-18 03:00) [20]

Если это действительно справочник, то кроме наименования у объекта должны быть ещё какие-то св-ва, и добавление "на лету" бесмысленно. Если же эта таблица - сборище повторяющихся текстовых строк, то лучше просто создать текстовое поле и не экономить место :-)


 
Wolf   (2003-01-18 12:10) [21]

Надо убедить клиента, что делать так нельзя, а то будет у него в таблице А:
ежики, ежеки, Ежики, ежки и т.п.


 
MsGuns   (2003-01-18 18:16) [22]

>ЮЮ © (18.01.03 03:00)
>Если это действительно справочник, то кроме наименования у объекта должны быть ещё какие-то св-ва, и добавление "на лету" бесмысленно

Не спора ради а токмо для истины ;)
Справочник справочнику - рознь. Внекоторых случаях добавление "на лету" не только удобно, но и необходимо. Пример:

Офис крупной оптовой фирмы. Стоит с десяток операционных мест, с которых по телефону и так идет работа с клиентами - покупателями. Операционист-менеджер, выписывая счет/накладную, должен ввести в него (счет): кому выписан. Справочник номер раз. При добавлении нового клиента выясняется, что его банк не внесен в общий корпоративный справочник банков. Надо тут же добавить. Справочник номер два. Т.е. "двухслойное" редактирование последовательной цепочкой сразу двух справочников. А бывает и больше. Есть, конечно, другой вариант - предварительная регистраиця клиента у админа БД или у ведущего менеджера по продажам. Но это лишние задержки, которые не нравятся покупателям и вредят имиджу фирмы.
Как при добавлении нового клиента не допустить избыточности (т.е.повторного ввода одного и того же ЮЛ) - это уже часть бизнес-логики и зависит от проф.качеств разработчика приложения.


 
ЮЮ   (2003-01-20 04:08) [23]

MsGuns © (18.01.03 18:16)
Не убедил :-) В данном случае видно лишь следующее: операционисту-менеджеру без разницы структура БД: Клиенты, Банки и т.п., ему надо просто выписать счёт с заполненными реквизитами. А все эти Клиенты и Банки появились лишь от избыточного "профессионализма" разработчика приложения :-)
В противном случае, операционист-менеджер должен был первым делом найти клиента в БД, при его отсутствии создать его и заполнить минимально необходимую информацию, в.ч. его Банк, и уже оттуда вызвать "выписать счёт"



 
Сергей   (2003-01-25 14:38) [24]

Снова у меня появилась свободная минута и я с большим удовлетворением обнаружил, что дисскуссия всё ещё продолжается. Полностью поддерживаю обстоятельное объяснение MsGuns`а в защиту необходимости корректировки справочника на лету. Скажу честно, в данный момент я занимаюсь, как программированием, так и внесением информации, поэтому больше рассматриваю проблему не со стороны "как удобно программисту", а со стороны "как удобно пользователю". А пользователю удобно решать проблемы по мере их возникновения, а не предусматривать заранее!!!
Всем откликнувшимся спасибо за хорошие советы! Некоторые из них я уже попробовал реализовать.
Сделав ставку на удобство для пользователя, всё же хочу не использовать модальные формы. И тут, извините меня за упёртость и тупость, ещё раз спрашиваю: "Форма [А] должна вызывать форму [Б]. Форма [В] должна возвратить результат в элемент вызвавшей её формы [А], если к тому времени форма [А] не будет закрыта пользователем. Как правильно это сделать?"


 
MsGuns   (2003-01-25 17:12) [25]

Форма "B" записывает выходные параметры (например, реквизиты выбранного (добавленного) юзером покупателя) в параметры (я в таких случаях использую тип Record), которые доступны форме "А". Затем проверяется "визуальность и активность форма "А". Если форма невизибельная (юзер ее закрыл), то упр-е остается в текущем контроле, если же она визибельная, то фокус на нее, а если и активна, то вообще ничего не делается (Exit из соотв. процедуры -обработчика кнопок "Выбрать"/"Отменить")
Если надо, чтобы форма "В" была на экране, даже когда фокус в форма "А", сделай ей ("В") FormSlyle := fsStayOnTop (На мой взгляд не самый лучший интерфейс для справочника - постоянное его присутствие на экране - а если справочников не один, а 6, да еще "лестницей" ?



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2003.02.13;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.53 MB
Время: 0.01 c
1-38312
Leshiy
2003-02-01 10:45
2003.02.13
Два ComboBox a один Items.


3-38136
Spell
2003-01-27 21:00
2003.02.13
Transaction IBase


14-38449
Tsr
2003-01-29 17:43
2003.02.13
Пижоны


3-38105
Victor_
2003-01-27 14:08
2003.02.13
ADOQuery + сортировка


7-38581
Arkan
2002-12-09 22:57
2003.02.13
Программно падавать напряжение на светодиоды.





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский