LockingVector

Jeder der in der EPLAN API programmiert, kennt die Aufwände beim Locking. Es ist mir nicht immer ganz klar wann was zu verwenden ist. LockingVector sollte nur in Ausnahmefällen verwendet werden, es kann zu unschönen Verhalten kommen. Auch so in der API-Hilfe beschrieben.

Der LockingVector hebelt das Locking komplett aus und die API verhält sich ähnlich wie die Oberfläche. Hört sich gut an, aber wie gesagt für mich nur mit Vorsicht zu genießen.

Dennoch gibt es für mich einen Anwendungsfall: Interne EPLAN Action im API ausführen… Ja manchmal muss man das. Hatte mit Auswertungen aktualisieren den Fall:

Wichtig ist dass ResumeManualLock()  nicht vergessen wird… Ich hab mir das mal in ein Using gepackt, das sich um alles kümmert und auch die Klasse auf GitHub bereitgestellt:

Artikel mit Funktionsschablone erzeugen

Schnell mal per API Artikel mit Funktionsschablone erzeugen war meine Aufgabe…
Naja nicht so einfach:

Es darf nur ein Artikel hinterlegt sein, sonst schlägt die Action XPameCreateType  fehl. Ist nicht schön, aber die Funktionsschablone von Hand zu erstellen ist mir zu heikel. Denn da kommt ja oftmals was neues dazu :^)

UndoStep & SafetyPoint

Man ist es gewohnt über Bearbeiten Rückgängig  zu arbeiten…
Aber das geht nicht von alleine, mann muss schon was dafür tun.

EPLAN stellt hier zwei Klassen bereit, welche das sehr gut implementieren. Muss sagen ich nutze für Schreiboperationen (ab sofort) immer Beide.
UndoStep lässt den User die Möglichkeit die Bearbeitung per API rückgängig zu machen. SafetyPoint stellt den Ursprung wieder her, falls eine Exception auftritt.

Toller Nebeneffekt, man muss sich nicht ums Locking der erzeugten Elemente kümmern :)

EPLAN-API: Signierung automatisieren (Update 2)

Und täglich grüßt die EPLAN Signierung…

Meine Beschreibung hier, klappt leider nur wenn man eine DLL bzw. EXE hat. Es wird zwar alles richtig signiert, aber die Verweise werden nicht aktualisiert, da ist .NET schuld…

Tja, für die Meisten wird das kein Problem sein, aber ich arbeite immer mit verteilten Libraries.

Ich habe einen Weg gefunden der für mich OK ist. Bisl manuelle Arbeit hat man wenn man mehrere Keys signieren muss.
In der AssemblyInfo.cs  lege ich fest dass in der Release Konfiguration die Kompiler-Attribute für EPLAN gesetzt werden.

Das tolle ist, ich kann nach wie vor den Release Build testen, wenn ich das Trace Flag wegnehme.

Zusätzlich wird die Signierung wirklich erst von EPLAN gemacht… denn die Attribute reservieren nur den Speicher in den Assemblies. Somit kann man auch Extensions verwenden welche den Build beeinflussen wie Fody.PropertyChanged, welches bei mir immer mit WPF im Einsatz ist.

Mir ist beim Bauen einer Offline-Application auch noch was aufgefallen:
Werden externe Assemblies verwendet, achtet darauf das diese strong namend signiert sind. Sonst könnt Ihr Sie nicht verwenden. Ich nutze zum Glück ausschließlich OpenSource Lösungen… denn eine davon war nicht signiert und ich musste es dann mit dem EPLAN KeyFile selbst machen, was ich ja konnte da Code vorhanden ist :^)

Vielen Dank an der Stelle, mal wieder, an den tollen EPLAN API Support, der mir hier wieder freundlich zur Seite stand!