Поэтому, попробовав каждую хитрость, которую я мог придумать, используя фильтры и получив короткую оценку, я остановился на грязном решении, которое частично подрывает поведение окна данных, но работает.
Я решил, что единственный способ исправить этопроблемы отображения, вызванные несоответствием между выбираемыми значениями в раскрывающемся окне данных и фактическими значениями, введенными в столбец, состояли в том, чтобы гарантировать, что несоответствие фактически никогда не может произойти.
Я создал новый столбец раскрывающегося окна данных сотрудника, в котором столбцы отображения и данных указывают на поле имени сотрудника.Пользователь выбирает имя сотрудника, и идентификатор сотрудника затем выбирается вручную из дочернего окна данных, используя Find и GetItemString, где это необходимо.В результате выпадающее окно данных больше не может манипулировать данными - теперь это нужно делать вручную в коде, - но при изменении выражений фильтра визуальные изменения в существующих строках отсутствуют.
До того:
ls_employee = dw_1.GetItemString(row, "employee") //Returns employee ID
После:
ls_employee = dw_1.GetItemString(row, "employee") //Returns employee name
ls_employee = ldwc_employee.GetItemString(ldwc_employee.Find("employee_name = '" + ls_employee + "'", 1, ldwc_employee.RowCount()), "employee_id") //Find row number and fetch ID
Тогда, поскольку пользователь больше не вставляет значения PK / FK в таблицу, идентификатор сотрудника должен быть вручную установлен на старом(скрытый) столбец идентификатора сотрудника перед вызовом обновления.
dw_1.SetItem(row, "employee_id", ls_employee)
Я не совсем доволен этим решением, поскольку оно делает использование раскрывающегося окна данных в конечном счете бессмысленным.Также не учитываются случаи, когда поиск может вернуть неправильный номер строки, если два сотрудника имеют одинаковые имена и фамилии, но это приемлемо в моем случае, потому что такие ситуации крайне маловероятны.
Так что я не горжусь этим, но это так или иначе.