2

I have the following class:

public class MyDialogSelect extends RunBase
{
    private DialogField nameField;

    // Snipped for brevity

    public Object dialog()
    {
        Dialog dialog = super();
        nameField = dialog.addField(extendedTypeStr(CustName));
        // Snipped for brevity
        return dialog;
    }

    public void dialogSelectCtrl()
    {
        CustTable customerTable = CustTable::find(accountField.value());
        nameField.value(customerTable.name());
        // Snipped for brevity
    }
}

This compiles and works as expected.

However, I prefer using the keyword this to indicate when variables belong to the instance, so I try changing it this to:

public class MyDialogSelect extends RunBase
{
    private DialogField nameField;

    // Snipped for brevity

    public Object dialog()
    {
        Dialog dialog = super();
        this.nameField = dialog.addField(extendedTypeStr(CustName));
        // Snipped for brevity
        return dialog;
    }

    public void dialogSelectCtrl()
    {
        CustTable customerTable = CustTable::find(accountField.value());
        this.nameField.value(customerTable.name());
        // Snipped for brevity
    }
}

But, this won't compile, instead resulting in Invalid token '('.. However, if I remove this before nameField.value(customerTable.name());, it works as expected again. (Note: I still indicate this in this.nameField = dialog.addField(extendedTypeStr(CustName));).

Why won't it compile when I include this before a property which invokes a method? I've also observed this with this.nameField.enabled(false) also failing. Is there a more general rule or principle I should understand here about when x++ allows, disallows, or requires this?

FH-Inway
  • 4,432
  • 1
  • 20
  • 37
Brian Kessler
  • 2,187
  • 6
  • 28
  • 58
  • 3
    Not an answer, but an educated guess: legacy reasons. If you take a look at https://learn.microsoft.com/en-us/dynamicsax-2012/developer/the-this-object, it states "[this] Cannot be used to qualify the names of member variables that are declared in the classDeclaration code.". While this is for the previous version AX 2012 and not the case in D365FO any more (as your `dialog` method shows), I would guess that a function call like in the `dialogSelectCtrl` method is not supported. For x++, it is unsual to refer to member variables in such a way. – FH-Inway Jun 24 '21 at 21:04
  • I don't know why `this` is so underused on most platforms -- if it were up to me, I'd make it mandatory everywhere. You might be onto something, but in fact I can use `this` to qualify names of the variables (e.g. `this.nameField = ...`, just not when calling methods on those variables. – Brian Kessler Jun 25 '21 at 08:12
  • 1
    This could just be a compiler bug. Syntax-wise it should be correct. – avolkmann Jul 01 '21 at 09:29

2 Answers2

1

You cannot use this to reference instance variables in X++. Like in C++.

You can (and must) use this to refer to instance methods.

Jan B. Kjeldsen
  • 17,817
  • 5
  • 32
  • 50
0

This refers to the context of the development, in your example, this refers to the class as a whole. Of you add another method, you would call that method using this.

With latest form pattern changes, I believe the MSFT recommendation is to use dialog form pattern instead of class to generate dialog.

  • cheers for the response. `this` is common in OOP languages and (aside from JavaScript), I believe its use is generally the same in _most_. As @avolkmann suggested above, syntax-wise, my usage seems correct, but it may be a compiler bug (TBC). I've noticed while going through the cookbook, most of the material on forms seems unworkable, possibly related to the "recommendation" you allude to. Can you please suggest any good resource to learn about the dialog form pattern? – Brian Kessler Jul 03 '21 at 21:09
  • I 'm interested in the MSFT recommendation you mention, as it is the first time I'm hearing of this. Where did you hear or read this recommendation? – FH-Inway Jul 05 '21 at 13:53
  • @BrianKessler: There is [Dialog form pattern](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/user-interface/dialog-form-pattern) as a possible documentation. It describes when dialogs should be used and how they should look like. As far as I know, you can create dialogs in code in simple cases when creating a dialog form would be overkill. If you create a dialog form, it should follow the described form pattern. – FH-Inway Jul 05 '21 at 13:55