Свойства Combobox

[Atani]

1. У контрола Combobox есть свойство ComboType = Standart (по умолчанию). Что изменится, если поставить значение List (на форме вид контрола не менился)?

2. Свойство AppendNew, которое в положении Yes даёт вводить текст в поле контрола, а в положении No позволяет только лукапить. Как работает это свойство, что добавляет и куда, если набрать можно только текст из выпадающего списка? Другой текст затирается сразу после нажатия на Enter. Кроме того, метод Combobox1.Text() возвращает всё время пустую строку.

3. Можно ли ширину выпадающего списка сделать неравной ширине самого контрола, чтобы, например, на форме от контрола остался только значок лукапа (примерно 23 пиксела), а сам выпадающий список показывал весь текст (15-20 символов)?

[Ruff]

1. ComboType = List как раз и запрещает вводить текст в поле контрола, а не AppendNew.
2. Пока не знаю...
3. Легче всего - использовать ActiveX

[maxsmirnov]

2.
append new text to the list on editing.
This property can be used on unbound controls only

перевод
позволяет добавлять в выпадающий список свои значения.
Работает если контрол не связан с Enum итп.

[Ruff]

Цитата:

Изначально опубликовано maxsmirnov
2.
Работает если контрол не связан с Enum итп.

А-а-а! Так вот в чем фишка... А я думал "unbound" - значит не связанный с DataSource.
Связал с Enum-ом, и ничего не работало...
Хотя это все-равно не снимает еще один вопрос:

Цитата:

... метод Combobox1.Text() возвращает всё время пустую строку.

[maxsmirnov]

PHP код:

getText(int номер строки) 


[Ruff]

Только как его узнать, этот номер строки.....
.item() всегда возвращает 1, независимо от выбранного пункта.
Это в методе modified() проверялось. Или не там надо было?

[maxsmirnov]

selection()

[Atani]

Спасибо, люди, для меня вопрос исчерпан.

[blokva]

Цитата:

Изначально опубликовано Atani
Спасибо, люди, для меня вопрос исчерпан.

А вот у меня вопрос: при изменении ComboBox как получить доступ к первоначальному значению?
т.е. я в методе modified() хочу проанализировать предыдущее значение контрола!

[maxsmirnov]

в init() формы запоминайте первоначальное значение и с ним сравнивайте

[Artild]

а есть в Аксапте возможность в ComboBoxе, который связанс Enum, не отображать часть элементов Enumа???

[mazzy]

только в том случае, если в элементах enum указаны security или функциональные ключи И для текущего пользователя эти ключи выключены.

Если же у вас некоторые enum отсутствуют исходя из логики программы (а не из соображений security), то необходимо создавать новый enum в AOT.

[Atani]

Или же создавать такой вот отвязанный от всего combo, и наполнять его вручную допустимыми значениями функцией .Add()

Резюмируя про AppendNew. С помощью этого свойства можно создать поле ввода типа ComboBox, но с возможностью ввода значения, отличного от перечисленных в выпадающем списке. Например, на регистрационной форме предлагается ввести город проживания, при этом выдаётся список известных (авторам :-)) городов и существует возможность ввести в этом же поле свой город, если он не найден в списке.

Создаётся ComboBox, не привязанный ни к enum, ни к datasource, со свойством AppendNew = Yes. В методе ComboBox.Modified() прописывается результат в текстовое поле базы данных. Например: Towns.TownName = ComboBox.getText(ComboBox.Selection());

Да, предварительно в методе init() наполнить контрол значениями из базы или из enum'а. Вот только не знаю пока, как динамически пробежаться по значениям enum'а...

[mazzy]

Цитата:

Изначально опубликовано Atani
Или же создавать такой вот отвязанный от всего combo, и наполнять его вручную допустимыми значениями функцией .Add()

постарайтесь все же не программировать.
вам же потом легче будет.

и обновлять, и разбираться, и использовать свой же код.

[Антон Солдатов]

Цитата:

Изначально опубликовано mazzy

постарайтесь все же не программировать.
вам же потом легче будет.

В ситуации, когда "родительский" список может изменяться, придется выбирать между двух зол - модифицировать все дочерние списки(их тоже может быть много), либо изначально программным способом фильтровать один большой список, но тратить дополнительные ресурсы на переход к новым версиям.

[mazzy]

Антон, извини конечно... щас буду резать правду-матку прямо в лицо

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

Что хочу сказать... если поменялся родитель, а потомки не изменились...
Это значит, что теперь потомки НЕ наследуют от родителя!
Это очень серьезное логическое изменение!
При настолько серьезных изменениях придется изменять очень многое.
поэтому предусматривать универсальную обработку таких случаев бесполезно! Все равно такой случай универсально не обрабоаешь.

Бог с ним с этим случаем. Но когда программисты делают универсальные обработки разных сущностей или универсальные формы для разных таблиц или универсальные лукапы или универсальные деревья... это и есть тот случай, когда программист решает свои программистские задачи, а не задачи внедрения.

Пример в Аксапте - hrmvirtualnetwork, markuptrans. Пример "правильной" на мой взгляд универсальности - журналы, колонки в финансовых отчетах, типы заказов, типы складских строк.

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

все вышеизложенное - сугубо ИМХО. Извините, если кого задел.

[Антон Солдатов]

Цитата:

Изначально опубликовано mazzy
Что хочу сказать... если поменялся родитель, а потомки не изменились...
Это значит, что теперь потомки НЕ наследуют от родителя!
Это очень серьезное логическое изменение!

Не будем уходить далеко от конкретной ситуации. Есть набор констант BaseEnum, которые бы неплохо было отображать в разных формах в разном составе. Но значения этих констант во всей логике должны оставаться неизменными. Например, я хочу чтобы в одних формах в комбобоксе "Тип чего-то там" был с двумя элементами, в других формах с тремя, т.к. остальные элементы В ЭТИХ ФОРМАХ никогда не используются.
Вполне возможный случай: в BaseEnum будут добавляться новые элементы.
Если мы будем фильтровать програмно в наших формах некоторые константы(например по постфиксу в имени элемента, т.к. никаких дополнительных свойств в элементах BaseEnum-а я не заметил), то при добавлении нового элемента он будет легко и непринужденно обработан.
Если же мы будем создавать для разных типов форм разные списки, с теми же константами, исключая лишь некоторые элементы, то как раз и возникают все "родственные" заморочки - при добавлении нового элемента в базовый BaseEnum, нам нужно исходя из соотв. правил обновить наши списки(в какие-то добавить, в какие-то нет). Таких дополнительных списков может быть достаточно много, чтобы задуматься о программировании(которое есть зло (с)mazzy).

[mazzy]

Хорошо, вернемся к...

Цитата:

Изначально опубликовано Антон Солдатов
Есть набор констант BaseEnum, которые бы неплохо было отображать в разных формах в разном составе. Но значения этих констант во всей логике должны оставаться неизменными.
Вполне возможный случай: в BaseEnum будут добавляться новые элементы.
Если мы будем фильтровать програмно в наших формах некоторые константы(например по постфиксу в имени элемента, т.к. никаких дополнительных свойств в элементах BaseEnum-а я не заметил), то при добавлении нового элемента он будет легко и непринужденно обработан.

Программой!
А как же человек?

Человеку будет выдан совершенно разный набор строк, а для программиста "значения этих констант во всей логике должны оставаться неизменными".

Вот так и получаются, ИМХО, ситуации, когда "сюда смотри, сюда не смотри, здесь рыбу заворачивали"

Человек в разных формах видит разный набор констант. Значит для человека это разные константы! С какой стати внутри программы эти разные наборы должны быть представлены одним enum'ом? Только потому, что программисту так легче программировать? Это и есть решение задач программиста, а не решение задач внедрения. (Причем, замечу, на редкость извратное и противоречащее ядру. Т.е. программисту при таком подходе придется постоянно бороться с ядром, вметос того, чтобы получать от него помощь)

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

Поэтому считаю, что программное вмешательство в enum - очень плохой подход. Со всех точек зрения.

[Антон Солдатов]

Цитата:

Изначально опубликовано mazzy
Человек в разных формах видит разный набор констант. Значит для человека это разные константы! С какой стати внутри программы эти разные наборы должны быть представлены одним enum'ом?

для человека это будет все тот же набор, но без некоторых элементов. Например: в форме А, мы можем выбрать для Типа нашей штуки варианты {1,2,3}. В форме Б при создании этой же штуки мы можем выбрать варианты {4,5,6}. А в отчете по всем, созданным штукам, мы хотим видеть все штуки с вариантами {1,2,3,4,5,6}.
[Подобной штукой например может быть "строка в журнале" и полем "тип счета".]
Для пользователя очевидно, что во всех формах(фактически это может быть и одна форма, только со включенными/выключенными полями) все те же штуки, только разных типов.. Непонимания не должно возникнуть.

Цитата:

Изначально опубликовано mazzy

Поэтому считаю, что программное вмешательство в enum - очень плохой подход. Со всех точек зрения.

програмное вмешательство будет не в baseenum(ни в коем разе!), а в дизайн формы, т.е. исключительно в презентационную логику.

[Garic]

Не согласен.
Часто нужно скрыть конкретные значения у enum. В 3.0 кстати нельзя закрыть их security key.
Посмотрите как реализован выбор к обработке в документах заказов/закупки. Там скрываются ненужные значения enum-ов для разных документов (скомплектовано например). Здесь это решается ограничением на максимальный код enum-а. Иногда этого бывает недостаточно - тогда и приходится програмно добавлять в комбобокс, а потом обрабатывать при выборе.