Приветствую всех.
Столкнулся с проблемкой, которую не могу решить, хотя могу обойти. В чём проблема… У меня данные хранятся в таблицах SQLight. Выбранные данные отображаются в таблицах treeView. id записей из БД сохраняются в iid строк таблиц treeView. Таким образом сохраняется связь между хранимыми данными и отображаемой выборкой. При добавлении данных (новых строк/записей) надо дать пользователю возможность выбора нового значения из списка уже существующих. Соответственно - Combobox. Пользователь выбирает нужное значение из выпадающего списка, а для записи в БД мне надо знать id этого значения. Надо выполнить обратный поиск в таблице, чтобы по значению найти его id. При этом надо учитывать условия, с которыми выполнялась выборка. Это крайне не удобно. И, даже, если мне удастся накрутить/наворотить логику обратного поиска с учётом всех условий предыдущих выборок, я не могу быть уверен что будет найден правильный id (местами значения могут повторяться). К сожалению, Combobox, в отличие от treeView, не позволяет привязать к отображаемым значениям свои индексы или тэги. Поэтому я пошёл таким путём: собираю в строку id значения и само значение и в таком виде даю пользователю для выбора. Выглядит не очень красиво, но: собрать строку не сложно; пользователь понимает что он выбирает; после выбора сплитануть строку и получить из неё id - тоже без проблем.
Буду рад, если кто-то сможет подсказать более красивое решение, как сохранить однозначное соответствие между значениями в списке выбора Combobox и записями в БД, без создания временных дополнительных виртуальных таблиц или словарей.

Alex.Pro.
возможность выбора нового значения из списка уже существующих. Соответственно - Combobox.

так все равно запрос к БД нужен для создания списка. будет таблица.
один из столбцов выводите в Combobox, у него есть currentText/currentIndex, по индексу и определите остальное
типа так

vic57
все равно запрос к БД нужен для создания списка. будет таблица.

Пожалуй, вы правы. Сейчас я склоняюсь к использованию словарей. Из БД читаю соответствующие условиям значения вместе с ключами и формирую словарь {значение:ключ}. Одно из условий - уникальность значений. Ключи в БД - тем более уникальные. Так что в словаре собираются взаимооднозначные пары. Значениями из словаря (которые - ключи словаря) заполняю Combobox, а потом по выбранному значению нахожу в словаре нужный ключ из БД.

vic57
один из столбцов выводите в Combobox, у него есть currentText/currentIndex, по индексу и определите остальное

Жалко только что currentIndex - это внутренний индекс Combobox'а, напрямую не связанный и не связываемый с ключами БД. Получить из Combobox'а выбранное значение - не проблема. Проблема - потом найти всё остальное, учитывая что в БД (в отличие от выборки для Combobox'а) значения могут повторяться.
И приведённый пример, к сожалению, не помогает связать Combobox с БД. Банальный баян. Но всё равно благодарю за желание помочь. Тем более, что мысль “всё равно будет таблица” (или словарь) - мне нравится.

Alex.Pro.
Жалко только что currentIndex - это внутренний индекс Combobox'а, напрямую не связанный и не связываемый с ключами БД.

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

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

py.user.next
у тебя произошло классическое смешение частей программы из-за нехватки знаний.

Ну вот опять. Побежали кособокие собаки. Ну и пусть себе бегут, не зная откуда бегут, не понимая почему бегут, не зная куда бегут. И не видя связи между пунктом А и пунктом Б.

Alex.Pro.
Ну вот опять. Побежали кособокие собаки.

Я имею в виду, что когда ты так напишешь, по-своему - связав базу данных и выпадающее меню напрямую, тогда при изменении базы данных сразу сломается это меню целиком, а при изменении меню сразу сломается база данных целиком. Это как колесо от машины, которое не на болтах к машине прикрутили, а которое приварили сварочным аппаратом со словами “приварить-то будет гораздо крепче и надёжнее, чем на этих дурацких болтиках его прикручивать! я - Кулибин! а они - дураки все!”. Потом это всё будет ездить, но до первой пробоины на дороге. А когда ты захочешь заменить колесо, потому что надо ехать дальше и срочно, ты выйдешь и увидишь, что какой-то дебил приварил его сварочным аппаратом и ты не можешь его заменить, и оторвать ты его не можешь, потому что в данный момент ты на дороге, а не в мастерской. Так что с таким подходом у тебя будет стандартная ситуация: наделав кучу компонентов, ты будешь сидеть и бояться что-то менять в них во всех, если даже всем будет очевидно, что в них что-то кривое получилось и нужно это срочно исправить и выпрямить, потому что, пукнув лишний раз не туда в каком-нибудь мелком компоненте твоего вот этого произведения, в результате у тебя развалится всё приложение. Колесо сломалось одно, а встала вся машина, а не только это колесо. Вот так она будет на соплях жить, пока не будет пробоина, пока кто-нибудь не сменит где-нибудь API по желанию своей левой пятки и у тебя не спросит, менять его ему или нет, или когда тебе надо будет в базу данных добавить поле или значения видоизменить, а ты будешь понимать, что ты не можешь этого сделать, что ты не можешь заменить колесо.

py.user.next
колесо от машины, которое приварили сварочным аппаратом

Какое колесо, какая сварка, что за бред? Спасибо vic57 понял вопрос и подсказал подходящий способ связи между хранимыми и отображаемыми данными.