ABACOM - ELECTRONIC SOFTWARE

Hallo zusammen,

eine nützliche Erweiterung wäre meines Erachtens die Integration der 'PStrings' in der
CSimStart - Routine ...
Diese wird bekanntlich zur Initialisierung der jeweiligen DLL eingesetzt.
Diese Verbesserung sollte zumindest in Version --> NEXT berücksichtigt werden.

Im Moment ist die Initialisierung von 'PStrings' NICHT möglich (Statusmeldungen, Errorstrings etc.). Dies belastet deshalb CCalculate unnötigerweise mit EINMAL-Code, welcher eigentlich in CSimStart viel besser 'aufgehoben' wäre. Da die Ausführungs-Geschwindigkeit von CCalculate direkt durch die Menge des enthaltenen / auszuführenden CODE's beeinflusst wird, ist jede mögliche Entlastung (von CCalculate) von Vorteil (wie auch in Handbuch zu DLL's beschrieben, soll der DLL-Aufruf (= CCalculate), so kurz wie möglich gehalten werden).

PS: Dies ist KEIN April-Scherz, sondern durchaus ernsthaft gemeint.

Hallo IKT,
das währe dann CSimStartEx, auf den ersten Blick verlockend.
In der Form wie PStrings im Moment in PL-DLL implementiert ist wird das aber leider nicht viel bringen.

Auszug aus DLL-Hilfe:
Bevor ProfiLab die Methode anspringt, werden die PChar mit den Werten von den $Eingängen belegt.
Nach Verlassen der Methode gibt ProfiLab die Inhalte der PChar über die $Ausgänge aus.
Ein Unterscheidung in Eingang und Ausgang findet hier nicht statt. So teilen sich z.B. Eingang 0 und Ausgang 0 den gleichen PChar.

Der Inhalt von PStrings geht zwischen zwei Aufrufen der DLL verloren, deswegen muss auch jeder PString-Ausgang bei jedem Aufruf neu beschrieben werden.
Bei POutput reicht es, einen Ausgang nur dann zu setzen wenn sich ein Wert ändert.

Ich hoffe auch, dass sich das in der nächsten Version ändert, das braucht aber viel Speicherplatz.

Mike

Hallo Mike,

Mike D hat geschrieben:... mit den Werten von den $Eingängen belegt ...

Obiges genauer angeschaut ergibt für mich folgendes:
- Wo es KEINE Eingänge gibt, wird auch NICHTS überschrieben (woher sollen denn die 'DATEN' für's Überschreiben herkommen?)
- Daraus folgt: die 'oberen' PStrings könnten durchaus als temp. Strings 'herhalten', ohne das sie überschrieben werden. (Bitte korrigiert mich, sollte ich falsch liegen ...)

Habe bei allen meinen Tests immer PStrings[99] und weiter nach unten eingesetzt (bis ca. 80), ohne je Probleme zu haben.
Anschliessend einfach:
PStrings[IO] = PStrings[nn] ' Temp. string nach IO-String
POutput[n] = PStrings[n] ' IO-String nach POutput (dies ist möglicherweise sogar überflüssig)

dann liege ich vielleicht falsch, hatte ich anders in Erinnerung.
Ich dachte das Array währe für jeden Aufruf nur temporär.

Hallo Mike,

Mike D hat geschrieben:Ich dachte das Array währe für jeden Aufruf nur temporär.

Das Temporär bezieht sich meiner Meinung nach darauf, dass es beim Sim.-Stop zerstört wird. Anderst als der Inhalt von PUser, der in der Hauptanwendung gespeichert wird.
Während der Simulation bleibt es aber erhalten.
@abacom,
können Sie bitte dieses Verhalten bestätigen oder dementieren?

Mike D hat recht und verweist korrekterweise auf die Anleitung.

Hallo Mike und abacom,

danke für die Klarstellung.

Der Verweis auf die Dokumentation ist, mit Verlaub gesagt, völlig daneben, da genau der Umstand, dass PStrings LOKAL zu CalculateEx / CCalculateEx ist, mit keiner Silbe erwähnt wird.
Zitat Mike: "... mit jedem Aufruf neu erstellt wird."
Dies ist definitiv etwas anderes als 'überschreiben'. Es ist eher 'erneut schreiben' nachdem das Array neu erstellt wurde.

Habe das Update von heute drauf, also auch die aktuellste Version der Doku (nochmals überprüft).