RequireParent in 9.0

Erweiterungen PHP-Module (Entwicklung)
1

Ich teste gerade ein Modul mit einem kleinen Nutzerkreis. Ich hatte bisher nur unter 8.x das Modul genutzt bzw. entwickelt.

Im Modul wird ganz normal

$this->RequireParent('{9CD1AA03-841E-FB97-8E32-6536A1D4561B}');

genutzt. Bei mir selber werden auch alle passenden Parent Instanzen automatisch angelegt. Jetzt hat ein Tester schon die 9.0 und da kommt auf einmal so was

Screenshot 2026-02-18 154736
Screenshot 2026-02-18 1547362128×1006 124 KB

Was hat sich denn zur 9.0 geändert bzw. muss im Modul angepasst werden, damit das wie bisher zur Version 8 auch funktioniert und der Parent einfach angelegt wird?

2

Das wird nicht mehr passieren. Die Konsole übergibt hier die Hoheit an den Nutzer.

Also weitermachen.. gibt hier nix zu sehen :wink:

Weil diese GUID gibt es doch gar nicht.. oder ist 9CD1AA03-841E-FB97-8E32-6536A1D4561B von deinem Modul? Weil dann sollte das in der Liste auftauchen.
Oder wolltest du den WS Client haben? Der hat D68FD31F-0E90-7019-F16C-1949BD3079EF

Schau mal hier, dort steht was sich geändert hat:
GetCompatibleParents

3

Danke für die Antwort

Ist das generell so ab 9.x, warum soll der Nutzer da was aussuchen, das führt doch nur zur Verwirrung, wenn der Nutzer auch noch wissen muss was für ein Socket er braucht? Das ging bisher doch auch, warum wird das denn geändert?

Eigentlich wollte ich in der Tat einen WS Client haben, das ging aber zumindest bis zur Version 8 auch. Aber wenn ich das ändern muss oder sich die GUID verändert hat dann stelle ich das um.

Kann ich denn RequireParent behalten, oder muss ich jetzt wirklich auf IPSModuleStrict umstellen um zwingend GetCompatibleParents zu nutzen?

4

Dem User wird schon das richtige vorgeschlagen, wenn du die richtige GUID benutzt.
Und bei IPSModule kannst du RequireParent auch nutzen; damit es abwärtskompatibel ist bleibt diese Funktion.
Du kannst aber auch schon GetCompatibleParents (gibt es seit 8.2 Testing) nutzen.

Nur bei IPSModuleStrict gibt es kein RequireParent mehr. Da ist GetCompatibleParents Pflicht.
Sollte so auch alles in der Doku (bei RequireParent) stehen :wink:

5

Was mache ich denn falsch bzw. warum verhält sich Symcon 9 so?
Ich habe eine Discovery Instanz

das ist die Module.json
{ "id": "{4C0ABD10-D25B-0D92-9B2A-9E10E24659B0}", "name": "Remote 3 Discovery", "type": 5, "vendor": "Unfolded Circle", "aliases": [], "parentRequirements": [], "childRequirements": [], "implemented": [ "{76BD37C4-C1A4-AA3A-4AFF-599D64F5E989}" ], "prefix": "UCR", "url": "https://www.unfoldedcircle.com" }

wenn ich diese Instanz anlege dann passiert das

Bildschirmfoto 2026-02-19 um 17.03.20
Bildschirmfoto 2026-02-19 um 17.03.201661×485 33.7 KB

ich habe aber auch kein
GetCompatibleParents
im Code

Warum erscheint also dieses Fenster in Symcon 9, wenn doch überhaupt keine Parent GUID in der module.json hinterlegt ist?

Wie schaffe ich es das dieses Fenster gar nicht erst in Symcon öffnet?

Die Instanz nutzt IPSModuleStrict.

6

Ich denke, das „implemented“ willst du gar nicht haben.

7

Das habe ich inzwischen gelöscht, das macht keinen Unterschied, das unerwünschte Fenster, siehe oben kommt dennoch.

Kann ich beim besten Willen nicht nachvollziehen warum Symcon so ein Fenster anzeigt, bei einer Discovery Instanz, die keinen Parent direkt hat.

8

Zeig doch bitte mal deine module.json?

9 
{
    "id": "{4C0ABD10-D25B-0D92-9B2A-9E10E24659B0}",
    "name": "Remote 3 Discovery",
    "type": 5,
    "vendor": "Unfolded Circle",
    "aliases": [],
    "parentRequirements": [],
    "childRequirements": [],
    "implemented": [],
    "prefix": "UCR",
    "url": "https://www.unfoldedcircle.com"
}
10

Modul neu geladen nach der Änderung in der JSON?

11

Die sieht gut aus.

Ein ReloadModule hast du sicherlich gemacht. Dann ist es in der module.php su suchen.

12

Macht keinen Unterschied, das Fenster mit den Schnittstellen suchen geht auf sobald die Discovery Instanz erzeugt wird. Das Fenster erscheint dann eine kurze Zeit danach schließt es sich selbstständig und die Discovery Instanz erscheint. Die Discovery Instanz selber funktioniert auch.

Die Frage ist nur muss man mit diesem störenden Fenster bei der ersten Anlegen der Discovery Instanz leben oder kann man das nicht irgendwie unterbinden?

13

Wie gesagt. Was passiert bei dir im Create und im Apply?
Hast du das Modul schon in GitHub? Ich kann da gerne mal drüberschauen.

EDIT:
Ich habe etwas geforscht. Das Ergebis ist:

Wenn im Apply ein

IPS_GetInstanceListByModuleID('{780B2D48-916C-4D59-AD35-5A429B2355A5}'); //DNSSD

ausgeführt wird und der Apply etwas länger dauert, dann ist eine Dialogbox für einen kurzen Moment zu sehen:

image
image1314×359 20.7 KB

Der Inhalt ist jedoch seltsam.

@Dr.Niels : das lässt sich bei mir durch einen sleep(5) im Apply leicht nachvollziehen.

14

Ich vermute das ist einfach der Inhalt vom „letzten mal“? Ich muss wahrscheinlich einfach nur aufräumen, damit zwischen Öffnen des Dialogs und Verfügbarkeit der relevanten Werte etwas passendes da steht. Aber das baue ich gerne ein :+1:

1 „Gefällt mir“
15

Auf die Gefahr hin, dass das eine nichts mit dem anderen zu tun hat:

Es gibt ja den grundsätzlichen Fehler, dass “Schnittstelle ändern” in einer Splitter-Instanz einen fehlerhaften Dialog anzeigt. Ebenso wird beim Neuanlegen die Liste nicht angezeigt, sondern ein neuer Client Socket erzeugt. Für mich hört sich das hier so an, als ob das eine mit dem anderen zusammenhängt bzw. erstmal der Fehler behoben werden muss.

16

So, Fix kommt an beiden Fronten. Der Dialog räumt auf solange die neuen Daten noch nicht vorhanden sind. Und der „Expertenmodus“ im Dialog erlaubt das Hängen an alle Schnittstellen trotz require. Außerdem ist die Checkbox für den Expertenmodus jetzt auch immer sichtbar.

2 „Gefällt mir“