In Silverlight gibts die Methode nicht. Du hast ja auf die Framework Doku oben verwiesen, nicht auf die von Silverlight. Schau dir die Doku von der ObservableCollection mal von Silverlight an, dann siehst du, dass es die Methode dort einfach nicht gibt.
Dann hast du den Vorschlag aus dem anderne genannten Thread aber nicht richtig umgesetzt. Ich sprach dort von einem Canvas als ItemsPanel für dein ItemsControl und nicht davon im ItemTemplate ein Canvas zu benutzen. Für die Items werden nur die entsprechenden Attached Properties gesetzt um diese dann innerhalb des ItemPanels zu positionieren.
Ist das sowas wie beim Laden von Resourcen aus anderen Assemblies?
Genau sowas sollte es sein :)Was dir eigentlich bei der URI zum Bild nur fehlt ist der Assemblyname, der sollte sich aber bekommen lassen über den Typen des Plugins. Hier wird der gleiche Vorschlag gemacht.
Zitat
Ist es einfacher, wenn ich das Icon in der Plugin-Dll als Resource habe und nicht einfach als Datei
Muss es unbedingt sein für obige Variante.
Zitat
es wäre ja auch noch denkbar, das Plugin-Icon einfach dorthin zu kopieren und von dort zu laden
Damit wäre dein Programm auf "normalen" PCs nicht mehr lauffähig weil eingeschränkte User, wies heutzutage Standard ist, keine Schreibrecht im Programmverzeichnis haben.
... und wenn ich das Binding über die
ObservableCollection also so:
ObservableCollection<EquipmentObject> equipCollection = new ObservableCollection<EquipmentObject>(equipmentObjects);
ListCollectionView equipments = new ListCollectionView(equipCollection);
equipments.GroupDescriptions.Add(new PropertyGroupDescription("description"));
dataGrid1.ItemsSource = equipCollection;
mache funktioniert das binding nicht mehr und dementsprechend das Groupuing natürlich auch nicht.
Da ist doch gar kein Binding involviert? Das ist doch ne einfache Zuweisung der Daten. Wie dem auch sei, du erstellst zwar ne CollectionView mit dem Grouping, aber verwendest sie doch gar nicht. Du nutzt ja die AusgangsCollection. Das kann dann natürlich nicht tun.
zu 1.: Er kann das Command nicht finden, da der DataContext ja nen ganz anderer ist. Im funktionierenden Beispiel ist der DataContext ja das mainViewModel. In der Liste dagegen ist der DataContext ja das Item, für das das Template angewendet und nicht dein mainViewModel.
zu 2.: Hat nichts mit DataBinding zu tun, sondern dem Canvas was da im Template eh völlig überflüssig ist. Die Canvas haben ne Größe von 0 und daher ist auch Sicht des ScrollViewers alles paletti da ja alle Items reinpassen.
erstmal muss man festhalten das grad moderne Handys nur noch selten was direkt auf der SIM Karte speichern.
Dann ist deine Frage aber trotzdem noch alles weitere als klar. Mit was für ner Technologie arbeitest du denn? Meistens hat man eh keinen direkten Zugriff auf die SIM sondern die API der Plattform kapselt das ganze. Dann musst du auch nicht pollen, sondern bekommst durch die API mitgeteilt wenn eine neue Nachricht kommt.
Pollen wäre bei der SIM übrigens fatal. Es ist auch nur nen Flash Speicher drin und laut SIM-Karte gibts sogar festgelegte Zyklen nachdem sich manche deaktivieren.
Erfolgt die Auflstung innerhalb des ItemsConrol in einen StackPanel?
Ja, zumindest defaultmäßig wenn man nichts anderes einstellt.
Die Idee von dir ist gar nicht schlecht. Scheitern tut es aber schon im Ansatz daran, das du ja im Template ebenfalls nen StackPanel hat. Sprich der Button wird im Template schon richtig mit dem Margin angeordnet, aber auch nur im inneren StackPanel, das ItemsControl weiß von dem aber gar nichts und bekommt die ganzen StackPanels als Children welche es wiederum ganz normal anordnet.
Setzt als ItemsPanel ein Canvas und verwende statt Margin die attached Properties von Canvas um die Position der Items dort drin zu setzen. Es macht keinen Sinn StackPanels zu verwenden, wenn du eigentlich absolut positionieren willst.
Um Items unterschiedliche Templates zu geben, benutzt man den ItemTemplateSelector.
Was aber keinesfalls geht ist, Items aus unterschiedlichen Quellen anzuzeigen. Entweder packt man die Items in die Items Collection oder man setzt ItemsSource auf die Quellaufzählung. Mischen geht aber nicht. Daher musst du dafür sorgen, dass du eine gemeinsame Datenquelle hast.
das du erst einen Screenshot erzeugst, erwähnst du ja gar nicht im Ursprungsbeitrag. Da kann man dann durchaus das CopyFromScreen verwenden. Aber aus dem Bitmap kannst du natürlich ein WriteableBitmap erzeugen. Mit LockBits holst du dir vom Bitmap die BitmapData und mit den Infos kannst du mit WriteableBitmap.WritePixels die Daten übernehmen.
Ansonsten gibst den sonst üblichen Weg von Bitmap in BitmapImage und mit dem BitmapImage kannst du dann ne WriteableBitmap erzeugen.
Dann war "component" schon richtig, du musst es wahrscheinlich bei beiden ohne "s" schreiben oder hast du wirklich 2 verschiedene Ordner, einmal mit "s" und einmal ohne?
Es gibt weder den einen, noch den anderen, siehe WPF Pack URI, woher das component dort drin kommt.
Selbst wenn die URIs aber richtig gezogen werden, wirds immer noch nicht tun, da MediaElement kein Abspielen von embedded Resourcen unterstützt. Man bekommt auch einen entsprechenden Fehler wenn man mal einfach das MediaFailed Event vom Media Player aboniert.
um zu sagen wie man das schneller macht, muss man erstmal wissen woran es liegt, dass es so lang dauert. Ist es das Holen der Logs der anderen Rechner, das Eintragen in die Datenbank oder das anschließende verarbeiten?
Erster Fehler - Doku nicht gelesen...
In der Doku zur Bitmap.GetHBitmap Methode steht
Zitat
You are responsible for calling the GDI DeleteObject method to free the memory used by the GDI bitmap object.
Da du das nicht machst, wird dann Speicher natürlich zugehaun.
Zweiter Fehler:
Von hinten durch die Brust ins Auge...
Wozu zum Teufel lässt du dir von einem Bild, wo du ja anscheinend als ImageSource direkt vorliegen hast
Zitat
...ich lasse mir ein Bild anzeigen...
ein Windows Forms Bitmap erzeugen um das zu editieren und dann noch zusätzlich über umkopieren von unmanaged Spiecher wieder ein WPF ImageSource zu erstellen?
Benutz einfach die WriteableBitmap Klasse von WPF und gut ist.
Selbst ohne das selbstverursachte Memoryleak von dir verbraucht deine Variante wesentlich mehr Speicher als die reine WPF Variante da du ja bei jedem MouseMove neue Bilder erzeugst. Es reicht doch nur bei dem einen bestehenden jeweils die Pixel zu setzen.
Das Control sollte sein Parent egal sein. Trotzdem hast du die Lösung schon erhalten. Du kannst dir einfach ein RoutedEvent mit Tunneling erstellen. Dann bekommst du auch in dem Child das Event wenn das Window es auslöst.
Aber auch der Hinweis auf das ViewModel von ErfinderDesRades ist natürlich korrekt. Gerade wenn du sagst Zustand willst du ja auf gemeinsame Daten zugreifen.
PreviewMouseDownEvent ist eigentlich ein Attached Event der Mouse Klasse. Das PreviewMouseDown Event im Window und im StackPanel sind exakt das identische Event, sie sind nämlich nur Aliase auf das Attached Event der Mouse Klasse und werden auch nicht durch Window bzw. StackPanel deklariert, sondern schon allgemein von UIElement.
schreibst, abonierst du das Event beim StackPanel.
Nichtsdestotrotz ist das hier völlig irrelevant da das PreviewMouseDown Event natürlich nen Tunneling Event ist. Daher abonier das einfach wo du willst und du musst einfach nur aus den Argumenten beachten wer der OriginalSender ist.
alternativ kannst du einfach .Net 4.5 verwenden falls bei dir möglich. Damit kannst du auch Win32 Content animieren. Das ist bis Version 4 einfach nicht möglich.
da die Höhe nicht explizit gesetzt wird, scheints die Defaulthöhe zu sein.
Man darf bei dem ganzen nicht vergessen, dass der Webbrowser eigentlich kein reines WPF Control ist, da das HTML Rendering ja vom IE ActiveX Control übernommen wird, und man da eh beim Layouting massive Einschnitte hat. Daher nehm ich mal auch an, dass er die Inhalte nicht automatisch layouted und seine Wunschgröße ermittelt (Was bei HTML Seiten auch bissle schwierig ist, da das Layout nur in wirklich wenig Fällen eine absolute Größe vorschreibt)
in was für Fällen soll das Ergebniss falsch sein? Das Ergebniss ist halt so, wie Equals implementiert ist. Wenn man Wertetypen hat, oder Referenztypen die sich wie Wertetypen verhalten (wie z.B. string), dann kann man die so nicht einsetzen in Binding Szenarien. Wenn man zwei Objekte von Werttypen anlegt mit gleichen Eigenschaftswerten, dann sind diese gleich, da kann man mit Equals die Objekte nicht mehr auseinander halten. Wenn man z.B. direkt eine StringCollection bindet, welche 3 mal "Hans" enthält und setzt das SelectedItem auf "Hans", dann ist es purer Zufall welches der 3 Items ausgewählt wird.
Was für Typen bindest du denn? Wenn du die selber erstellt hast, musst du halt Equals wie gewünscht überschreiben.
. Da steht nichts davon, dass die Datei lokal vorhanden sein muss. Warum sie nicht konsequenterweise URI statt string als Datentyp benutzen weiß ich auch nicht.
Zum Problem: Wieso meinst du UpdateLayout aufrufen zu müssen? Wenn dein Binding richtig funktioniert, dann bekommt die GUI doch mit, dass du neue Daten hast und aktualisiert automatisch die Anzeige. Im RunWorkerCompletet Event kannst du übrigens problemlos die GUI ändern, da der Eventhandler auch im GUI Thread läuft, ansonsten gilt halt wie immer [FAQ] Controls von Thread aktualisieren lassen (Control.Invoke/Dispatcher.Invoke)
Applikationsresourcen sind ja nochmal was anderes als die Dateiressourcen wo ich den Link geschickt hatte. Aber nutzen kann man die natürlich schon.
Zum Fehler: Image ist in WPF das Control welches Bilder anzeigt, die eigentlichen Bilddaten sind Objekte welche vom Typ BitmapSource bageleitet sind, wie z.b. BitmapImage. (In Windows Forms war das anders. WF Image == WPF BitmapImage, WF PictureBox == WPF Image)
Controls packt man nie in Ressourcen, gerade aus dem Grund welche dir die Fehlermeldung nennt. Du legst dort stattdessen Objekte vom Typ BitmapImage an und verwendest die an den jeweiligen Stelle als Source für die Image Controls.
ja, dann eher Custom Control. Schau mal hier, was man da alles beachten muss und wie man ein Custom Control richtig erstellt. Dann sollte es eigentlich auch tun mit dem ContextMenu da das ja einfach nur von Framework Element vererbt wird.
Dein Code ist komisch. Du sagst du willst ein UserControl, hast aber als Root Knoten im XAML ein TreeView. Wenn das nen UserControl werden soll, muss das auch nen UserControl sein. Bei dir siehts mehr nach einem Custom Control aus. Dort würde man dann aber wiederum nicht so mit XAML arbeiten, sondern das Aussehen des Controls in einem Style festlegen.
Was solls jetzt werden, ein Custom Control oder ein User Control?
Zusätzlich zu dem von FZelle gesagtem: Auch wenn man Code nur schnell per Hand schreibt, bitte auf Konsistenz achten, da man sonst gar nicht weiß wo man anfangen soll nach Fehler zu suchen. Du sagst du hast ein UC namens Tree und postest dann XAML Code wo steht TreeView, TreeViee und verwendet wirds dann doch wieder mit Tree...
so macht man das in WPF nicht. WPF hat ein eigenes, viel einfacher zu benutzendes Resourcen System. Einfach bei den Bildern als Build Action Resource einstellen und dann kann man bequem über die URI zugreifen.
ich persönlich finde das Design gut. Es gibt meiner Meinung nach einen konsistenteren Eindruck, gerade weil MS anscheinend ja auch die Applikationen daran anpasst. Der RC von VS 2012 z.B. passt sich ja nahtlos in das von dir im Screenshot gezeigte Design ein und auch von Office gibts diese Metro Design Screenshots.
Die Transparenzen vom Aero Design von W7 find ich schon praktisch an vielen Stellen (durchscheinend in der Titelleiste, so dass man sieht was drunter ist), könnte aber auch ohne die leben.