steinadler

Ah okay, das heißt, das Paradebeispiel von Ninject public class WarriorModule : NinjectModule { public override void Load() { Bind<IWeapon>().To<Sword>(); Bind<Samurai>().ToSelf().InSingletonScope(); } } ergibt auch nur Sinn, solange man beim Programmstart festlegt, ob man "Sword" auswählt. Wenn man nun das Werkzeug während der Programmlaufzeit wechseln möchte, also als "Sword" etwas anderes machen? Das würde doch dann auch nicht mehr mit DI funktionieren oder? Ich habe bisher immer konventionell ohne DI programmiert, mit Ereignissen usw.

Es ist eher so, dass der Kunde einen Sensor kauft und die PC-Software permanent aktuell hält. Daraus ergibt sich: (alter) Sensor neue Software. Inzwischen gibt es jedoch eine neue Sensor-Firmware, welche von der bereits aktuellen PC-Software schon unterstützt wird. Man musste bisher immer Firmware aktualisieren und dann die Software neu starten. Diesen Neustart möchte ich gern verhindern. Oder: Kunde trennt die Verbindung zum Sensor und tauscht den Sensor zu einem neueren Modell, welches auch von der Software unterstützt wird. Ich müsste also meine Geräteinstanzen während der Programmlaufzeit irgendwie austauschen können. Wie gesagt, vielleicht ist DI dafür aber auch nicht gemacht.

Es handelt sich dabei um eine Assembly, welche sämtliche Firmwareversionen des Sensors abdeckt. Man hat ein SensorBuilder-Klasse mit der man Connect() aufruft und irgendwann per Event ein Interface auf den Sensor zurückbekommt. Die Assembly ändert sich praktisch nicht, nur die Firmwareversion des Controllers.

Die Begriffe Controller und Steuerung sind etwas unglücklich gewählt, das stimmt. Controller ist ein Mikrocontroller und Steuerung ist eigentlich eine StateMachine/Schrittkette. Prinzipiell habe ich eine StateMachine, welche einen Ablauf beinhaltet (etwas wird vom Sensor eingelesen und der Controller verarbeitet es; anschließend gibt ein Drucker ein Etikett aus, z.B.). Diese Schrittkette gibt es im Programm nur einmal. Bisher habe ich dieser Schrittkette per Konstruktor jeweils die Instanzen von Sensor, Controller und Drucker übergeben. Problem: Macht man ein Firmware-Update des Sensors und verbindet den Sensor neu, dann wird eine neue Instanz des Sensors erzeugt, da für die neue Firmware eine spezielle Implementation benötigt wird. Durch die Constructor-Injection musste bisher immer nach Firmware-Update das Programm neu gestartet werden - das wollte ich gern vermeiden. Wie sage ich jetzt der Schrittkette, dass sich die Sensorinstanz geändert hat? Ich wollte die Schrittkette eigentlich nicht neu erstellen sondern nur die Sensorinstanz austauschen. Wenn DependencyInjection dafür völlig ungeeignet ist, dann mach ich es auf konventionellem Weg mit Events und einer Setter-Methode, die die Geräteinstanz austauscht.

Genau, diese dre Klassen. Ich habe noch jeweils eine Klasse SensorBuilder. Diese besitzen eine Connect-Methode und ein Event, welches ausgelöst wird, sobald eine entsprechende Instanz erzeugt wurde. Dieses Erzeugen passiert, nachdem während Connect() die Seriennummer und Version des Gerätes geprüft wurden. Das ganze läuft asynchron, bis eben das Event ausgelöst wird. Die Frage ist nun, wie ich die Instanz an meine Controller-Klasse weitergebe. Ich möchte ja gern DI nutzen. Aber ich habe bisher keine Möglichkeit gefunden, dass ich die Instanz des Sensors (z.B. beim neu verbinden) in meiner Controller-Klasse verändern kann.

Hallo, bei einem Projekt benötige ich zwei Geräte, einen Sensor und eine Steuerung. Ebenso habe ich eine Klasse 'Control' die beide Geräte miteinander kommunizieren lässt. Diese bekommt dann von Sensor und Steuerung jeweils eine Instanz. Allerdings bekomme ich erst nach dem Verbinden zum Sensor eine entsprechende Instanz zurück (je nach Firmware-Version). Wenn ich mich nun während der Programmlaufzeit vom Sensor trenne und neu verbinde, könnte es sein, dass sich die Instanz des Sensors ändert. Wie übergebe ich denn meiner 'Control'-Klasse am besten die beiden Instanzen? Lässt sich das per DependencyInjection überhaupt umsetzen (aktuell nutze ich Ninject)? Oder erzeuge ich besser eine übergeordnete Klasse 'Device' welche meine beiden Geräteinstanzen enthält und übergebe diese der 'Control'-Klasse? Danke schonmal

Das kommt drauf an, ob man jede angefangene Stunde rechnet. Rein fürs Schauen würden theoretisch paar Sekunden ausreichen. Das läuft darauf hinaus, dass eine Vergütung gegen Null geht, aber man trotzdem (gerade am Wochenende) eingeschränkt ist.

Was es dem Kunden nützt, steht auf einem anderen Blatt - das ist jetzt so gegeben. Evtl. geht der Kunde davon aus, das meist schon eher jemand am Apparat ist, das ist aber sein Problem. Wie Maniska sagte, alle 6 Stunden aufs Telefon schauen. Nach obiger Rechnung gibt das je Woche 21,3 Stunden (128 geteilt durch 6). Setzt man jetzt hierfür den normalen Stundenlohn an? Habe irgendwo auch mal was von 12,5% vom normalen Stundenlohn gelesen.

Deswegen habe ich extra nen Thread gestartet, da ich über solche Zeiten nicht viel weiter gefunden habe.

Rein theoretisch müsste man ja aller 6 Stunden aufs Telefon schauen. Fraglich wäre, welche Zeit man dann als "Rufbereitschaftszeit" ansetzen kann. Eben diese 2,6 je Wochentag?

Die 2,6 Stunden? Die verbleibende Resttageszeit (24-8 = 16) geteilt durch die Reaktionszeit, in der man zurückgerufen haben muss. Fällt die Anlage um 22 Uhr aus hätte man ggf. innerhalb der 6 Stunden die Anlage wieder am Laufen, falls man telefonisch weiterhelfen kann.

In dem Fall ist gemeint: innerhalb 6 Stunden muss man per Telefon reagiert haben (Telefonbereitschaft).

Für die reine Bereithaltung? Und die Stundenanzahl laut meiner Rechnung oben?

Wie fließen da die Reaktionszeiten ein? So hier: Wochentag: 16 Stunden / 6 Reaktionszeit = 2,6 Stunden Sa/So: 24 / 6 = 4 Stunden Macht für die Woche: 5 Tage * 2,6 Stunden + 2 Tage * 4 Stunden = 21 Stunden Korrekt? Es geht hier rein um die Vergütung der Bereithaltung zur Rufbereitschaft; die einzelnen Anrufe/Einsätze werden gesondert vergütet.

Hallo ihr Lieben, folgende Randbedingung: Rufbereitschaft mit einer (Telefon-)Reaktionszeit von 6 Stunden, vor Ort 24 Stunden (in dieser Zeit muss man beim Kunde sein). Mo-Fr. von 16-07 Uhr. Sa./So. ganztags Was für eine Vergütung würdet ihr da ansetzen? Im Netz habe ich nichts über diese Reaktionszeiten gefunden. Danke für eure Meinungen

Dann habe ich in jeder Zeile und in jeder Spalte den Wert des Parameters1 stehen, oder?

Sowas wird es wohl werden müssen. Nur benötige ich dann ja für jeden einzelnen Parameter eine entsprechende MyCustomTextBlock-Instanz. An ein DataGrid kann man soweit ich weiß nicht ein Template je Zeile binden. Wollte halt gern ein DataGrid, um - ähnlich wie beim VS-Eigenschaftenfenster - das schön gruppieren zu können.

Genau das ist der Punkt. Im Moment habe ich ein Tool, das alle Zeichenfolgen im XAML in ResourceDictionary packt. Dort stehen dann die zugehörigen Übersetzungen drin. Ändere ich einen Eintrag im ResourceDictionary (dies passiert auch beim Änderun der Sprache), wird dann die GUI aktualisiert. Mir widerstrebt nur im Moment, dass ich die Liste im ViewModel je nach Sprache zusammenbauen muss. Ich dachte eher an soetwas: xaml: <array> <item group="common" text="englishNamedParameter" value="{Binding myParameter1}" unit="s" stringformat="f3" /> <item ... /> </array> somit würde die automatische Übersetzung wieder passen. Nur soetwas bekomme ich momentan nicht an das DataGrid gebunden.

Hallo, ich nutze in meiner Software das MVVM-Pattern. In einem Fenster möchte ich ein Datagrid mit Werten anzeigen (Name, Wert, Einheit). Nun stellt sich mir die Frage, wo ich die Liste erzeuge: im ViewModel oder in der View? Erzeuge ich sie im ViewModel müsste ich die Liste dort entsprechend der eingestellten Sprache befüllen und Darstellung des Zahlenformats jeweils angeben. Erzeuge ich die Liste im Xaml (View), kümmert sich meine LanguageEngine um die Sprache - ich scheitere nur bisher daran, diese Liste so umzusetzen. Hat jemand eine Idee?

Hallo ihr, ich habe eine Klasse, die Arbeit per Thread ausführt. Wenn ich nun aus diesem Thread per Event mit meinem Hauptfenster kommunizieren will, muss ich das ja per Invoke in den GUI-Thread umleiten. Angenommen meine Klasse hat noch weitere Events, macht man das dann so, dass die Events der Klasse alle aus dem selben Thread kommen (d.h. ich müsste das Event aus dem Thread in den Erzeuger-Thread der Klasse umleiten), oder macht man das dann erst an zentraler Stelle, meinetwegen im ViewModel?

Stimmt, das geht natürlich. Ich hatte halt der Faulheit halber per Drag-Drop den Bereich markiert und die Formel nicht weiter angepasst. Danke

Hallo zusammen, Excel 2010: A1: 1 A2: 2 A3: 3 A4: 4 A10: =Summe(A1:A4) Trage ich in Zeile A5 was ein, wird die Formel in A10 automatisch auf den Bereich A1 bis A5 angepasst. Das ist mir etwas zu viel Intelligenz, die Excel da mitbringt. Lässt sich diese Anpassung irgendwie umgehen? Wenn ich die Formel in C1 platziere, wird nichts erweitert, sondern es erscheint eine Hinweismeldung. Danke

Hallo ihr, ich wollte mir jetzt über den XmlSerializer eine Menge Arbeit ersparen. Blöderweise muss ich dazu ja sämtliche Eigenschaften public machen. Ist das ein sinnvoller Weg? Oder implementiere ich lieber IXmlSerializable? Danke

Hallo ihr, ich habe eine FixedPage in einem FixedDocument erstellt. Auf der Page ist eine Linie gezeichnet. <Line Stroke="Black" StrokeThickness="1" SnapsToDevicePixels="True" StrokeDashArray="4 4" Grid.ColumnSpan="3" X2="{Binding ActualWidth, RelativeSource={RelativeSource Self}}" HorizontalAlignment="Stretch" VerticalAlignment="Bottom" /> Wenn ich das im ReportViewer anzeige oder als XPS drucke ist alles okay. Wenn ich aber an einen Drucker schicke, wird mir das StrokeDashArray mit viel zu geringen Abständen gedruckt. An was liegt das? Wie kann man das umgehen? Danke schon mal.

Zum Beispiel: Klasse "Mensch": Methode "SetzeAlter(int alter)" Hier macht int doch keinen Sinn, oder? Fehlersicherer (zur Entwicklungszeit) wäre doch uint, oder sehe ich das falsch? Negatives Alter ist ja Quatsch.