OK vielen dank hat funktioniert. Es ist aber wahrscheinlich für andere wichtig noch zu sagen dass
panel3.Background = new SolidColorBrush(Color.FromArgb(255, 0, 200, 0));
nicht klapt da man noch Windows.UI eingebunden haben muss. So war das jedenfalls bei mir also so klapte es
panel3.Background = new SolidColorBrush(Windows.UI.Color.FromArgb(255, 0, 200, 0));
Trotzdem danke an deine Hilfe.
Hallo,
ich würde dem User gerne mit einem Fortschrittsbalken anzeigen wie lange es noch ungefähr dauert bis die Daten aus der DB geladen sind.
Die Daten hole ich über das EntityFramework aus der DB und erstelle aus einer IQueryable eine Liste. Das kann je nach Filter ein paar Sekunden dauern, weil ziemlich viele Datensätze in der DB stehen.
Gibt es eine Möglichkeit dem User diesen Fortschrittsbalken anzuzeigen oder habe ich hier nur die Möglichkeit dem User ein AnimationsIcon (wie im WEB) oder ein Infotext anzuzeigen, dass die Daten noch geladen werden?
Habe es bereits über die Progressbar und ReportProgress probiert, aber ich weiß nicht an welcher Stelle ich den ReportProgress aufrufen soll, weil ich ja keine Zählerschleife verwende.
Vielen Dank für eure kreativen Vorschläge
LG, Auraya
Hallo,
vielen Dank für deine Antwort. Ich habe es mittlerweile anderes gelöst:
ich lese die Daten aus bevor ich den BackgroundWorker nutze und übergebe diese dann der RunWorkerAsync-Methode des BackgroundWorkers. Die Daten erhalte ich in der DoWork-Methode über den EventArgs Parameter
private void btnSearch_Click(object sender, EventArgs e){
var daten= new MyClass(){ a= txtA.Text};
worker = new BackgroundWorker();
worker.DoWork += new DoWorkEventHandler(worker_DoWork);
worker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(worker_RunWorkerCompleted);
worker.RunWorkerAsync(daten);
}
void worker_DoWork(object sender, DoWorkEventArgs e)
{
var daten=e.Argument;
this.result = getDataAsList(daten.a);
}
Hi zusammen,
ich danke euch für die Unterstützung, es lag tatsächlich daran das ich aus der Main Methode meine, als public definierten Methoden, aufrufen wollte.
Habe diese Methoden nun in eine neu angelegte Klasse verschoben und schon geht es.
Jetzt werde ich mich noch ein wenig an die Schönheit und Kommentierung der diversen Passagen machen.
Vielen Dank
Nein im Entwurf Spalten anfügen. Die Zellen dieser Spalte greifen dann über verschiedene Tabellen auf einen Wert zu.
Seltsamerweise funktioniert es, wenn die Daten in die Tabelle direkt über Access eingetragen worden sind. Wenn diese aus dem Programm kommt dann nicht.
In Access sehen alle Einträge gleich aus.
asc schrieb:
Nur wird der DPI-Wert den WPF ausliest scheinbar nicht mit der Auflösung verändert, sondern fix z.B. aus den Systemeinstellungen übernommen. Theoretisch könnte sich dies irgendwann ändern, wenn OS und Monitore sich hier austauschen (und man die konkrete DPI-Angabe zur aktuellen Auflösung erhält).
Auf Multi-Monitor-Systemen wird man es wohl nie 100% garantieren können, da die verschiedenen Monitore ja unterschiedliche Pixelgrössen haben können.
Was empfiehlt sich für typsichere ID Typen zu verwenden - enums oder structs?
(ID wie in CountryID, PlayerID etc. -- das was man im DB-Jargon als Surrogate-Key bezeichnet.)
Das Ziel ist dass diese sich so ähnlich wie möglich zu Integers verhalten was Serialisierung etc. angeht, aber eben nicht implizit konvertiert werden können. (Implizite Konvertierung von ID-Typ -> Integer wäre OK, ist aber nicht nötig.)
Der Vorteil von enums wäre ganz klar dass man viel weniger Code braucht, und das mann bestimmte Konstanten für "Well-Known-Entities" ultimativ einfach definieren kann. Dafür mache ich mir Sorgen was z.B. Serialisierung angeht -- enum.ToString() spuckt ja den Bezeichner aus wenn es einen zum Wert passenden gibt. Das ist nicht wirklich erwünscht, da die Dinger u.A. auch in Service-Schnittstellen auftauchen, und ein Client nix damit anfangen kann wenn am Server eine "Well-Known-ID" dazugekommen ist, deren Bezeichner dem Client aber (nocht) nicht bekannt ist.
Der Vorteil von structs wäre dass man viel mehr selbst kontrollieren kann -- eben auch ToString() überschreiben, Interfaces wie ISerializable implementieren und zu was man sonst noch lustig ist.
Also, was meint ihr?
Ich weiss ehrlich gesagt nicht ob ich das machen würde.
Ich meine nur es ist eine 3. Möglichkeit die du nicht angeführt hast
(Bzw. andere Möglichkeit Variante A umzusetzen)
Ich weiss nur, dass ich auf jeden Fall alle Daten in einem Service-Aufruf übergeben wollen würde. (Ausgenommen natürlich Fälle wo "alle Daten" bedeutet dass man einen zig MB grossen Request bekommen würde.)
Hallo zusammen,
ich stehe auf dem Schlauch. Ich möchte eine Listbox durchsuchen und die Werte nacheinander mit einer Textbox vergleichen. Ist der gefundene Wert (in der Listbox) kleiner dem der Textbox soll er in der Listbox markiert werden.
Ich bekomme es hin das mir der gleiche Wert markiert wird, wie ich ihn in der Textbox eingebe.
public void kleiner()
{
int index = listBox1.FindString(textBox1.Text);
if(0 <= index)
{
listBox1.SelectedIndex = index;
}
}
Vielleicht kann mir jemand helfen, denn ich habe bereit eine Methode list.FindIndex gefunden. Aber ich bekomme die Umsetzung nicht wirklich hin. Würde mich über eine Unterstützung sehr freuen.
Das ist so meiner Ansicht nach nicht möglich, da Thickness eine Struktur ist und daher keine DependencyProperties anbieten kann, somit sind Left, Bottom,Right,Top keine Dependency Properties und du kannst nicht einzeln daran binden.
Du musst deine Thickness Struktur irgendwo in einem ViewModel halten und da dann entsprechend nur das Setzen der zweiten und dritten Parameter erlauben und dich aus der View an diese Thickness Instanz binden.
DB und DTO trennen macht IMO auf jeden Fall Sinn -- sehe ich ähnlich wie du. Das zu koppeln wäre unsauber und gefährlich.
Ich würde das einfach mal als "muss" festsetzen.
Wenn die Verwendung des EF auch "muss" ist, dann bleibt eh keine Wahl mehr, dann müssen da zwei Klassen programmiert werden.
Sonst, ohne EF, könnte man evtl. stellenweise die Daten direkt aus den Tabellen in die DTOs schaufeln und umgekehrt. (Wobei das vermutlich auch recht schnell unsauber wird, also wird es so oder so nicht ausbleiben dass man für jede DB-Entity eine Klasse bastelt.)
Was die Trennung DTO/UI angeht... pfuh. Weiss nicht. Macht vermutlich auch Sinn. Wobei ich mir auch immer denke "is ja irre, alles 3x machen, das muss ja einfacher gehen".
Ahoi,
ich hab nach einigem googeln und rumprobieren einen Out-Of-Process COM in C# gebastelt. Funktioniert soweit auch alles ganz gut, bis auf das gute alte Problem: deterministische Finalisierung.
Dummerweise weigert sich MS ja hartnäckig eine Möglichkeit für die Weiterleitung des "final release" des CCW zu schaffen.
Ich brauch aber mehr oder weniger deterministische Finalisierung (sprich "bald" reicht, "irgendwann" reicht nicht). Also hab' ich mir dazu ein hübsches Singleton gebaut wo alle COM Objekte registriert werden, und einen Thread der dann hin und wieder mal den CCW Ref-Count dieser Objekte kontrolliert -- und bei Ref-Count 0 Dispose aufruft.
Bei Objekten die vom Client per CoCreateInstance erzeugt werden funktioniert das auch ganz toll - da ist der CCW Ref-Count im Konstruktor bereits > 0.
Dumm ist es nur bei Objekten die ich im Out-Of-Process Server selbst instanziere (ganz normal mit new ), und dann als COM-Interface zurückgebe. Zu dem Zeitpunkt wo der Konstruktor läuft gibt es da natürlich noch keine COM Referenzen, das Ding ist ja erstmal ein ganz normales Objekt.
Wenn jetzt genau zur ungünstigsten Zeit mein "COM Object Disposer" Thread los laufen würde, würde dieser nen CCW Ref-Count von 0 feststellen, und das Objekt disposen.
Als Workaround hab' ich jetzt mal QueueUserAPC verwendet. Statt die selbst erzeugten Objekte direkt in die Liste einzutragen, beantrage ich einen Callback mittels QueueUserAPC (über PInvoke).
Und im Callback wird das Objekt dann eingetragen.
Das scheint auch zu funktionieren - anscheinend wartet der Thread der die COM RPC Aufrufe abarbeitet irgendwo in einem "alertable" Zustand, und das erst ausreichend spät, nachdem das zurückgegebene Interface bereits "gemarshalt" wurde.
(Natürlich ist diese Lösung auch alles andere als optimal, da man immer aufpassen muss dass nach QueueUserAPC kein eigener Code mehr kommt der alertable wartet, aber OK, damit könnte ich leben.)
Nur frage ich mich jetzt... ist das halbwegs sicher?
Bzw. fällt jemandem von euch eine bessere Möglichkeit ein freigegebene COM Objekte "einzuklauben"?
Eine Möglichkeit abzufragen ob der CCW für ein Objekt überhaupt schon erzeugt wurde würde auch reichen -- nur hab ich keine gefunden ( Marshal.GetIUnknownForObject ist einfach kommentarlos erfolgreich, selbst wenn das Objekt noch keinen CCW hat).
folgende Seite b hat mich auch zu diesem Thema ein wenig weiter gebracht. Also von daher Closed
http://stackoverflow.com/questions/8738010/get-linq-subquery-into-a-user-defined-type
Ich glaube nicht dass du das Parent manuell setzen solltest.
Wie wärs wenn du einfach den Button und die PictureBox auf/in das Panel legst ?
Du musst dann nur aufpassen welches du zuerst hinzufügst, je nachdem ist dann der Button im Vordergrund oder die PictureBox
Okey... Ich hab eine - für mein Problem - ETWAS einfachere Variante gefunden. Ich stand glaube einfach so ziemlich auf der Leitung... So sogar, daßa es mir peinlich ist...
Das nächste Mal durchforste ich erst mal mein eigenes Google, auch bekannt als Gehirn.
Danke für eure Hilfe..
berniebutt schrieb:
Ich muss mich konsequenter von alten Gewohnheiten in C oder C++ trennen und darf nichts einfach unbedenklich übernehmen.
So ist es. Es gibt eine Reihe von Dingen, die man in C# besser NICHT mehr macht, wenn man von C++ kommt. Ich habe diesen Lernprozess auch durchmachen müssen
http://msdn.microsoft.com/en-us/magazine/cc301520.aspx
http://msdn.microsoft.com/en-us/library/yyaad03b(v=vs.90).aspx
http://windowsdevcenter.com/pub/a/dotnet/2002/02/11/csharp_traps.html
Besser struct nur für einfache kleine Dinge einsetzen. Will man mehr, fertige Klassen verwenden oder solche selbst entwickeln.
Wie KPC schon sagte, ist das vielleicht wichtigste im Zusammenhang mit structs: Nimm sie nur selten und wenn, dann mach sie immutable. Für deine konkrete Anforderung wäre class besser.
@KPC cooler Nick
