|
![]() |
#1 |
Участник
|
Например, такой код работает верно:
X++: display UTCDateTime time() { return DateTimeUtil::getSystemDateTime(); }
__________________
Ivanhoe as is.. Последний раз редактировалось Ivanhoe; 19.05.2011 в 14:39. |
|
![]() |
#2 |
Участник
|
Да, этот Edt работает, но у него метка не та.
А вот стандартные другие ЕДТ? Я пробовал на ActivationDateTime он sys и на своем, отнаследованном от этого, от КреатедДайтТайм или без наследования. А вот UTCDateTime в качестве родителя у ЕДТ не ставится, и сотв получить счастье не выходит. Остается вариант все клнтрольки делать от UTCDateTime и называть их метками на самой форме. Но это изврат и баг. Так что, все еще прошу подтвердить поведение прочих не UTCDateTime ЕДТ в дисплей филдах на закладке формы. ЗЫ. А вообще не забавно, что на стартапе проекта с переходом на ах2009 время стало уходить в утиль (неоплачиваемое и овертаймовое) оч сильно - граблями устелен этот путь, там где их не было отродясь (настроил и полетел) - накидали пачками грабельки, усердно, добротно, что все плюсы новой системы (кроме маркетинговых и обязалово-сейлозых) меркнут. Из недавнего еще в ЖГК ОС\Строки\Групповые операции - кривые диалоговый формы с dialogField = new DialogField() вместо dialogField = dialog.addFieldValue Последний раз редактировалось BOAL; 19.05.2011 в 22:53. |
|
![]() |
#3 |
Участник
|
Цитата:
Цитата:
![]() ![]() |
|
![]() |
#4 |
Administrator
|
Цитата:
Т.е. я конечно понимаю, что каждый RUx содержит в себе пачку исправлений и улучшений, но это еще не означает что "чем дальше, тем стабильнее". По моему - так вообще в RU3 не было много такой "мелочевки", типа dialogField = new DialogField (вроде как - точно уже не скажу). Т.е. какие-то грабли явно прибавились после. Тот же RU7 конечно может и хорош - но зарплата к нему вот только только вышла - соответственно - при использовании (хотя бы частично) функционала из зарплаты - ставить RU7 до выхода зарплаты бессмысленно (при этом МС не утруждает себя хранить версии зарплаты на каждый RUx и норовит обновить слой после выпуска фиксов в XPO. Т.е. получается, что без залитого в usr-слой нужного XPO-шника приложение с зарплатным слоем не компилируется).
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#5 |
Участник
|
Цитата:
Сообщение от BOAL
![]() Да, этот Edt работает, но у него метка не та.
А вот стандартные другие ЕДТ? Я пробовал на ActivationDateTime он sys и на своем, отнаследованном от этого, от КреатедДайтТайм или без наследования. А вот UTCDateTime в качестве родителя у ЕДТ не ставится, и сотв получить счастье не выходит. Остается вариант все клнтрольки делать от UTCDateTime и называть их метками на самой форме. Но это изврат и баг. Так что, все еще прошу подтвердить поведение прочих не UTCDateTime ЕДТ в дисплей филдах на закладке формы. В морфиксе есть глюк. Если перетаскивать на форму методы с EDT типа UTCDateTime, то он создает контролы StringEdit, которые неправильно отображают эти методы. Просто, создавайте контролы на форме через Создать Control/UTCDateTimeEdit, а потом указывайте в нем датаметод и датасорс, если надо. Либо, указывайте изначально в методе возвращаемый тип UTCDateTime, создавайте метод драг&энд&дропом, а после этого меняйте возвращаемый тип в методе на нужный вам. Извращение, конечно, но пока не исправят - что делать? ![]()
__________________
Axapta v.3.0 sp5 kr2 |
|
|
За это сообщение автора поблагодарили: BOAL (3), sukhanchik (3), Logger (8), Ivanhoe (1), gl00mie (3), S.Kuskov (2). |
![]() |
#6 |
Участник
|
У нас эта форма появилась переносом и заменой из-за пропажи полей CreatedDate на таблицах.
Теперь ясно, как делать такие дисплей поля. Спасибо! gl00mie на РУ7 переход не планировали. От чего это спасет? Чтоб понять стоил ли связываться. Что лечит ядро, а что прил., то есть может просто накатить АОС и клиент и оставить прил. от Ру6? |
|
Теги |
ax2009, display метод, utcdatetime, дата, ошибка, фильтр, формат дат |
|
|