глючный UTCdatetime или руки кривые?

[gl00mie]

Цитата:

Сообщение от BOAL

А вот UTCDateTime в качестве родителя у ЕДТ не ставится, и сотв получить счастье не выходит.

По-моему, UtcDateTime - это базовый тип, как Date или Int, а не расширенный, поэтому от него и нельзя ничего "наследовать".

Цитата:

Сообщение от BOAL

А вообще не забавно, что на стартапе проекта с переходом на ах2009 время стало уходить в утиль (неоплачиваемое и овертаймовое) оч сильно - граблями устелен этот путь, там где их не было отродясь (настроил и полетел)

Ууу, то ли еще будет!.. Но вы же на RU7 переходите? Тогда от кучи граблей вы уже избавлены - что в приложении, что в ядре. А на счет настроил и полетел - это когда такое было? Я, наверно, что-то пропустил

[sukhanchik]

Цитата:

Сообщение от gl00mie

Но вы же на RU7 переходите? Тогда от кучи граблей вы уже избавлены - что в приложении, что в ядре.

Ээээ этот вопрос был задан в тоне иронии или на полном серьезе? В плане "многих фиксов в RU7" ?
Т.е. я конечно понимаю, что каждый RUx содержит в себе пачку исправлений и улучшений, но это еще не означает что "чем дальше, тем стабильнее". По моему - так вообще в RU3 не было много такой "мелочевки", типа dialogField = new DialogField (вроде как - точно уже не скажу). Т.е. какие-то грабли явно прибавились после.

Тот же RU7 конечно может и хорош - но зарплата к нему вот только только вышла - соответственно - при использовании (хотя бы частично) функционала из зарплаты - ставить RU7 до выхода зарплаты бессмысленно (при этом МС не утруждает себя хранить версии зарплаты на каждый RUx и норовит обновить слой после выпуска фиксов в XPO. Т.е. получается, что без залитого в usr-слой нужного XPO-шника приложение с зарплатным слоем не компилируется).