Die letzten Monate haben eher gezeigt, dass so eine "Zwitter-Runtime" mit .NET Core -> NET Framework -> COM keine gute Idee ist und das nicht so super toll funktioniert.
Ich gehe sogar soweit zu behaupten, dass COM niemals mehr benutzt werden sollte und jeder! andere Ansatz besser (weniger schlecht) ist.
Noch zur Sache:
Du könntest den Report-Teil ja als eigene Applikation laufen lassen.
Werf ihm die Daten als XML hin und lass eine deine Report-App drüber laufen, oder biete das ganze als REST-Service an. Gibt da einige Möglichkeiten.
Die Frage ist auch noch, wann du deinen .Write-Befehl überhaupt absetzt. Im KeyDown-Event oder so?
Bist du mal mit dem Debugger dahin?
Bei SendKeys.Send steht in der Doku übrigens {DOWN} und nicht {down}. Kein Plan ob das einen Unterschied macht, aber als Entwickler solltest du auf so Kleinigkeiten achten.
public string Nummer => this.Fields[nameof(Nummer)];
public Dictionary<string, string> Fields = new Dictionary<string, string>()
{
{nameof(Nummer), "Das ist NUMMER"},
};
Ansonsten noch ein Link zur Info: DynamicObject Class
Sowas sollte aber nur in absoluten Ausnahmefällen Anwendung finden.
Vor 20 Jahren habe ich die Schul-PCs bei Bedarf mit einem Image überbügelt. Die Benutzer-Profile lagen im Netz.
Du könntest auf dem IPC auch eine Virtuelle Maschine laufen lassen und das entsprechende Image immer wieder herstellen.
Zu deiner Frage:
Du kannst und solltest über das Rechte-System verhindern, dass die Benutzer auf dem PC 'rumspielen'. Der Benutzer im 'IPC' sollte in einem eingeschränken Kontext laufen. Das ist aber ein ziemlich weites Feld, in das du dich erstmal einlesen solltest.
Aber was auch gut sein kann ist dass ich die formel nicht richtig benutzt habe.
Denn ich weiß nicht was RGB sein soll.
Deswegen ist es so wichtig, dass du als Fragesteller erklärst, was du schon versucht hast und woran es scheitert. Das du dich mit dem Thema RGBx beschäftigst, bin ich davon ausgegangen, dass du weißt was das ist.
R, G und B stehen für den jeweiligen Farbanteil: (Rot, Grün, Blau). (255, 0, 0) ist reines Rot.
RGBW hat noch einen Weißanteil, damit kann man ungefähr die Helligkeit steuern.
Willst du RGBW in RGB umwandeln, dann geht diese 'Helligkeits'-Information verloren.
Das musst du dann durch eine entsprechende Umrechnung kompensieren.
Beispiel:
Du hast RGBW (120,50,20, 60):
Der Rot-Anteil (R) ist 120.
Den Rotanteil (R') für das Ergebnis kannst du mit der Formel ausrechnen:
RGBW=RGB+(255-RGB)*W/3/255
G + B erstmal ignorieren und etwas umstellen:
R' = R - [(255-R) * (W/3/255)]
R' = 120 - [(255-120) * (60/3/255)]
R' = ~110
Das Gleiche für G und B machen und du erhälst:
(110, 56, 29)
So könntest du es mal probieren. Wie es sich auf dem entsprechenden Gerät tatsächlich verhält, ist natürlich noch so eine Sache. Exakt gleich wird es sich nicht einstellen lassen.
PS:
Ich möchte an der Stelle noch erwähnen, dass ich keine Ahnung von dem Thema habe. Also wenn ich groben Unfug erzählt habe, mich bitte darauf aufmerksam machen.
Jedoch bringt er mir immer den Fehler das "ReadBodyName" nicht als extern oder abstrakt gekennzeichnet ist , wenn ich "extern" davor schreibe bringt er mir die Fehler:
- extern muss dem membertyp/namen vorangehen
- Methode muss einen Rückgabetyp besitzen
- der Name Obj ist im aktuellen kontext nicht vorhanden
Das Keyword extern ist dafür da um externe Methoden zu deklarieren. Wenn man zum Beispiel eine C++-dll einbindet. Megadotnet.dll ist eine .NET-dll und der C#-Compiler kann die Deklaration aus der dll entnommen werden. Die Lösung hat Abt schon beschrieben.
Ich habe auf die schnelle keine Beschreibung der API gefunden. Kannst du bitte einen entsprechenden Link schicken?
Das mit den Bildern ist eigentlich ein gutes Beispiel. Angenommen du willst eine Vorschau mit maximal 10 Bildern anzeigen, aber nicht alle 4000 Bilder gleichzeitig laden, dann kannst du mit yield nur jeweils die benötigten Bilder für die Vorschau laden.
Dein Code ist nicht ganz korrekt.
public IEnumerable GetAllImages(IEnumerable<string> imagePathes)
{
foreach (var imagePath in imagePathes)
{
yield return Image.FromFile(imagePath]);
}
}
- Die Navigation in einen NavigationService auslagern und diesen (z.B. per Dependency Injection) an alle ViewModels übergeben. Dann kannst du diesen Service von überall verwenden, um zu einer Seite zu navigieren, und das MainViewModel kann auf die Änderungen reagieren.
Wenn deine Klassen generiert worden sind, kann es sein, dass sie das Keyword partial vor dem class haben. Dann kannst du die generierte Klasse mit eigenem Code erweitern.
Nachdem ich ihn davon überzeugt hatte, dass man Daten aus pdf-Files sehr gut exportieren kann
Kannst du uns davon auch überzeugen?
Abgesehen davon, ob json oder xml, es kommt natürlich auf den Anwendungsfall an. Brauche ich xml nicht aus einem bestimmten Grund, verwende ich eher json, weil es etwas schlanker ist und mit newtonsoft so schön einfach zu verwenden.
Klasse Auto hat Instanzen der Klasse Autositz und Fahrer.
Nun will die Klasse Autositz rausfinden welcher Fahrer gerade im Auto ist.
Er müsste somit die Klasse Auto fragen. Nur wie greift Autositz auf Auto zu, wenn es nicht sowas wie eine Parent Eigenschaft gibt.
Es gibt bei modernen Autos die Möglichkeit, die Sitzeinstellung zu speichern und per Knopfdruck auszuwählen. Das heißt der große Fahrer mit den langen Beinen muss sich nicht ins Auto zwängen, weil seine Frau vorher gefahren ist, sondern er drückt auf einen Knopf und der Sitz fährt automatisch auf seine Position.
Wenn ich die Anforderung so lese, dann kommt mir die Idee, dass wir eine Klasse SitzEinstellung brauchen. Die Klasse Sitz muss den Fahrer nicht kennen, sondern hat eine Methode FahreInPosition(Sitzeinstellung). Aufgerufen wird diese Methode (je nach Anwendungsfall) vom Auto, denn da ist ja auch der Knopf dran.
Durch diese Denke ergeben sich fast automatisch übersichtlichere Klassen, mit spezifischer Verantwortung.
Nach DomainDrivenDesign könnte in diesem Beispiel das Auto das AggregateRoot sein. Es gibt ein bestimmtes Auto (Entity), in das ein bestimmter Fahrer einsteigt (nur eine Id notwendig). SitzEinstellung wäre dann ein ValueObject, Sitz eventuell auch. Die Kommunikation mit der Umwelt, oder dem Programm wird über das AggregateRoot Auto gemacht.
DomainDrivenDesign soll nicht überall angewendet werden, gehört meiner Meinung nach aber zur Bettlektüre vom professionellen Entwickler, da es das Denken ungemein erweitert.
Meine Frage nun: Wie löss ich das am besten ohne jetzt das Aggregate aufzubohren?
- In jedem UseCase via Repository Interface die items manuel registrieren lassen? Hört sich für mich sehr unsauber an
- Irgentwie im Infrastrucuture.Data Layer versuchen AddItem via Domain Events abzufangen und registrieren zu lassen?
- Im Infrastrucuture.Data Layer versuchen die AddItem zu overloaden und im Repository by Add() abzufangen?
- Besser vorschlgäe oder elegantere Lösungsansätze?
Alles wesentliche hat Abt schon gesagt.
Ich habe festgestellt, dass die Auswahl des richtigen Weges zu stark von der Anforderung abhängig ist, als dass man sich auf einen Festlegen könnte.
Grade Beispiel-Implementierungen und Test-Projekte geben die nötige Komplexität für tiefergehendes Verständnis nicht her.