|
25.01.2011, 22:07 | #1 |
Участник
|
это одна из идей, которую я хочу пропихнуть в АХ 2012.
**** выделено отсюда Используете ли вы @SYS метки при создании своих партнерских расширений? ****
Цитата:
Иван, было бы неплохо пропихнуть еще парочку : 1. В отладчике выходить из метода не по последней строчке, а по закрывающей скобке "}" - очень этого не хватает. Сейчас приходится иногда вставлять в конце метода вызов метода пустышки - неудобно. Тем более что в других продуктах MS, именно так и работает. (Например, когда отлаживаешь в Excel макрос на VBA) 2. Облегчить каким-нибудь способом поиск мест в коде, в которых меняются свойства контрола или датасорса или поля датасорса. Поясню подробнее. Иногда разбираешь чужие модифы, ошибки и происходит вызов ядреного метода, например xRecord.insert() или xRecord_ds.active() - чтобы найти кто и откуда гадит, достаточно поставить точку останова внутри метода, воткнуть туда, например, простенький if с проверкой на некорректные значения и точкой останова и таким образом быстро найти проблему. Если метод не перекрыт, то перекрыть его и добавить свой код с проверками. А вот со свойствами датасорсов и контролов такой номер не прокатит, так как их перекрывать нельзя. А иногда очень нужно. Например выяснить, из-за чего же все-таки дизейблится поле и т.п. Возможно, решать надо совсем по другому, не так как я описываю. Например, чтобы отладчик мог задавать условные точки останова, по значению переменной или по значению свойства объекта. - Но в любом случае это очень нужная вещь - могла бы сэкономить кучу времени. Проще всего по-моему дать возможность обрабатывать любое свойство как метод, перекрывая его в код X++. Или сделать что-то по аналогии с использованием \System Documentation\Classes\FormRun\controlMethodOverload т.е. сделать настройку в ядре, которая вызывала бы определенный программистом метод при изменении заданного свойства объекта. Т.е. нужно мне поймать кто дизейблит контрол Object, я вызываю FromRun.XXXcontrolMethodOverload("MyMethodName4Invoke", Object, "Object_PropertyName") и при изменении свойства PropertyName ядро дергает мой метод MyMethodName4Invoke() передавая в него Object, а я ставлю в своем методе MyMethodName4Invoke() точку останова и вижу стек вызовов и быстро нахожу проблему. Последний раз редактировалось Logger; 25.01.2011 в 22:19. |
|
|
За это сообщение автора поблагодарили: Pustik (1), S.Kuskov (3). |
25.01.2011, 22:32 | #2 |
Участник
|
Также отладчик не позволяет смотреть свойства объектов, а хотелось бы. Хотя это можно обойти программированием на X++ (например, перекрыть метод toString() в котором возвращать в строковом виде значения свойств), но как-то лениво...
|
|
26.01.2011, 13:27 | #3 |
Участник
|
мне кажется, что хотелки с отладчиком и со средой разработки лучше формулировать так:
хочу чтобы разработка велась в Visual Studio и все инструменты этой среды разработки работали бы с аксаптовским кодом. |
|
|
За это сообщение автора поблагодарили: player (1), Deepoint (1). |
26.01.2011, 13:41 | #4 |
Moderator
|
Цитата:
Боюсь что вместе с отладочно/программерскими феньками из VS, ты в нагрузку получишь жесткую "модель водопада", от которой не поздоровиться не только кодерам, но и консам, администраторам и тп... Хотя это офтопик для данной темы. |
|
|
За это сообщение автора поблагодарили: macklakov (2), aidsua (2), MikeR (3). |
26.01.2011, 13:44 | #5 |
Участник
|
Ох... ты прав...
но все равно - хочу одну среду для разработки всего. задолбался прыгать из одной в другую. |
|
26.01.2011, 13:48 | #6 |
Moderator
|
Цитата:
Давайте все таки формулировать пожелания правильно: "Хочу чтобы среда разработки была КАК в Visual Studio", а не "Хочу разрабатывать в Visual Studio" |
|
26.01.2011, 14:46 | #7 |
Участник
|
|
|
26.01.2011, 15:04 | #8 |
Moderator
|
VS навязывает жесткую модель билда.А в аксапте можно, во первых переносить изменения проектами (хотя это и не лучший в плане стабильности способ), во вторых - запросто можно вообще жить с некомпилируемыми классами, в стадии отладки. Конечно при условии, что их никакая фунцкиональность пока не вызывает.
|
|
26.01.2011, 17:59 | #9 |
Участник
|
Вот это как раз непринципиально. а то так они задумают очередного слона и его ждать до следующей пятилетки.
|
|
26.01.2011, 18:01 | #10 |
Участник
|
Кроме того небольшие изменения всегда проще пропихнуть, чем глобальные.
|
|
02.02.2011, 14:46 | #11 |
Участник
|
Как вы все должны понимать, мы уже на финальной стадии выпуска продукта, поэтому, помимо фиксов каких-то мелких багов и оптимизации производительности, я бы не стал ожидать больших изменений в редакторе в сравнении с тем, как он работает сейчас (недавно был блог пост с видео).
Раз уж все пишут про новые возможности системы, позволю и себе привести скриншот дебаггера. Ваше первое желание исполнено. Условные точки останова, к сожалению, не дождетесь |
|
|
За это сообщение автора поблагодарили: Logger (15), S.Kuskov (1). |
02.02.2011, 15:49 | #12 |
Участник
|
Цитата:
X++: return a + b - this.func(c) * 10; |
|
02.02.2011, 15:52 | #13 |
Участник
|
Такого не просили. Просили только, чтоб на закрывающей скобке останавливался
|
|
02.02.2011, 16:03 | #14 |
Участник
|
|
|
02.02.2011, 16:11 | #15 |
Участник
|
Цитата:
См. скриншот с ответом и на вопрос gl00mie |
|
19.05.2011, 16:06 | #16 |
Участник
|
Цитата:
Есть проблема - когда код написан на clicked() методе формы, то в стеке вызовов он отображается как (C)\Classes\FormButtonControl\Clicked что естественно неудобно, так как не дает понимания в какой же именно форме исполнялся код. Иногда приходится разбираться с чужим проблемным кодом, смотришь логи со стеками вызовов, а они как дразнят! Вроде и стек вызовов есть, но фиг поймешь откуда же эта гадость лезет. (В случае если код исполняется в методе формы, класса или таблички, то все нормально - мы можем в стеке вызовов определить объект на котором сидит метод) Или может запретить писать код в Clicked() методах кнопок ... |
|
19.05.2011, 16:31 | #17 |
Участник
|
Цитата:
Сообщение от Logger
Не смотря на это можно пропихнуть еще одну хотелку ?
Есть проблема - когда код написан на clicked() методе формы, то в стеке вызовов он отображается как (C)\Classes\FormButtonControl\Clicked что естественно неудобно, так как не дает понимания в какой же именно форме исполнялся код. Иногда приходится разбираться с чужим проблемным кодом, смотришь логи со стеками вызовов, а они как дразнят! Вроде и стек вызовов есть, но фиг поймешь откуда же эта гадость лезет. (В случае если код исполняется в методе формы, класса или таблички, то все нормально - мы можем в стеке вызовов определить объект на котором сидит метод) Или может запретить писать код в Clicked() методах кнопок ... |
|
|
За это сообщение автора поблагодарили: Logger (5). |
02.02.2011, 15:23 | #18 |
Участник
|
Иван, да нам не обязательно видеть это конкретно в 2012-й. Главное чтобы сделали. Если честно я не особо и надеялся. Так что приятная неожиданность сегодня случилась
А с условными точками останова не дождемся в конкретной версии или в принципе такого не будет? На самом деле на них свет клином не сошелся. Хотелось просто иметь какой нить инструмент быстрого нахождения тех мест в коде из которых меняются свойства контролов и датасорса на конкретной форме. Это же все позволит удешевить поддержку и сопровождение системы. |
|
02.02.2011, 15:33 | #19 |
Участник
|
Цитата:
Сообщение от Logger
Иван, да нам не обязательно видеть это конкретно в 2012-й. Главное чтобы сделали. Если честно я не особо и надеялся. Так что приятная неожиданность сегодня случилась
А с условными точками останова не дождемся в конкретной версии или в принципе такого не будет? На самом деле на них свет клином не сошелся. Хотелось просто иметь какой нить инструмент быстрого нахождения тех мест в коде из которых меняются свойства контролов и датасорса на конкретной форме. Это же все позволит удешевить поддержку и сопровождение системы. А механизм, который, возможно (я не разбирался, как с ним работать), позволяет отслеживать такие вещи, сделали - events & event handlers добавили. И, если я правильно понимаю, теперь можно подписаться будет на многие из стандартных событий, и делегировать исполнение какому-то своему коду. В нем можно поставить точку останова, которая вызовется в случае, если произошло это событие. Хотя, опять же, я не уверен, как именно это работает и насколько широки возможности, и в том, что таким образом можно будет добиться требуемого результата. |
|
02.02.2011, 19:47 | #20 |
Участник
|
Именно что! а то надоедает везде, где можно, сперва присваивать возвращаемое значение локальной переменной и потом уже эту переменную возвращать. В случае со "сложносочиненными" объектами это еще и к тормозам может приводить из-за изменения числа ссылок и необходимости обработки этого дела. В Visual Studio вся прелесть останова на закрывающей скобке и состоит в том, что можно посмотреть возвращаемое значение независимо от того, возвращается ли переменная или какое-то выражение. По идее для X++ это должно быть относительно просто реализовать, ведь там возвращаемое значение вычисляется и кладется на вершину стека, откуда его потом берет вызывающий код...
PS. Но если на закрывающей скобке можно будет хотя бы точку останова поставить и ловить ее независимо от числа return'ов в теле метода, то это тоже неплохо. |
|
Теги |
button, clicked, stack trace, stack trace clicked, кнопка, стек вызовов |
|
|