это одна из идей, которую я хочу пропихнуть в АХ 2012.

[gl00mie]

Именно что! а то надоедает везде, где можно, сперва присваивать возвращаемое значение локальной переменной и потом уже эту переменную возвращать. В случае со "сложносочиненными" объектами это еще и к тормозам может приводить из-за изменения числа ссылок и необходимости обработки этого дела. В Visual Studio вся прелесть останова на закрывающей скобке и состоит в том, что можно посмотреть возвращаемое значение независимо от того, возвращается ли переменная или какое-то выражение. По идее для X++ это должно быть относительно просто реализовать, ведь там возвращаемое значение вычисляется и кладется на вершину стека, откуда его потом берет вызывающий код...

PS. Но если на закрывающей скобке можно будет хотя бы точку останова поставить и ловить ее независимо от числа return'ов в теле метода, то это тоже неплохо.

[Logger]

Цитата:

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

Как вы все должны понимать, мы уже на финальной стадии выпуска продукта...

Не смотря на это можно пропихнуть еще одну хотелку ?

Есть проблема - когда код написан на clicked() методе формы, то в стеке вызовов он отображается как
(C)\Classes\FormButtonControl\Clicked
что естественно неудобно, так как не дает понимания в какой же именно форме исполнялся код. Иногда приходится разбираться с чужим проблемным кодом, смотришь логи со стеками вызовов, а они как дразнят!
Вроде и стек вызовов есть, но фиг поймешь откуда же эта гадость лезет. (В случае если код исполняется в методе формы, класса или таблички, то все нормально - мы можем в стеке вызовов определить объект на котором сидит метод)

Или может запретить писать код в Clicked() методах кнопок ...

[kashperuk]

Цитата:

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

Не смотря на это можно пропихнуть еще одну хотелку ?

Есть проблема - когда код написан на clicked() методе формы, то в стеке вызовов он отображается как
(C)\Classes\FormButtonControl\Clicked
что естественно неудобно, так как не дает понимания в какой же именно форме исполнялся код. Иногда приходится разбираться с чужим проблемным кодом, смотришь логи со стеками вызовов, а они как дразнят!
Вроде и стек вызовов есть, но фиг поймешь откуда же эта гадость лезет. (В случае если код исполняется в методе формы, класса или таблички, то все нормально - мы можем в стеке вызовов определить объект на котором сидит метод)

Или может запретить писать код в Clicked() методах кнопок ...

Я то конечно могу создать, но это не баг. У нас это называется Design Change Request (DCR), а их мы уже давно не делаем для этого релиза. Так что только уже в АХ7, если согласятся чинить.

[Logger]

Ну хотя бы так.
Я думаю мы и на ax6 нескоро перейдем. Так что особой разницы нет в каком именно релизе согласятся это править.

[Poleax]

редирект ХОТЕЛКИ можно регистрировать на connect

[Logger]

Оказывается можно достичь поставленной задачи не трогая ядро.
Когда кнопка получается фокус то дергается метод
\Classes\SysSetupFormRun\selectControl

Можно в нем запоминать имя формы и имя контрола кнопки.
Затем при работе
Application.logInsert
Application.logUpdate
Application.logDelete

анализировать стек вызовов и если он начинается со строки
@"(C)\Classes\FormButtonControl\Clicked"
то доставать запомненные имя формы и контрола и прописывать их куда нам надо, например подменять в стеке вызовов строку
@"(C)\Classes\FormButtonControl\Clicked"
на
@"\Forms\ИмяФормы\...\ИмяКонтрола\Clicked"

Попробовал - работает.

[Logger]

Но это несколько кривенько. Лучше конечно ядро пофиксить. А то получается некоторая непоследовательность. Если метод живет на форме/классе/таблице то он в стеке вызовов виден, как и содержащий его объект - форма/класс/таблица а если он на кнопке, то ни форма ни кнопка не видны. Дискриминация.