8. Lizenz und Demomodus #

← FAQ und Fehlerbehebung · Inhalt

PBToolboxAI ist eine kommerzielle Bibliothek. Die Lizenzprüfung erfolgt vollständig offline: keine Verbindung, keine Aktivierung, kein Serveraufruf. Ein signierter Schlüssel wird beim Start gesetzt, die DLL prüft ihn lokal.

8.1 Die drei Schlüsseltypen #

Die Schlüssel sind kumulierbar: Rufen Sie PBT_SetLicense so oft wie nötig auf, die Bibliothek behält einen Schlüssel je Typ.

Typ	Inhaber	Schaltet frei
`dev`	Namentlich, ein Entwickler	Nur in der PowerBuilder-IDE
`runtime`	Ihr Unternehmen, eingebettet in die ausgelieferte Anwendung	Nur in einer kompilierten ausführbaren Datei
`demo`	Mit der Demoanwendung geliefert	Die Demoanwendung, in der IDE, bis zum Ablauf

Ein Projekt benötigt also beide: einen dev-Platz je Entwickler und einen runtime-Schlüssel für die Anwendung, die Sie an Ihre Kunden ausliefern.

Ein dev-Schlüssel, der in einer ausführbaren Datei landet, schaltet nichts frei.
Ein runtime-Schlüssel gewährt keinen Entwicklungsplatz.
Ihre Endkunden müssen nichts eingeben und nichts aktivieren: Der runtime-Schlüssel steckt in Ihrem Code.

Die Erkennung „IDE oder ausführbare Datei“ wird von der DLL selbst vorgenommen (Prozessname, geladene Design-Time-Module), nicht von PowerBuilder-Code — sie lässt sich aus Ihren Quellen nicht umgehen.

8.2 Den Schlüssel setzen #

Nur eines ist zu tun, vor dem Öffnen des ersten Fensters:

// Deklaration - Anwendungsobjekt, "Local External Functions"
Function long PBT_SetLicense (string as_client, string as_key) Library "pbtoolboxai.dll"

// Event open des Anwendungsobjekts
long ll_rc
string ls_cle_dev

// Der RUNTIME-Schluessel gehoert in den Code : er MUSS in die EXE.
ll_rc = PBT_SetLicense(gs_titulaire, gs_cle_runtime)

// Der DEV-Schluessel wird vom Rechner gelesen : er schaltet nur die IDE frei,
// im Code wuerde er in jede Kopie wandern, ohne dort etwas zu nuetzen.
ls_cle_dev = ProfileString("pbtoolboxai.ini", "license", "dev", "")
if ls_cle_dev <> "" then ll_rc = PBT_SetLicense(gs_titulaire, ls_cle_dev)

Open(w_principale)

Der Schlüssel wird über die DLL-Funktion gesetzt, nie über eine Komponentenmethode: Er gilt für den gesamten Prozess und muss gesetzt werden, bevor irgendeine Komponente existiert. Aus demselben Grund verlangt PBT_LicenseStatus kein Handle.

Der Inhaber wird im Klartext als erstes Argument übergeben: der Name (oder die E-Mail-Adresse), auf den die Lizenz ausgestellt wurde, und er muss mit dem im signierten Schlüssel übereinstimmen. Ein Schlüssel kann also nicht weitergegeben werden, ohne den Namen des Käufers mitzugeben.

Rückgabe	Bedeutung
`0`	Schlüssel gültig und übernommen
`-1`	Ungültiges Schlüsselformat
`-2`	Ungültige Signatur (Schlüssel verändert oder fremd)
`-3`	Wartung abgelaufen für diese Version der Bibliothek (siehe 8.5)
`-4`	`demo`-Schlüssel abgelaufen
`-5`	Der übergebene Inhaber stimmt nicht mit dem des Schlüssels überein

💡 Welcher Schlüssel gehört wohin. Der runtime-Schlüssel gehört in den Code: er muss in der ausgelieferten ausführbaren Datei landen. Der dev-Schlüssel nicht — er schaltet nur die IDE frei, in einer EXE ist er also nutzlos und reist trotzdem mit, samt Ihrem Firmennamen. Sein Platz ist eine Datei pbtoolboxai.ini neben der IDE oder ein Registry-Wert.

Den Schlüssel nach der Erstellung einer Komponente zu setzen, funktioniert ebenfalls: Bereits geöffnete Komponenten werden sofort freigeschaltet. Am einfachsten bleibt jedoch das Event open der Anwendung.

💡 Bewahren Sie den Schlüssel in einer Konstanten oder einer Ressource Ihrer Anwendung auf. Er ist signiert: Er enthält kein verwertbares Geheimnis und kann nicht verändert werden, ohne seine Signatur ungültig zu machen.

8.3 Den Lizenzzustand prüfen #

// Deklaration
Function long PBT_LicenseStatus (ref string as_json, long al_len) Library "pbtoolboxai.dll"

string ls_statut

ls_statut = Space(1024)
PBT_LicenseStatus(ls_statut, 1024)
// -> {"licensed":true,"ide":false,"keys":{...},"reason":""}

Nützlich in der Integrationsphase, um zu prüfen, ob ein Schlüssel berücksichtigt wird, oder um einen Start in Ihrem Anwendungsprotokoll festzuhalten.

8.4 Der Demomodus #

Ohne gültigen Schlüssel — oder mit einem Schlüssel, der nicht zum Kontext passt (etwa ein dev-Schlüssel in einer Exe) — läuft die Bibliothek im Demomodus: Alles ist nutzbar, alles ist sichtbar, aber mit Grenzen — außer den vier Komponenten der Community-Edition, die gleich darunter beschrieben sind und nie eingeschränkt werden.

Vier Komponenten bleiben kostenlos #

Die Community-Edition muss nicht eingerichtet werden: ganz ohne Schlüssel laufen vier Komponenten ohne Abzeichen und ohne Grenze, zeitlich unbegrenzt.

Komponente	Was sie bringt
statictext	Beschriftung mit Auszeichnung: fett, Farben, Links, Aufzählungen, klappbare Blöcke
messagebox	Thematisierter modaler Dialog mit frei wählbaren Schaltflächen
toaster	Benachrichtigungen in der Bildschirmecke, mit Titel, Bild und Aktionen
webbrowser	WebView2-Browser, eingebettet in ein PowerBuilder-Fenster

Die Wahl ist bewusst: Es sind die vier, denen man zuerst begegnet, sie tragen kein eigenes Datenmodell, und sie genügen, um auf einem gesperrten Rechner zu beweisen, dass die Laufzeitumgebung sich verteilen lässt — das eigentliche Hindernis vor jedem Kauf.

Die Liste lebt in der DLL. PBT_LicenseStatus gibt sie unverändert unter "free" zurück: Ihre Anwendung kann also ansagen, worauf sie ohne Schlüssel Anspruch hat, statt es Komponente für Komponente zu entdecken.

Ein gültiger Schlüssel hat immer Vorrang: bei diesen vier Komponenten wie bei allen anderen stellt er Ihren Namen und Ihre Edition wieder her.

Das Abzeichen #

Jede Komponente zeigt ein Abzeichen „PBToolboxAI — DEMO“, das nicht ausgeblendet werden kann.

Die funktionalen Grenzen #

Komponente	Grenze im Demomodus
tab	Höchstens 3 Seiten
ribbon	Höchstens 2 Registerkarten
toolbar	6 angezeigte Items über alle Leisten hinweg
tilesbox	8 angezeigte Kacheln
Alle anderen	Nur das Abzeichen — keine funktionale Grenze

Diese Grenzen gelten für die Darstellung: Nichts schlägt fehl, die Anzeige wird abgeschnitten. Sie können daher jede Komponente wirklich bewerten, mit Ihren eigenen Daten, bevor Sie kaufen.

Das Setzen eines gültigen Schlüssels hebt alle diese Grenzen sofort auf und entfernt das Abzeichen, ohne die Anwendung neu zu starten.

8.5 Unbefristet + Wartung #

Die Lizenz ist unbefristet: Die von Ihrem Wartungszeitraum abgedeckten Versionen funktionieren für immer, auch nach dessen Ablauf.

Konkret trägt der Schlüssel ein Wartungsenddatum, das mit dem Erstellungsdatum der DLL verglichen wird:

eine Version der Bibliothek, die während Ihrer Wartung veröffentlicht wurde, ist dauerhaft freigeschaltet;
eine nach dem Ablauf veröffentlichte Version liefert -3 zurück: Erneuern Sie die Wartung, um darauf zuzugreifen;
Ihre bereits ausgelieferten Anwendungen sind niemals betroffen: Sie enthalten die Version, die sie immer verwendet haben.

8.6 Häufige Fragen #

Wird mein Schlüssel online geprüft? Nein. Kein Netzwerk, niemals. Die Prüfung ist eine RSA-Signatur, die lokal von Windows validiert wird.

Brauchen meine Kunden einen Schlüssel? Nein. Ihr runtime-Schlüssel steckt in Ihrer Anwendung; sie bekommen von der Lizenz nie etwas zu sehen.

Was passiert, wenn ich PBT_SetLicense in der Produktion vergesse? Die Anwendung funktioniert, aber jede Komponente zeigt das Demo-Abzeichen und die Grenzen aus der obigen Tabelle gelten. Das ist der erste Punkt, den Sie prüfen sollten, wenn bei einem Kunden ein Abzeichen erscheint.

Kann ich einen dev-Schlüssel und einen runtime-Schlüssel im selben Code setzen? Ja — das ist sogar der Regelfall: Der dev-Schlüssel greift, wenn Sie aus der IDE ausführen, der runtime-Schlüssel, wenn Sie die Exe ausführen. Jeder wird im jeweils anderen Kontext ignoriert.

Das Abzeichen erscheint, obwohl der Schlüssel gesetzt ist. Drei Ursachen, nach Häufigkeit geordnet: (1) ein dev-Schlüssel, während Sie eine kompilierte Exe ausführen, oder umgekehrt; (2) der Rückgabewert von PBT_SetLicense wurde nicht geprüft — vergewissern Sie sich, dass er 0 lautet; (3) Wartung abgelaufen für die installierte DLL-Version (Rückgabe -3). PBT_LicenseStatus klärt das in einer Zeile.

Ein Schlüssel ist personengebunden. Ein dev-Schlüssel ist an einen Entwickler gebunden, ein runtime-Schlüssel an Ihr Unternehmen. Geben Sie sie nicht außerhalb Ihres Teams weiter.

← FAQ und Fehlerbehebung · Inhalt