Отладка в AL раньше была для меня катастрофой

Меня всегда раздражало то, как устроен AL (язык приложений) и как система, основанная на событиях, ужасно усложняет отладку и трассировку вашей программы. Тем не менее, даже несмотря на то, что базовая система имеет некоторые неоспоримые недостатки, наши боги сверху (Майкрософт) сделали все возможное, чтобы извлечь из нее максимальную пользу, предоставив нам доступ ко всему набору методов отладки, некоторые из которых вы, возможно, не знаете. в курсе.

Контрольные точки

Я уверен, что все и их бабушки слышали о точках останова и постоянно используют их в своей повседневной рутине программирования AL. Это инструмент в коде Visual Studio, который позволяет вам установить красную точку на определенной строке, заставляя сервер BC остановить выполнение кода и позволяя вам проверять окружающий контекст.

На панели отладки (в левой части кода Visual Studio) вы также можете проверять глобальные и локальные переменные.

В зависимости от ваших предпочтений вас также может раздражать то, что отладчик прерывается при ошибках и/или при изменении записей. Чтобы включить/отключить это поведение, вы можете изменить свой профиль запуска, найденный в .vscode/launch.json.

{
    "configurations": [
      {
        "breakOnError": true,
        "breakOnRecordWrite": true
      }
    ]
}

Регистратор событий

Один из самых больших вопросов, который у меня всегда возникал при отладке с точками останова, был: «Что вызвало вызов SomeFunctionA?». В случае обычных процедур ответ можно быстро найти, нажав ctrl + f в рамках проекта на запрос SomeFunctionA\(

Однако в случае событий (что является обычным явлением, поскольку AL является языком программирования, основанным на событиях). Ответить на этот вопрос часто гораздо труднее. Какие события называются когда? и на что мне подписаться? как называется порядок событий?

Однако недавно я нашел очень хороший способ отладить это: встроенную «запись событий». Это инструмент, который используется в веб-приложении Business Central и может быть открыт путем поиска страницы Event Recorder. Когда вы откроете его, вам будет представлено что-то вроде этого:

Когда вы нажмете Record Events > Start, BC начнет отслеживать любое пользовательское или триггерное событие, которое активируется. убедитесь, что вы не закрываете страницу регистратора событий, а открываете новые страницы, выполнив поиск с помощью окна поиска, иначе запись будет отменена.

Затем вы можете выполнить все действия, которые хотите проверить, а затем нажать Record Events > Stop, чтобы остановить запись и отобразить список активированных пользовательских/триггерных событий.

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

Это дает вам хороший обзор того, какие события запускаются, однако, что, если вы хотите подписать функцию на одно из событий, которые вы нашли с помощью отладчика событий? Вы можете очень легко прокручивать вправо от таблицы регистратора событий, пока не найдете столбец Get AL Snippet, где вы можете щелкнуть ссылку, чтобы получить автоматически сгенерированный код.

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

Стек вызовов

Он немного более известен, чем регистратор событий BC, но все же заслуживает большой любви. Это инструмент внутри отладчика VSCode AL, как и инспектор локальных/глобальных переменных. Он появляется, когда вы застряли на точке останова, и выглядит так:

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

Но что, если вы хотите узнать, из какого места была вызвана текущая функция? может быть, он вызывается только в каком-то условии, или, может быть, он вызывается из какой-то привязки к событию.

Самый интуитивный способ выяснить это — расставить точки останова во всех местах, где вызывается текущая функция, однако есть гораздо более эффективный способ:

Стек вызовов можно использовать именно для этой цели, посмотреть, из какой функции была вызвана текущая функция. На изображении выше вы можете видеть, что текущая функция с именем Code была вызвана из функции PostSplitJnlLine, которая, в свою очередь, была вызвана из RunWithCheck. Вы также можете дважды щелкнуть эти строки, чтобы перейти непосредственно к вызову этой функции.

Часы

Другой сценарий отладки — когда вы хотите отслеживать значение переменной при переходе через точки останова. Возможно, у вас есть целочисленное значение с именем MyNumber, которое увеличивается в разных местах кода, и вы хотите знать, как MyNumber становится определенным значением.

Вместо того, чтобы прокручивать вниз к разделу переменных модуля кода, чтобы навести указатель мыши на переменную для ее проверки, вы можете попробовать добавить ее в список Watch в отладчике. Всякий раз, когда вы добавляете сюда переменную, она будет отображаться вместе со своим значением во время сеанса отладки.

Таким образом, он всегда будет виден на вашем экране, и вам не нужно спамить свой код с помощью Message(Format(MyNumber));.

Удачи в отладке

Это конец статьи. Надеюсь, я научил вас хотя бы одному полезному способу отладки, о возможности которого вы не знали. Возможно, я даже помог вам избежать многочасовой отладки.

Максимально используйте эти функции и получайте удовольствие от отладки кода!