X++ normálně nerozlišuje velikost písmen – můžete zavolat warning(“x”) nebo WaRnInG(“x”) a oboje udělá to samé (ačkoli vaši kolegové nemusí být tak benevolentní jako kompilátor X++). Nicméně to samé naplatí pro .NET Interop z X++ – můžete sice použít například System.Math::Cos(0), ale pokud zkusíte zavolat System.Math::cos(0), dostanete kompilační chybu.

Existují dokonce případy, kdy změna velikosti písma zapříčiní volání jiné metody. Podívejte se na následující kus kódu – způsobí .NET výjimku, odchytne ji, převede na řetězec a odešle do infologu:

try
{
    System.IO.File::Open('neexistující soubor', System.IO.FileMode::Open);
}
catch (Exception::CLRError)
{
    error(CLRInterop::getLastException().ToString());
}

Výstup by měl být něco jako: “System.Reflection.TargetInvocationException: Exception has been thrown by the target of invocation. —> System.IO.FileNotFoundException: Could not find file ‘C:\Windows\system32\neexistující soubor.’ (…)” (Poznámka: nevím, co přesně dostanete v systému s češtinou.)

Nyní změňte ToString() na tostring(). Výstup bude “Class CLRObject”.

Co se stalo? To, co dostaneme z CLRInterop::getLastException() je instance (X++) třídy CLRObject, která reprezentuje .NET objekt (v tomto případě FileNotFoundException). Když zavoláme metodu ToString(), AX rozpozná, že FileNotFoundException takovou metodu obsahuje a zavolá ji. Ale pokud zavoláte tostring(), AX nemůže použít metodu na FileNotFoundException kvůli různé velikosti písmen. Ale je zde metoda toString() na samotné třídě CLRObject (zděděná z třídy Object), která může být zavolána bez potíží. Tudíž zde nejde o jednu metodu vracející různé výsledky, jsou to metody na úplně jiných objektech.

Můžete to být trochu matoucí, ale dává to smysl.