Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Gute Frage. Ist mir auch erst jetzt aufgefallen. Editor habe ich Notepad2 unter Win7 verwendet und Code mit Copy Paste eingefügt. (Firefox).
Im Editor siehts gut aus. Und zumindest meine heutige Hauptarbeit (Externes PHP) lief auf dem Edomi Rechner normal. (Nicht als Edomi LBS). Und hab den gleichen Editor verwendet.
Bin jetzt leider nicht mehr an meinem Compi. Kanns erst morgen testen. Dachte aber, ich hätte mal utf8 in der Fusszeile gesehen.
@rdeckard
Kann mich täuschen - sieht aber irgendwie merkwürdig aus. $E[3] hat einen #init-Wert, $E[2] Bezeichnung Trigger aber $E[1] prüfst du als Startbedingung für den EXEC-Teil.
Leider sehe ich nicht (deine eingefügten Bilder sind bei mir nicht sichtbar), ob du tatsächlich einen Wert !=0 am $E[1] anliegen hast.
Zuletzt geändert von KNXFan1970; 22.02.2016, 06:00.
Hast recht, dieser Block stimmt nicht genau mit meinen Eingangsvariablen überrein. In meiner ursprünglichen Version war das nicht so drin. Um aber einen sauberen Stand zum Testen zu erhalten, habe ich das Gerüst vom gaert übernommen. Und da war dieser Block so drin. (Habs aber dann vergessen, auf meine Variablen anzupassen.)
Aber es ging schon vorher ohne diesen Block nicht richtig.
Und zum Testen habe ich im Logikeditor die Werte fix gesetzt. (Die Sache mit dem Zeichensatz muss ich noch prüfen. Irritiert mich etwas.)
Dann würde mir, um zu prüfen, ob die Eingabe für das Port eine ganze Zahl (kein Komma) ist, folgendes Abfrage ausreichen:
Nicht ganz, is_numeric haelt sich ja auch fuer floats zustaendig, 1.234 waere also demnach auch ein gueltiger Port.
Wenn Du das wirklich alles ueberpruefen willst, dann musste auch sicherstellen, dass es wirklich ein integer ist. Das geht zB mit is_int, abrufen mittels floor und dann "mit sich selbst" vergleichen oder sicher irgendwie mit ctype_digit.
Mach doch einfach ein $port=floor($port+0), dann steht in $port zumindest schonmal ein integer, denn kannste dann mit dem alten $port vergleichen und wenn das nicht identische Strings sind, dann war $port am Anfang ungueltig.
Hallo Christian, ist der „Inhalt“ des Eingangs am LBS - hier z.B. eine Ganzzahl 9999 „automatisch“ ein String ?
Ich bilde mir ein, dass ich die 9999 schon mit is_int() getestet habe und FALSE als Antwort erhielt …
EDIT: scheint tatsächlich so zu sein …
Mit is_int() wird die IF-Bedingung nicht erfüllt (false) …
Mit is_numeric() wird wohl auch 999.9 als gültig erkannt und der LBS wird damit ein Problem haben ...
Zuletzt geändert von coliflower; 22.02.2016, 12:41.
Variablen beziehen sich auf genau eine LBS-Instanz, d.h. mehrere LBS gleichen Typs beeinflussen sich nicht hinsichtlich deren Variablen. Die Variablen halten einen Wert solange, bis EDOMI beendet bzw. neu gestartet wird. Variablen und Initialwerte vom Typ String werden genau wie Zahlen ohne(!) Anführungszeichen deklariert (Zeichenketten und Zahlen werden intern nicht unterschieden).
Ich les das so, als ob es einfach Strings sind, auch wenn man sie ohne Anführungszeichen deklariert.
Mit is_int() wird die IF-Bedingung nicht erfüllt (false) …
Ich werde mich hueten hier nochmal Mutmassungen ueber die Funktionsweise von Edomi abzugeben
Aber wenn ich das gebaut haette:
-wenn Dein Eingang ein internes KO ist, dann waere es vom Typ variant, der bei mir nicht zwischen Zahlen und Strings unterscheiden wuerde
-wenn Dein Eingang ein externes KO ist, dann koennte man natuerlich anhand des DPTs festlegen welchen Datentyp man an der Stelle uebergibt - PHP ist aber nur recht schwach bis garnicht typisiert, deswegen haette ich das nicht gemacht
Bei mir waeren das also vermutlich immer Elemente der kleinsten gemeinsamen Obermenge - anders ausgedrueckt: Strings.
Das ist auch gut so, denn damit kann man einfach so rumhantieren und muss sich keine Gedanken ueber Vorzeichen, Wertebereich, Farbe oder Geruch machen. Da kann man dann zB auch sowas wie "hallo+5" ausrechnen (wobei uebrigens 5 rauskommt). Im Gegenzug bedeutet das aber auch, dass es nicht so wirklich einfach ist festzustellen, ob ein Wert einem bestimmten Datentyp entspricht (oder entsprechen koennte). Und da faengt jetzt Dein Dilemma an
Aber nochmal in Code:
PHP-Code:
if ($i == strval(floor($i+0))) { print "INTEGER"; }
obiges interpretiert aber zB auch "1.0" als integer, alternativ kann man auch einfach gucken, ob $i nur aus Zahlen besteht:
PHP-Code:
if (preg_match('/^\d+$/',$i)) { print "INTEGER"; }
Damit werden aber keine Angaben im Exponentialformat mehr akzeptiert
Was auch gaenge, waere so:
PHP-Code:
$i=104; $check=$i+0; if (is_int($check)) { print "INTEGER"; }
Ich glaube, das ist relativ sicher - aber irgendwas wird da auch irgendwann nicht mehr passen.
Wozu soll der ganze Aufwand nochmal dienen?
Bedenke: idiotensichere Systeme sind nur solange sicher, wie sie von Idioten bedient werden. Irgendwann wird schon jemand "rausfinden" wie er einen Wert eingibt der dann doch nicht von deinem LBS abgefangen wird und stattdessen im Edomi Log landet
Es ist ein Initialwert, kein KO … Ich sah derzeit keine Notwendigkeit es über ein KO einzugeben …
Dann belasse ich es bei is_numeric() um Blabla abzufangen, der Rest ist mir somit Wurscht ...
Bedenke: idiotensichere Systeme sind nur solange sicher, wie sie von Idioten bedient werden. Irgendwann wird schon jemand "rausfinden" wie er einen Wert eingibt der dann doch nicht von deinem LBS abgefangen wird und stattdessen im Edomi Log landet
Da fällt mir ein, was ich letztens irgendwo in einer Signatur gelesen habe: "If you make something idiot proof, they start making better idiots"
Ich komme auf mein gestriges LBS-Problem zurück. In der Tat war es als ANSI gespeichert. Da ich die ganze Zeit mit einem bestehenden utf8-Code gearbeitet habe (inkl. PHP-Tests, aber ausserhalb von Edomi) und erst am Schluss dann ein NEUES Textfile erzeugt habe, ist mir nicht aufgefallen, dass der Editor scheinbar ANSI als Default für neue Dateien verwendet.
Zudem war ja noch in der Abfrage des Triggers ein Fehler, weil die Vorlage mit e1 als Trigger arbeitet und ich e2 verwendet habe.
Habe beides korrigiert und dann lief der Test-LBS durch.
Leider ist damit mein ursprüngliches Problem nicht gelöst worden. Denn, wenn ich jetzt meinen "richtigen" LBS starte, bringt mir Edomi 2 Fehlermeldungen ins Fehlerlog.
Ich hab den Code etwas verkürzt (wiederkehrende IF-Abfragen entfernt):
2016-02-22 20:53:17406373?113981/usr/local/edomi/www/data/liveproject/lbs/EXE19000901.php: Code 2 / Zeile 1 / file() expects parameter 1 to be string, array given ERROR
2016-02-22 20:53:17406919?113981/usr/local/edomi/www/data/liveproject/lbs/EXE19000901.php: Code 2 / Zeile 1 / Invalid argument supplied for foreach() ERROR
Was ist eigentlich mit Code 2 und Zeile 1 gemeint?
Und wie schon zu Beginn erwähnt. Der eigentliche EXEC-Code läuft unter PHP (ausserhalb Edomi) normal durch. (Natürlich muss ich dann die Eingangsvariablen manuell noch setzen.)
ich hab mal eine kleine Frage bzgl. PHP. Eventuell (bestimmt) kann mir jemand von euch Pro's weiterhelfen.
Ich bin derzeit ein wenig an einem LBS am basteln, welcher mir mein ISG ausliest. Hier mal ein Auszug aus dem LBS
wenn ich das ganze als PHP aufrufe bekomme ich meine einzelnen "match" angezeigt, lade ich den LBS in Endomi bekomme ich td class=value 23,9 td als Ausgabe.
Jetzt wollte ich einfach die Zahlen filtern indem ich alle Buchstaben Filter sprich
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar