Kleine Ergänzung: Damit lässt sich das umsetzen, was ich machen wollte.

Zwei Hinweise, falls das mal jemand findet und ähnlich nutzen will:

• webView.NavigationStarting wird auch aufgerufen, wenn man via webView.Source eine URL aufruft. Wenn man in NavigationStarting das Navigieren via e.Cancel = True abwürgt sollte man auf die aufgerufene URL prüfen, sonst sägt man sich selbst wieder ab.
• Wenn man URLs mit neuen Fenstern als Ziel aufruft (<a href='{url}' target='_blank'>), dann greift NavigationStarting nicht, da die Instanzierung eines neuen Fensters offensichtlich direkt erfolgt und NavigationStarting in der aktuellen webView-Instanz garnicht erst angesteuert wird.

Oh mann, war gestern dann doch wahrscheinlich zu lange... Das sieht genau nach dem aus, was ich suche. Drei mal über die Events gelunzt, drei mal übersehen...

Danke.

VG Uwe

Hallo zusammen,

ich steh mir wahrscheinlich grad mal wieder selber im Weg...

Lange Vorgeschichte:

• Wir haben nen ERP (WinForms, Clientbasiert), an dem man so einiges customizen kann.
• Unter Anderem kann man da sogenannte Infoscreens erstellen, die sich in den Modulen in der Oberfläche beliebig einhängen lassen. Diese Infoscreens sind quasi dynamische HTML-Seiten, aber technologisch ne Mischung aus VB-Script, VBA (die Älteren erinnern sich vielleicht noch...) und HTML/CSS. Gruselig zu entwickeln, weil alles in einem Textblock stecken muss, keine fertigen Komponenten nutzbar sind, etc. Geht irgendwie, aber vom Aufwand her zum Ergebnis einfach bäh. Zumal HTML/CSS auch eingeschränkt ist, da das Ganze dann im ERP auf dem guten, alten Browsercontrol auf IE7-Basis läuft. Das wird gleich noch wichtig: Ausführung der Scripte war komplett lokal am Client.
• In diesem Konstrukt konnte man aber Links auf andere Datenobjekte im ERP aufbauen (Logikbeispiel: ERP://contact=12345). Das Ganze funktioniert auch aus anderen Apps heraus (HTML-Mails, etc.), da der Handler auch im System registriert ist. Entscheidender Punkt: Innerhalb der Darstellung im ERP fängt das jetzige Browsercontrol die angeklickten Links ab und öffnet das passende Modul samt Datensatz.
• Nachdem ich nun ne Weile mit Blazor unterwegs bin kam die Idee auf, ob man das nicht darüber abfackeln könnte. Entsprechende Seiten zu bauen ist kein Problem, parametrisierter Aufruf auch nicht. Knackpunkt: Das alte Browsercontrol kann den Kram nicht mehr sauber darstellen. Meistens machen die JavaScript-Teile Probleme.
• Lösungsansatz: Man kann auch net-basierte Plugins/Usercontrols in die ERP-Oberfläche einbinden. Also nen Plugin mit WebView2 gebaut und dem ganzen untergeschoben. Funktioniert soweit super! Alles wird sauber dargestellt. Aber wir nähern uns dem eigentlichen Problem...

Kurze Frage:

Die Blazor-Seiten laufen ja aufm Server, der Client (hier im lokalen ERP-Plugin) stellt nur dar. Wenn nun in den Seiten einer der oben beschriebenen Links auf eines der anderen Datenobjekte angeklickt wird, dann würde die Blazor-Seite das ja an den Server schicken, wo mir das nichts nützt. Ich brauche die Info  lokal am Client, um dort das andere Objekt aufzurufen. Den Objektaufruf dem ERP unterschieben ist kein Problem. Aber wie komme ich beim WebView2-Control an die Info, dass da ein Link aufgerufen wurde und welcher?

Danke schon mal für sachdienliche Hinweise?

VG Uwe

Klingt für mich auch so, als würde Obsidian ganz gut passen. Vor allem, weil es Daten lokal synct, was ja offensichtlich durchaus ein relevantes Feature zu sein scheint.

Auch wenns schon ne Weile her ist, aber falls mal jemand was Ähnliches sucht:

Der SQL-Server bietet ein Feature, das nennt sich Verbindungsserver. Damit kannst Du andere Datenquellen, also auch andere SQL-Server (mit denen gehts auch am Stressfreiesten) einbinden. Und dann zentral über eine SQL-Verbindung ansprechen und auch zusammen in einer Abfrage ansprechen.

Zitat von visionmaster

Ich muss aus C# heraus eine PDF-Datei in eine Text-Datei konvertieren. Es soll eigentlich die gleiche Funktion sein, die im Dialog im ACROBAT-Reader als "Speichern unter..." zur Verfügung steht.

Wichtig wäre dabei auch, dass die Ausgabedatei die gleiche Struktur hat, die ACROBAT erzeugt.

Ob das mit dem letzten Punkt so klappt kann ich nicht sagen, aber wir haben vor paar Jahren für die reine Textextraktion die  Tesseract OCR Engine genutzt. Lief relativ gut und auch performant. Vielleicht ja nen Lösungsansatz...

Man kann zwar auch versuchen den Adobe Reader anzusprechen und zu automatisieren, aber das war immer problematisch und auch alles Andere als stabil.

Zitat von Abt

Zitat von vieledinge

Alles, was länger als 30 Zeilen ist sollte man überdenken

Mit welchem Sinn? Der Sinn von Trennung in Methoden ist Verantwortlichkeit.

Da stimme ich Dir durchaus zu.

Die 30 Zeilen sind kein Dogma. Die Praxis zeigt aber, dass es ab einer gewissen Codeblockgröße durchaus sinnvoll sein kann, da hinterher nochmal drüber nachzudenken, was man da tut und ob man das eventuell nochmal aufteilen sollte. Und wenn die Antwort "Nein" lautet, dann ist es auch gut.

Paar Punkte, die mir spontan auffallen:

Größe der Codeblöcke: Kurzer, kompakter Code ist besser verständlich. Alles, was länger als 30 Zeilen ist sollte man überdenken, ob man da nicht Teile davon sinnvoll in separate Functions oder Klassen auslagern kann.

Geschachtelte Schleifen: Würde ich versuchen zu vermeiden. Auch hier: Blöcke in Functions auslagern.

do while: Mag ich nicht (Persönliche Hassliebe). Konditionen am Ende der Schleife finde ich einfach bescheiden lesbar.

Ausgaben sinnvoll zusammenfassen, um kompakten Code zu erhalten. Die drei Varianten machen alle das Gleiche. Man muss halt ggfs. schauen, für welche Plattform(en) man entwickelt:

Console.WriteLine();
Console.WriteLine("Der eingegebene Wert muss eine Zahl sein!");
Console.WriteLine();

Console.WriteLine("\r\nDer eingegebene Wert muss eine Zahl sein!\r\n");

Console.WriteLine($"{Environment.NewLine}Der eingegebene Wert muss eine Zahl sein!{Environment.NewLine}");

Hallo zusammen,

für nen Inhouse-Projekt bräuchte ich ne Komponente, um erhaltene Rechnungs-PDFs zu prüfen, ob es sich um elektronische Rechnungen nach ZugFerd-/XRechnungs-Standard handelt und um danach die eingebetteten XML-Rechnungdsdaten zu extrahieren. Kann zwar theoretisch auch das vorhandene DMS, ich brauche aber bestimmte Infos für die korrekte Prozesseinsteuerung, BEVOR ich das Zeug ins DMS werfe.

Was ganz interessant aussieht ist https://konik.io, muss ich aber noch testen.

Gibts noch Tipps zu anderen, schlanken Tools, die man sich mal anschauen sollte?

Ansonsten findet man so einige Suiten wie PDFlib, die eher in Richtung eierlegende Wollmilchsau gehen und hier eher die Variante "mit der Wurst nach dem Schinken geworfen" wären.

VG Uwe

Zitat von Abt

Blöderweise liegen im ERP-Verzeichnis div. weitere DLLs (MS, 3rdParty), die so auch von den DMS-DLLs benötigt werden. Aber natürlich andere Versionsstände und irgendwas beißt sich da und das ERP zickt rum, wenn ich da die neueren Versionen nutzen will.

Verschiedene Versionen beißen sich immer, sofern Du Dich in einer App Domain befindest. Da hilft auch ein anderer Ordner nicht.

Das war vielleicht bisschen unglücklich ausgedrückt: Ich selbst nutze in meinen Komponenten indirekt nur eine Version der DLLs (die, die von der DMS-Software benötigt werden). Da ich aber dem ERP-System meine DLL nicht an einem beliebigen Ort zur Verfügung stellen kann, sondern die blöderweise zwingend im ERP-Verzeichnis liegen muss, habe ich das Dateikonflikt-Problem.

Habe ich ne Möglichkeit die Verweis-Komponenten der DLL in der Runtime-Umgebung in einem anderen Verzeichnis unterzuschieben? Also so, dass meine DLL immer noch im ERP-Verzeichnis liegt, alle zugehörigen Verweis-DLLs aber z.Bsp. in nem Unterverzeichnis \DMS?

Oder kann ich der DLL auch ne app.config unterschieben?

Es gibt auch dll.configs, wobei die ursprünglich einen anderen Zweck haben.
Könnte sein, dass aber assembly bindings ebenfalls unterstützt werden.

Ok, also mal testen.