Форум сайта python.su
Приветствую всех.
Столкнулся с проблемкой, которую не могу решить, хотя могу обойти. В чём проблема… У меня данные хранятся в таблицах SQLight. Выбранные данные отображаются в таблицах treeView. id записей из БД сохраняются в iid строк таблиц treeView. Таким образом сохраняется связь между хранимыми данными и отображаемой выборкой. При добавлении данных (новых строк/записей) надо дать пользователю возможность выбора нового значения из списка уже существующих. Соответственно - Combobox. Пользователь выбирает нужное значение из выпадающего списка, а для записи в БД мне надо знать id этого значения. Надо выполнить обратный поиск в таблице, чтобы по значению найти его id. При этом надо учитывать условия, с которыми выполнялась выборка. Это крайне не удобно. И, даже, если мне удастся накрутить/наворотить логику обратного поиска с учётом всех условий предыдущих выборок, я не могу быть уверен что будет найден правильный id (местами значения могут повторяться). К сожалению, Combobox, в отличие от treeView, не позволяет привязать к отображаемым значениям свои индексы или тэги. Поэтому я пошёл таким путём: собираю в строку id значения и само значение и в таком виде даю пользователю для выбора. Выглядит не очень красиво, но: собрать строку не сложно; пользователь понимает что он выбирает; после выбора сплитануть строку и получить из неё id - тоже без проблем.
Буду рад, если кто-то сможет подсказать более красивое решение, как сохранить однозначное соответствие между значениями в списке выбора Combobox и записями в БД, без создания временных дополнительных виртуальных таблиц или словарей.
Онлайн
Alex.Pro.так все равно запрос к БД нужен для создания списка. будет таблица.
возможность выбора нового значения из списка уже существующих. Соответственно - Combobox.
def selected(event): # получаем выделенный элемент selection = combobox.get() val = combobox.cget('values') print(selection, val.index(selection)) languages = ["Python", "C#", "Java", "JavaScript"] combobox = ttk.Combobox(values=languages, state="readonly") combobox.pack(anchor=NW, fill=X, padx=5, pady=5) combobox.bind("<<ComboboxSelected>>", selected) root.mainloop()
Офлайн
vic57Пожалуй, вы правы. Сейчас я склоняюсь к использованию словарей. Из БД читаю соответствующие условиям значения вместе с ключами и формирую словарь {значение:ключ}. Одно из условий - уникальность значений. Ключи в БД - тем более уникальные. Так что в словаре собираются взаимооднозначные пары. Значениями из словаря (которые - ключи словаря) заполняю Combobox, а потом по выбранному значению нахожу в словаре нужный ключ из БД.
все равно запрос к БД нужен для создания списка. будет таблица.
vic57Жалко только что currentIndex - это внутренний индекс Combobox'а, напрямую не связанный и не связываемый с ключами БД. Получить из Combobox'а выбранное значение - не проблема. Проблема - потом найти всё остальное, учитывая что в БД (в отличие от выборки для Combobox'а) значения могут повторяться.
один из столбцов выводите в Combobox, у него есть currentText/currentIndex, по индексу и определите остальное
Онлайн
Alex.Pro.Если тебе что-то жалко, можешь пронаследоваться и сделать свой Combobox на основе существующего, добавив в него атрибуты и методы, которых в нём не было изначально. Но из этой возможности не следует, что это правильное решение всегда.
Жалко только что currentIndex - это внутренний индекс Combobox'а, напрямую не связанный и не связываемый с ключами БД.
Офлайн
py.user.nextНу вот опять. Побежали кособокие собаки. Ну и пусть себе бегут, не зная откуда бегут, не понимая почему бегут, не зная куда бегут. И не видя связи между пунктом А и пунктом Б.
у тебя произошло классическое смешение частей программы из-за нехватки знаний.
Онлайн
Alex.Pro.Я имею в виду, что когда ты так напишешь, по-своему - связав базу данных и выпадающее меню напрямую, тогда при изменении базы данных сразу сломается это меню целиком, а при изменении меню сразу сломается база данных целиком. Это как колесо от машины, которое не на болтах к машине прикрутили, а которое приварили сварочным аппаратом со словами “приварить-то будет гораздо крепче и надёжнее, чем на этих дурацких болтиках его прикручивать! я - Кулибин! а они - дураки все!”. Потом это всё будет ездить, но до первой пробоины на дороге. А когда ты захочешь заменить колесо, потому что надо ехать дальше и срочно, ты выйдешь и увидишь, что какой-то дебил приварил его сварочным аппаратом и ты не можешь его заменить, и оторвать ты его не можешь, потому что в данный момент ты на дороге, а не в мастерской. Так что с таким подходом у тебя будет стандартная ситуация: наделав кучу компонентов, ты будешь сидеть и бояться что-то менять в них во всех, если даже всем будет очевидно, что в них что-то кривое получилось и нужно это срочно исправить и выпрямить, потому что, пукнув лишний раз не туда в каком-нибудь мелком компоненте твоего вот этого произведения, в результате у тебя развалится всё приложение. Колесо сломалось одно, а встала вся машина, а не только это колесо. Вот так она будет на соплях жить, пока не будет пробоина, пока кто-нибудь не сменит где-нибудь API по желанию своей левой пятки и у тебя не спросит, менять его ему или нет, или когда тебе надо будет в базу данных добавить поле или значения видоизменить, а ты будешь понимать, что ты не можешь этого сделать, что ты не можешь заменить колесо.
Ну вот опять. Побежали кособокие собаки.
Отредактировано py.user.next (Янв. 16, 2025 04:15:05)
Офлайн
py.user.nextКакое колесо, какая сварка, что за бред? Спасибо vic57 понял вопрос и подсказал подходящий способ связи между хранимыми и отображаемыми данными.
колесо от машины, которое приварили сварочным аппаратом
Онлайн