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.
