InventUpd_Reservation изменения в 2009

[ZVV]

Вот интересно, зачем в 2009 убрали из этого класса такие хорошие методы, как updReservOrdered() и updReservPhysical()?

Я конечно не гордый, могу и с ранних приложений скопировать, но интересна сама цель? Может подразумевалось извлечение этой информации каким-то другим способом?

[EVGL]

Про эти методы ничего не скажу, но в целом в этом классе стало меньше багов, чем в 4.0. Совсем недавно столкнулся с тем, что в заказе на продажу проводки в 4.0 оставались в статусе "Reserved ordered" несмотря на то, что "источник" (производственный заказ) был закрыт с недостачей. Импорт кода из 2009 помог программисту исправить проблему.

[ZVV]

ну упомянутые мною методы - это чисто методы отображния, на функционал они ни в коей мере не влияют...

[Maximin]

Жаль, что убрали.
Вообще-то говоря, удобно зарезервировать "хоть сколько-нибудь", а потом от полученного плясать.
Кол-во "хоть сколько нибудь" бывает нужно при разного рода подвозов (пополнении склада с транзитных/хранения), да и при от/резервировании одновременно "в заказанных" и в реальном наличии полезно бывает знать, сколько откуда взялось.
Про "меньше багов" в 4ке - скажу +1.

[ZVV]

Ну я их просто добавил назад... Всё вроде нормально...
По коду логика кажется не менялась в отношении этих переменных..

[Ievgenii]

Цитата:

Я конечно не гордый, могу и с ранних приложений скопировать, но интересна сама цель?

Эти методы были убраны ибо не было их использования в стандартной функциональности. (clean up of dead code in away)

[gl00mie]

Цитата:

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

Эти методы были убраны ибо не было их использования в стандартной функциональности. (clean up of dead code in away)

Вот это за-ши-бенская мотивировка! А то, что стандартная функциональность "иногда" допиливается, и допиленный код может при обновлении тупо перестать работать, потому что кое-что "ненужное" выкинули, - это пофиг? С таким же успехом можно было построить перекрестные ссылки по стандратному приложению и прибить все, что в них не попало - в стандартной функциональности не используется ведь...
Недавно узнал, что из 4-ки и последующих версий выкинули чудесный метод Global::callStack2Infolog(). Что ж, теперь есть хотя бы какое-то объяснение подобным действиям Мда, если раньше с проекта на проект таскали с собой исправления давно известных косяков стандартного функционала, то теперь еще будут таскать вполне себе рабочие куски, которые из стандартного приложения просто выкинули за "ненадобностью". Чем выкидывать из приложения якобы "мертвый" код, лучше бы новый фукнционал писали, чесслово...

[Ievgenii]

Цитата:

Вот это за-ши-бенская мотивировка! А то, что стандартная функциональность "иногда" допиливается, и допиленный код может при обновлении тупо перестать работать, потому что кое-что "ненужное" выкинули, - это пофиг?

Don't shoot the Messenger. К сожалению в Ax 5.0 не было возможным промаркировать код как не поддерживаемый в след. версиях (mark API as obsolete) и удалить метод через 2-3 версии, так как делают в .Net Framework например. Будем надееться что рано или поздно такая возможность появиться наподобие аттрибутов как MFP описал тут http://blogs.msdn.com/mfp/archive/20...rovements.aspx или что то похожее.

Цитата:

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

AFAIK размер всего кода Ax уменшился >10% и багов стало намного меньше. Пишем.

[belugin]

вот как надо вычищать dead code

[player]

А в классе CCADORecordset метод moveNext() ? Ведь без него и класс, становится не особо нужным...