17.12.2010, 13:56 | #1 |
Участник
|
Заблокировать menuItemButton если запись не выбрана
Как проще всего заблокировать menuItemButton если запись в соответствующем DataSource не выбрана (DataSource пуст либо фильтром скрыты все записи)? Почему такое поведение не предусмотренно по умолчанию?
|
|
17.12.2010, 14:02 | #2 |
Ищущий знания...
|
я обычно в методах формы пишу метод, что то типа activeButton. В этом методе пишу что то типа:
X++: MymenuItemButton.Enabled(DataSource.RecId != 0); далее в методе active нужного dataSource вызываю этот метод.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
17.12.2010, 14:03 | #3 |
Участник
|
не предусмотренно по умолчанию т.к. в этом нет смысла. проверяйте наличие курсора непосредственно внутри вызываемого класса или формы
Последний раз редактировалось ice; 17.12.2010 в 14:28. |
|
17.12.2010, 14:25 | #4 |
Участник
|
|
|
17.12.2010, 14:27 | #5 |
Участник
|
|
|
17.12.2010, 14:48 | #6 |
Участник
|
Решил в событии leave
Да и ещё по умолчанию в самом дизайнере, либо в ините формы, заблокировать кнопку, на случай если сразу после открыти формы datasource уже пуст. Исправление: не leaveRecord а просто leave(). При потери гридом фокуса ввода событие leave не происходит, в отличии от leaveRecord. Последний раз редактировалось S.Kuskov; 17.12.2010 в 15:08. |
|
17.12.2010, 15:01 | #7 |
Участник
|
и так на каждой форме, куда добавите кнопку?
|
|
17.12.2010, 15:13 | #8 |
Ищущий знания...
|
изначально, этот метод вызывается в init(). затем в active() главного дата сорса, к которому приджойнены остальные, и затем в active() остальных дата сорсов. и все. все нормально работает
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
17.12.2010, 15:17 | #9 |
Участник
|
|
|
17.12.2010, 15:25 | #10 |
Участник
|
А если удалить из грида единственную запись или наложить такой фильтр, условию которого не удовлетворит ни одна из записей и грид опустеет, тогда также вызовется activeButton?
|
|
17.12.2010, 15:31 | #11 |
Участник
|
можно было разместить кнопку в выпадающем меню, и блокировать кнопку при нажатии на кнопку меню. а проверку в вызываемом классе все равно придется делать, тк если его вызывут из кода, то он некорректно отработает
|
|
|
За это сообщение автора поблагодарили: S.Kuskov (1). |
17.12.2010, 15:33 | #12 |
Ищущий знания...
|
Цитата:
Но тема не про это, а про отдельный menuItemButton. И иногда кнопки должны быть просто на форме, без всяких MenuButton.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
|
За это сообщение автора поблагодарили: S.Kuskov (1). |
17.12.2010, 15:35 | #13 |
Участник
|
|
|
17.12.2010, 15:38 | #14 |
Ищущий знания...
|
Цитата:
но тут уже подстраховывает проверка в самой функции
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
17.12.2010, 15:40 | #15 |
Ищущий знания...
|
кстати, можно попробовать добавить на active() формы вызов этого метода. по идее active() формы должен вызываться всегда когда форма обновляется (не уверен, надо проверять), тогда вообще никаких проблем. и не надо в дата сорсах ничего писать
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
17.12.2010, 16:13 | #16 |
Участник
|
Проверил active() формы - работает только при активации окна, а не при любом его обновлении (оно и правильно). Здесь скорее нужно ловить манипуляции с источником данных, прекрыть и executeQuery() и delete(), но это не спортивно . Вот было бы прекрасно если бы такое поведение кнопки регулировалось каким-нибудь стандартным свойством. Мне кажется в этом будет смысл. На мой взгляд, текущее положение вещей создаёт какую-никакую но всё-таки потенциальная угрозу ошибки, вдруг в каком-нибудь месте системы нет соответствующей проверки в коде.
|
|
24.12.2010, 09:57 | #17 |
Участник
|
Есть метод, который вызывается всегда - display - можно этим воспользоваться
Создать контрол, к нему дисплейный метод, возращающий recid текущей записи, а также модифицирующий блокирование кнопки, плюс вывод label = false и размеры контрола = 0. "Лишний, технический" контрол практически не изменяет дизайн. ниже проект SharedProject_FormMenuItemButton.xpo |
|
|
За это сообщение автора поблагодарили: S.Kuskov (2). |
24.12.2010, 10:29 | #18 |
Модератор
|
Потому что проверка наличия буфера и его валидности традиционно выполняется в main или в конструкторе класса, вызываемого menuItemButton-ом
__________________
-ТСЯ или -ТЬСЯ ? |
|
24.12.2010, 11:02 | #19 |
Участник
|
Цитата:
Цитата:
titov, спасибо. Оно работает! |
|
24.12.2010, 11:31 | #20 |
Гость
|
Лишние контролы как-то уж совсем круто.
Я в подобных случаях запрещал отдельно лежащую на форме кнопку в executeQuery датасорса, а в active разрешал. Если пользователь наложил такой фильтр что нет записей, то executeQuery сработает, а active нет. |
|