Vor der Verwendung von führenden Ziffern im Namen wurde früher gewarnt da das unter Umständen dazu geführt hat, das eine führende Zahl als ISE_ID interpretiert wurde.
Auch jetzt noch kann es zu Problemen führen, aber meines Erachtens ist das früher noch schlimmer gewesen da schon eine führende Zahl eventuell falsch interpretiert wurde.
Wie ist es denn jetzt? Nehmen wir mal ein kleines Beispiel:
- du legst eine Gewerk mit dem Namen 950 an.
- In einem Script versuchst du jetzt auch das Gewerk zuzugreifen
Code: Alles auswählen
object test1 = dom.GetObject("950");
WriteLine(test1.Name());
- In 79% der Fälle wird auf jeder CCU dann "Anwesenheit" ausgegeben.
Dann gäbe es noch 10% welche bei denen "CCU im Reboot" oder irgendetwas ausgegeben wird, was auf die Verwendung der Systemvariablen als Boottrigger deutet, bei anderen wird vielleicht auch "${sysVarPresence}" ausgegeben, die sind dann von einem anderen immer noch vorhandenen Bug betroffen.
Allen gemeinsam: es wird aber nicht "950" ausgegeben, denn das wäre ja der Name des gerade angelegten Gewerkes.
(Bewusst habe ich 1% offen gelassen, weil es theoretisch vielleicht sein kann, das bei jemanden das Gewerk 950 eine ISE_ID < 950 verwendet wird, obwohl das glaube verhindert wird.) die würden dann aber etwas ganz anderes ausgegeben bekommen, wie man vielleicht erwartet:
Wir haben ja alle durch BadenPower vor Augen gehalten bekommen, das es sicherer ist auf ein Gewerk zuzugreifen in dem man
eben nicht dom.GetObject(); benutzt sondern ein Vorselektierung wie für das gerade angelegte Beispielgewerk
Code: Alles auswählen
object test2 = (dom.GetObject(ID_FUNCTIONS)).Get("950");
WriteLine(test2);
die Ausgabe ist aber auch hier nicht "950" wie für andere Gewerke gelten würde, sondern null
Dann könnte man noch weiter testen.
- Man benennt das Gewerk 950 um in einen Namen wie z.B. Testgewerk.
- Man denkt sich, nehmen wir einen Favoriten -
- also flugs einen Favoriten angelegt mit Namen 950 - upps geht nicht, da wird 950 1 draus.
Wieso, hat EQ-3 endlich mal auf meine Dauermeldung gehört, das Kein Objekt so heissen darf wie ein anderes und das nun auch Gruppenübergreifend implimentiert ohne es zu vermelden? Aber das Gewerk 950 gab es ja auch nicht mehr.
- Mhh, beiseite geschoben und Merker gesetzt.
- Sei es drum - nehmen wir einen anderen Namen. Neuen Favoriten angelegt mit Namen 41
- bekanntes Script:
Code: Alles auswählen
object test1 = dom.GetObject("41");
WriteLine(test1.Name());
Verdammt, (der kennende Mitleser wird es erwarten) da wird Servicemeldungen ausgegeben statt der erwarteten "41" für den Namen des angelegten Favoriten.
Und wieder gilt die prozentuale Verteilung wie oben, spar ich mir.
Also auch wieder den sichereren Zugriff mittels:
Code: Alles auswählen
object test3 = (dom.GetObject(ID_FAVORITES)).Get("41");
WriteLine(test3);
und wieder null.
Also den Test erstmal beenden, Favoriten wieder umbenennen in Testfavorit.
Zum Check noch mal schnell nachgeschaut:
Code: Alles auswählen
WriteLine(dom.GetObject(ID_FAVORITES).EnumUsedNames());
Ausgabe:
950
950 1
_USER1004
_USER1238
_USER41587
Alle
Heizungen Lichter
PC
PDA
Security
Testfavorit
Zentrale
Ohje, wo kommen denn
die jetzt her.
Schon wieder irgendwelche Geisterobjekte.
Du siehst, es ist immer noch ratsam Zahlen nicht zu verwenden für Namen.
Zahlen als Präfix vor Namen will ich nicht mehr probieren, denke aber das war gefixt.
Vor Umlauten äöüß....kann man ebenfalls nur warnen. Leerstellen, noch nie ein Problem ....
Allgemein gilt, verwendet man keine Scripte ist es auch noch relativ egal ob man Umlaute verwendet. Intern arbeitet die CCU mit den ISE_IDs von Objekten, also soweit erst mal nicht so schlimm. Aber auch die internen Scripte sind nicht fehlerfrei.
Benutzt man Apps, Tools wie den Scriptexecuter oder ähnliches, welche andere Codierungen benutzen, dann geht das Problem schon los.
Meine Meinung, vermeidet solche Sachen, es sei denn ihr seit euch sicher was ihr tut.
Und ich darf jetzt forschen warum meine Favoriten um Geisterobjekte bereichert wurden.
Alchy
