jwikman / nab-al-tools

The code repository for NAB AL Tools, an AL tool for VS Code
https://marketplace.visualstudio.com/items?itemName=nabsolutions.nab-al-tools
MIT License
19 stars 7 forks source link

Update g.xlf failed with error: Could not parse Option.... as a valid data type. #457

Closed plkonsult closed 7 months ago

plkonsult commented 7 months ago

Describe the bug See Title...!

Versions used VSCode: 1.87.2 NAB AL Tools: 1.33.402290847

To Reproduce Steps to reproduce the behavior:

  1. From Visual Studio Code press CTRL+SHIFT+P
  2. Chose NAB: Update g.xlf
  3. I get the error (everytime)

I am working on an extension for Business Central, Base Application 23.0.12034.12841. In this version you can still use Option fields.

plkonsult commented 7 months ago

Two days later this works again - event though I have not worked on the code since then. Put this in hold, and I will return if a similar error occurs....

jwikman commented 7 months ago

Hi, I've been on vacation with the family, so haven't had the time to look into this. But it seems as if you've solved this, without my help. :)

The extension does indeed support Options, but it is done with custom parsing of the al code (not symbols as some others). The advantage of that is that it works without symbols, and you do not need to be able to compile the app to work with the translations. The downside is that sometimes the code is written in a way that the parser does not understand... So to be able to add support for a new format of some code, we would need to have a sample of code to look into.

After looking into the code, I could only repro this by adding a field to a table as this:

        field(10000; Test; Option.......)
        {
            Caption= 'Test';
        }

Error:

[22:43:42] Running: Update g.xlf
[22:43:43] Error: Could not parse Option....... as a valid data type.

But I do not understand why you would have that in your code 😅

Anyway, I'm glad that it got solved by itself. But if it happens again, try to figure out which line of AL code that is causing this (by removing code until object is identified) and we could probably find a solution!

plkonsult commented 7 months ago

Hi Johannes,

And thanks for your swift reply….

But I ran into the error message again – but I also found out, what caused it. See below – here is the ‘Option….’ Text, that causes the error. ‘Funny’ thing, though, is that the text is out-commented and the code not active – but still NAB fails. I have now removed the dots (….) from text, and everything is working again….

/Lars

@.***

Kind regards

Peder Lars Knudsen +45 6074 0575 @.**@.>

[Logo 1]

Fra: Johannes Wikman @.> Sendt: 7. april 2024 22:53 Til: jwikman/nab-al-tools @.> Cc: Peder Lars Knudsen @.>; State change @.> Emne: Re: [jwikman/nab-al-tools] Update g.xlf failed with error: Could not parse Option.... as a valid data type. (Issue #457)

Hi, I've been on vacation with the family, so haven't had the time to look into this. But it seems as if you've solved this, without my help. :)

The extension does indeed support Options, but it is done with custom parsing of the al code (not symbols as some others). The advantage of that is that it works without symbols, and you do not need to be able to compile the app to work with the translations. The downside is that sometimes the code is written in a way that the parser does not understand... So to be able to add support for a new format of some code, we would need to have a sample of code to look into.

After looking into the code, I could only repro this by adding a field to a table as this:

    field(10000; Test; Option.......)

    {

        Caption= 'Test';

    }

Error:

[22:43:42] Running: Update g.xlf

[22:43:43] Error: Could not parse Option....... as a valid data type.

But I do not understand why you would have that in your code 😅

Anyway, I'm glad that it got solved by itself. But if it happens again, try to figure out which line of AL code that is causing this (by removing code until object is identified) and we could probably find a solution!

— Reply to this email directly, view it on GitHubhttps://github.com/jwikman/nab-al-tools/issues/457#issuecomment-2041605962, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDITOKLFYKDM73MFN5VT23Y4GW2XAVCNFSM6AAAAABFX2MNSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGYYDKOJWGI. You are receiving this because you modified the open/close state.Message ID: @.**@.>>

jwikman commented 7 months ago

Hi Johannes, And thanks for your swift reply…. But I ran into the error message again – but I also found out, what caused it. See below

Hi Lars,

I cannot see attachments when reply is sent by email.

But from your text, and from a known limitation in NAB AL Tools, I can guess that you have this Option value in a block comment like this:

        /**
        field(10000; Test; Option.......)
        {
            Caption= 'Test';
        }
        **/

Is that the case?

At our company (and many other as well, I heard) we've banned those block comments for a very long time, so I have not spent any time to detect these. In AL a block comment is faster done by marking the code and pressing Ctrl+', so I do not see that we will spend time on the old /** **/ style of block commenting.

I hope that explains the odd behavior. 🙂

plkonsult commented 7 months ago

Hi Johannes,

Yes, you are correct – I have used the ‘old’ / and /. So, for me, yet another reason to use the new marking full scale 😊

Once again – thanks…. Lars

Fra: Johannes Wikman @.> Sendt: 8. april 2024 09:18 Til: jwikman/nab-al-tools @.> Cc: Peder Lars Knudsen @.>; State change @.> Emne: Re: [jwikman/nab-al-tools] Update g.xlf failed with error: Could not parse Option.... as a valid data type. (Issue #457)

Hi Johannes, And thanks for your swift reply…. But I ran into the error message again – but I also found out, what caused it. See below

Hi Lars,

I cannot see attachments when reply is sent by email.

But from your text, and from a known limitation in NAB AL Tools, I can guess that you have this Option value in a block comment like this:

    /**

    field(10000; Test; Option.......)

    {

        Caption= 'Test';

    }

    **/

Is that the case?

At our company (and many other as well, I heard) we've banned those block comments for a very long time, so I have not spent any time to detect these. In AL a block comment is faster done by marking the code and pressing Ctrl+', so I do not see that we will spend time on the old / / style of block commenting.

I hope that explains the odd behavior. 🙂

— Reply to this email directly, view it on GitHubhttps://github.com/jwikman/nab-al-tools/issues/457#issuecomment-2042027172, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDITOM5EY73YHGAA3AOUJ3Y4JABTAVCNFSM6AAAAABFX2MNSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSGAZDOMJXGI. You are receiving this because you modified the open/close state.Message ID: @.**@.>>

jwikman commented 7 months ago

Perfect, then this is a "closed case" :)