Kleine Ergänzung: Damit lässt sich das umsetzen, was ich machen wollte.
Zwei Hinweise, falls das mal jemand findet und ähnlich nutzen will:
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:
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.