22.09.2011, 12:44 | #1 |
Участник
|
Сюрприз Edit-метода AX2009 RU5
Началось все с того, что при переходе с Axapta 3.0 на AX2009 заметили такую хрень. У нас есть форма, на ней по кнопочке вызывался отчет на несколько листов. Вот тут первый сюрприз: кнопочки прокрутки листов вниз активны, а прокрутки вверх нет.Т.е. опустился вниз отчета и вверх на первую страницу уже не подняться. После долгих и продолжительных поисков причин такого чуда обнаружили, что беда в edit-методе, который был на гриде. Поскольку в этом методе, много всего было написано кем-то до нас, разбираться не стали. Просто удалили его из грида. Буквально недавно, всплыло, что не работает кнопка, в которой просто тупо на методе clicked() висит info('бла-бла-бла'). И опять edit-метод на гриде.
Выяснилось, что в edit-методах пробовали управлять(в зависимости от условий) контролами грида, на котором эти edit-методы и висят. Попробуйте в форме InventTable на InventTable_ds создать метод X++: edit ItemName editItemId(boolean _set,InventTable _data, ItemName _val) { ItemName _ret = _val; InventTable_NameAlias.enabled(false); return _ret; } X++: void clicked() { super(); info('test'); } Открываешь форму с записями, жмешь кнопку и ни фига. Закрываешь форму выскакивает инфо. Плюс если открыть, например, форму в наличии, при условии, что она собой закрыла кнопки на форме InventTable, то после ее закрытия кнопки пропадают.Появятся, если дернуть форму InventTable(подправить ширину,высоту).А если формы MDI, то там вообще крыша у формы InventTable едет (например,кнопочка удаление записи после закрытия формы в наличии навсегда становится не активной). Я, конечно, понимаю, что управлять контролами в edit-методах может и не совсем правильно, но причем тут кнопки, метод clicked() и т.д., если управляли только контролом InventTable_NameAlias?.Кстати кнопочки прокрутки вверх на отчете(о чем я говорил выше) тоже появлялись после закрытия формы..
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. Последний раз редактировалось Pustik; 22.09.2011 в 13:04. |
|
|
За это сообщение автора поблагодарили: S.Kuskov (3). |
22.09.2011, 13:47 | #2 |
Участник
|
Цитата:
X++: edit ItemName editItemId(boolean _set,InventTable _data, ItemName _val) { ItemName _ret = _val; ; if (_set) { InventTable_NameAlias.enabled(false); } return _ret; } Последний раз редактировалось S.Kuskov; 22.09.2011 в 14:08. |
|
22.09.2011, 14:10 | #3 |
Участник
|
Цитата:
Сообщение от S.Kuskov
А условие, при котором происходит управление контролами, содержит проверку на то, что edit-метод вызван для изменения значения, а не для отображения?
X++: edit ItemName editItemId(boolean _set,InventTable _data, ItemName _val) { ItemName _ret = _val; ; if (set) { InventTable_NameAlias.enabled(false); } return _ret; } X++: edit ItemName editItemId(boolean _set,InventTable _data, ItemName _val) { ItemName _ret = _val; if (_data.ItemName) InventTable_NameAlias.enabled(false); else InventTable_NameAlias.enabled(true); return _ret; }
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. Последний раз редактировалось Pustik; 22.09.2011 в 14:19. |
|
22.09.2011, 14:31 | #4 |
Участник
|
Видимо что-то вроде этого хотели сделать?
Заблокировать menuItemButton если запись не выбрана |
|
22.09.2011, 20:37 | #5 |
Участник
|
Цитата:
Сообщение от S.Kuskov
Видимо что-то вроде этого хотели сделать?
Заблокировать menuItemButton если запись не выбрана Если вернутся к проблеме, то я хотел услышать мнение опытных людей именно по этому вопросу? Это баг или что? Я в этом методе затронул только определенный контрол и у меня повалились баги: 1) в отчете (пролистать вверх отчет нельзя) - обалдеть, причем тут контрол на гриде и кнопочки прокрутки вверх? 2)работа обычной кнопки с перекрытым методом clicked(). 3)если у вас 2 грида, и между ними splitter (как в SalesTable) периодически кнопки будут исчезать, пока не дернешь форму. А если форма MDI, то вообще полна горница сюрпризов. Еще раз скажу,что хочу разобраться, потому что такое может быть во многих формах, где побывали предыдущие программисты, и может быть от этого зависит какой нибудь алгоритм, к которому привыкли пользователи. P.S. Ну, а что скажет купечество? "12 стульев"
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
22.09.2011, 20:48 | #6 |
----------------
|
а стандартные "танцы с бубном" (реиндексация приложения, глобальная компиляция) не помогают?
|
|
22.09.2011, 20:52 | #7 |
Участник
|
Цитата:
Есть еще такое подозрение, что edit-метод работает так же как display, и из за этого беда, потому что при открытии формы грид моргает.
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
22.09.2011, 21:09 | #8 |
Участник
|
Цитата:
Сообщение от Pustik
в зависимости от того заполнено оно или нет, управляли контролом. Что-то типа :
X++: edit ItemName editItemId(boolean _set,InventTable _data, ItemName _val) { ItemName _ret = _val; if (_data.ItemName) InventTable_NameAlias.enabled(false); else InventTable_NameAlias.enabled(true); return _ret; } Цитата:
Цитата:
PS. Заметьте, что управление доступностью bound-контрола либо табличного поля влияет на все записи в гриде (хотя в каждый момент активна лишь одна), в то время как display-edit-методы на гриде работают с каждой записью по отдельности. Допустим, в записях на гриде через одну то заполнено ItemName, то пусто. Тогда при отрисовке поля для первой записи приведенный edit-метод отключит доступность NameAlias (для всех записей на гриде), для второй - снова включит (для всех), для третей - опять выключит и т.д. И так форма будет дергаться, будто в конвульсиях, пока ее не закроешь (эффект может проявляться в большей или в меньшей степени в зависимости от производительности клиентской машины). Последний раз редактировалось gl00mie; 22.09.2011 в 21:18. Причина: PS |
|
|
За это сообщение автора поблагодарили: Pustik (3), lev (3). |
22.09.2011, 21:21 | #9 |
Участник
|
gl00mie, класс, спасибо за информацию.
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
22.09.2011, 21:26 | #10 |
Участник
|
Осталось выяснить по поводу исчезновения кнопок?
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
22.09.2011, 21:34 | #11 |
Участник
|
Может, просто глюки перерисовки? IntelliMorph захлебывается в попытках пересчитать/перерисовать дизайн формы несско десятков/сотен раз в секунду? Я бы в любом случае убрал такой код из display-edit-методов - если и тогда кнопки будут пропадать, то уже можно более детально разбираться, а пока получается как в анектоде: "...а вы так не делайте"
Что касается приведенной ссылки, где рекомендовали управлять доступностью кнопок в display-методе (мол, работает независимо от того, выбралась запись или нет), хочу заметить, что решается все, по-моему, проще: делается метод, управляющий доступностью всех связанных с записью кнопок, и этот метод дергается из active() - безусловно и из executeQuery() после super() - по условию, что курсор, связанный с DS, пуст (в этом случае active не отработает). И никакого мельтешения display-методов... |
|
22.09.2011, 21:35 | #12 |
Участник
|
Цитата:
Сообщение от gl00mie
Тогда при отрисовке поля для первой записи приведенный edit-метод отключит доступность NameAlias (для всех записей на гриде), для второй - снова включит (для всех), для третей - опять выключит и т.д. И так форма будет дергаться, будто в конвульсиях, пока ее не закроешь (эффект может проявляться в большей или в меньшей степени в зависимости от производительности клиентской машины).
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
22.09.2011, 21:38 | #13 |
Участник
|
Убрали однозначно, просто не знали в чем причина. Думал не много по другому.
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
|
|