Laden...

Forenbeiträge von talla Ingesamt 6.862 Beiträge

26.06.2012 - 15:24 Uhr

Hallo,

Der Style entspricht aber noch in keinster Weise deinem ursprünglichen Style (warum wolltest du denn überhaupt groß umbauen?)

Ursprünglich hast du ja nen Label gehabt gegen das du gebunden hast. Jetzt hast du ne Liste von Listen und jede dieser Kindslisten hat genau ein Kind und das wird durch den ContentPresenter angezeigt. Das ist doch Murks. Weder ist das Label drin (wenn du das nicht benötigst hättest du schon im ursprünglichen Style nen ContentPresenter verwenden können) noch machen so verschachtelte Listen irgend einen Sinn wenn sie jeweils nur ein Kindelement haben.

26.06.2012 - 15:07 Uhr

Hallo,

Ich seh jetzt erst, dass dein Control an sich arg verwirrend benannt ist. Du hast ja kein ItemsControl mit Header, sondern ein ItemsControl mit Items mit Headern. Das ist ja was ganz anderes. Das HeaderedItemsControl aus WPF ist dagegen das erste, sprich ein ItemsControl mit Header.

Wie schon gesagt, das Mausrad geht nicht wegen der Verschachtelung der ScrollViewer die so sicherlich nicht gewollt ist da, das Ergebniss ja ein ganz anderes ist wie in deinem ersten Fall.

Dein Style icInfoWithHeader basiert ja auf icInfoNoHeader. Das heißt das du erstmal all das aus icInfoNoHeader bekommst, inklusive dem ScrollViewer den du ja im Template festlegst. In icInfoWithHeader setzt du jetzt für die Items ein ItemsControl welches wieder icInfoNoHeader hat, sprich das Template von dem ItemsControl als Item hat wiederrum den ScrollViewer drin, welches im Template von icInfoNoHeader definiert ist. Dadurch die Verschachtelung.

26.06.2012 - 14:13 Uhr

Hallo,

Beim zweiten Style wolltest du sicherlich Template statt ItemTemplate benutzen oder? Durch das ItemTemplate verschachtelst du ja die Liste und dann hast du eigentlich zwei Scrollviewer ineinander und die kommen sich natürlich in die Quere mit den Mouseevents.

Achja, noch was: Es gibt schon im Framework ein HeaderedItemsControl. Das würd ich für den zweiten Fall verwenden.

26.06.2012 - 12:10 Uhr

Das ist genau nicht richtig. Er kann ja nicht ahnen, dass der Quellcode in einem anderen Projekt, dem entspricht, der die DLL erzeugt. Füg die Verweise als Projektreferenzen hinzu wenn sie in der gleichen Projektmappe sind. Dies sollte man sowieso machen um Probleme mit der Buildreihenfolge auszuschließen.

26.06.2012 - 11:41 Uhr

Hallo,

hast du die Referenzen auf die Projekte direkt als Projektreferenzen oder als Assemblyverweise? Im letzteren Fall kanns zu deinen Effekten kommen, im ersteren sollte es eigentlich nicht der Fall sein.

25.06.2012 - 21:20 Uhr

Hallo,

dass alle Instanzen von x erstellt werden nach einem neu instanzieren von x "gelöscht" oder eben neu zugeordnet werden. Nein, solange der GC die Objekte nicht aufräumt, läuft dein Timer munter weiter. Wenn er nicht mehr laufen soll, musst du ihn explizit stoppen.

Dass der Timer jeweils in einem eigenen Thread läuft ist mir soweit auch klar So kann man das nicht ganz sagen. Der Timer läuft an sich in gar keinem Thread weil die auf den Hardwaretimern basieren. Was in einem extra Thread läuft, ist der Eventhandler für das Timer Tick Event. Aber auch da kann man nicht von ausgehen, das alle in einem extra Thread laufen, da diese Threads aus dem Threadpool benutzen und der ist ja auch nicht ewig groß.

25.06.2012 - 10:55 Uhr

Hallo,

das du ein FileSystemNode bekommst ist doch richtig. Du kannst dir mit dem ItemsContainerGenerator das passende TreeViewItem in deinem Behaviour holen. Danmit gehts dann weiter mit den bisherigen Lösungen.

25.06.2012 - 08:16 Uhr

Wie schon in den anderen Umfragen hab ich wieder auf Deutschland getippt.
Glaube die volle Leistung haben wir bisher auch noch nicht gesehen, da sie noch nicht in der Situation waren, ein Tor aufholen zu müssen. Da ist noch mehr Potential drin.

England wäre mir zwar lieber gewesen, aber dann endet die Niederlagenserie gegen Italien halt am Donnerstag 😁

25.06.2012 - 06:41 Uhr

Name (Class1) | ID (Class2) | Text (Class2) | Test(Class2)

Du schreibst ja, dass Class1 ne Liste von Class2 enthält, wie soll das dann aussehen?


Name (Class1) |  ID (Class2) | Text (Class2) |  Test(Class2)
                 ID (Class2) | Text (Class2) |  Test(Class2)
                 ID (Class2) | Text (Class2) |  Test(Class2)

So?

Sollte es nur bei einer Zeile bleiben, wie oben in deinem Beispiel, dann ist das einfach, da du dann einfach nur die Spalten des DataGrids manuell erstellen musst und dann entsprechend die Propertypfade zum zweiten Item angeben kannst.

25.06.2012 - 06:35 Uhr

Menno, da fall ich immer wieder drauf rein. Ist aber auch arg verwirrend, da laut MSDN SelectedItem extra noch als Bindable mit dem BinadableAttribut gekennzeichnet wird.

Hier gibts ne Diskussion mit ner Menge Möglichkeiten wie man das umgehen kann.

24.06.2012 - 23:15 Uhr

Hallo,

ich seh das Problem nicht. Du sagst dein ViewModel hat ein Property für das SelectedItem. TreeView hat das auch. Also brauchst du doch nur das SelectedItem der TreeView an das vom VM binden und schon ist die Frage

wie man die Information "TreeView.SelectedItem" sauber ins ViewModel bekommt.

doch gelöst.

24.06.2012 - 20:12 Uhr

Hallo,

was das Editieren von Objekte angeht, arbeitet das DataGrid mit dem IEditableObject zusammen. Wenn deine Datenklasse das implementiert, dann klappt das richtig, sogar mit Rollback, falls die Änderungen doch nicht übernommen werden sollen. Du musst dazu das DataGrid nicht manuell in irgend nen Modus bringen. Wenn Editieren erlaubt ist, dann wechselt es automatisch dahin, sobald der User ein Item editieren möchte.

24.06.2012 - 18:42 Uhr

Hallo,

Steuerelemente sind keine Daten und man sollte nie in Steuerelementen Daten halten. Wenn du Arbeitsabläufe hast, Listen mit Arbeitsanweisungen etc. sind das Daten. Benutz sowas wie nen ItemsControl und um für die entsprechende Darstellung zu sorgen, benutzt man Templates. Wenn du Daten und Aussehen trennst, kommst du erst gar nicht in die Probleme wo du jetzt hast.

Aus dem Stackpanel sind wohl die Controls aus dem VisualTree raus, aber im LogicalTRee hängen die wohl noch drin. Das geht nicht. Der VisualTree ergibts sich ja aus der Darstellung der Elemente im LogicalTree, daher kann nicht etwas im LogicalTree sein, was nicht im VisualTree ist.

24.06.2012 - 10:01 Uhr

Hallo,

Binding auf die Felder Auf Felder kann man nicht binden. Dass müssen Properties sein.

Die Liste ist ja dann auch nur ein Property gegen das du ganz normal binden kannst. Sprich, wenn du nen Template hast für eine Zelle wo z.B. wiederum ne ListBox oder sowas enthält, kannst du damit auch die Liste anzeigen. Aber so eine Master/Detail Ansicht direkt im DataGrid wie man es aus andere DataGrids kennt, wird vom WPF DataGrid nicht unterstützt.

23.06.2012 - 18:46 Uhr

Hallo,

VS bietet da nicht so viel außer der Ausgabe. Schau dir mal DebugView an, da hast du vielseitige Filtermöglichkeiten.

23.06.2012 - 16:43 Uhr

Hallo,

du widersprichst dich doch. In deiner vorherigen Nachricht hast du doch die Fehlermeldung gepostet, dass der Add Methode nen Frame Objekt übergeben werden muss und jetzt sagst du, dass die Add Methode den Frame erstellt.

Sicher das du nicht einfach hier

if (lyrics == null)
             {
                 title = FrameFactory.GetFrame(FrameFactory.UnsynchronizedLyricsFrameId) as TextFrame;
                 v2Tag.Frames.Add(lyrics);
             } 

statt title lyrics schreiben wolltest?

23.06.2012 - 16:15 Uhr

Ja, dass du erst nen Frame erstellen musst ist doch klar. Aber der kann doch leer sein. Bist du den Text aus der RichTextBox hineinschreibst ist er doch auch leer oder? Und statt halt null übergibst du so nen leeren Frame.

23.06.2012 - 13:06 Uhr

Hallo,

die Fehlermeldung ist doch eindeutig oder? Du versuchst einen Wert von null zu schreiben - was soll er da machen? Denke mal wenn du irgendwas sinnvolles schreibst, und seis nen leerer String statt null, sollte es auch keine Exception geben.

22.06.2012 - 15:58 Uhr

Kommentiere ich diese Zeile aus, ist das Verhalten in Ordnung. Also ist das Problem gelöst damit?

21.06.2012 - 16:49 Uhr

Das lustige ist eigentlich, dass wenn man nach "nvda wpf" sucht, die ersten paar Treffer Bugreports sind 😉 So super ausgereift scheint es wohl nicht zu sein.

Der Grund warum es aus VS direkt nicht geht, dürfte wohl der Hostingprozess des Debuggers sein. Warum das dann nicht tut, weiß ich auch nicht, aber das ist der einzige Unterschied.

20.06.2012 - 12:57 Uhr

Wobei es schon gehen müsste die Visibility als String anzugeben, weil es nen passenden TypeConverter dafür gibt. Trotzdem sollte man natürlich immer den richtigen Datentypen angeben um Fehler zu vermeiden und die Entwickler nicht zu verwirren 😃

20.06.2012 - 10:50 Uhr

Hallo,

30 Datensätze sind in der Tat nicht viel. Wie komplex sind denn die DataTemplates für die Items? Wenn die sehr komplex sind, zahlt es sich sicherlich aus, nicht die ganzen Daten komplett zu ersetzen, sondern nur die bestehenden mit den neuen Werten zu füllen. Dann muss die GUI nämlich nicht komplett neu erzeugt, sondern nur die aktualisierten Werte angezeigt werden.

20.06.2012 - 09:55 Uhr

Hallo Abt,

Geht es Dir wirklich nur um HTML5, CSS und Javscript, dann ist der Expression Web Editor das richtige. Das stimmt für den Augenblick ja auf jeden Fall, weißt du wie es aber mit der Metro Toolwelt aussieht? Blend wird ja in Zukunft auch dazu dienen Metro Apps mit HTML5 und Javascript zu gestalteten (siehe Creating HTML-based Metro style apps using Blend Beta) Gibts dort den Expression Web Editor dort dann überhaupt noch? Falls ja, dann wahrscheinlich nur für klassische Webanwendungen, nicht für Metro oder?

Denke für den Threadersteller ist die Frage auch nicht ganz uninteressant, deshalb hab ich sie gleich hier gestellt.

19.06.2012 - 16:16 Uhr

Hallo,

und genau das sagt der Fehler ja auch:

**Value **produced by BindingExpression is not valid for target property.; Value='0'

19.06.2012 - 13:29 Uhr

Hallo,

Hm, wenn ich in den Properties der TextBox schaue, hab ich bei Common / Text / Path den Hinweis "Path item could not be resolved". Aber der Code ist der dazugehörigen CodeBehind Datei...

Da du keine explizite Quelle fürs Binding angibst, wird gegen den DataContext gebunden - ist dieser auf das aktuelle Objekt gesetzt worden? Ansonsten ist der null und dann ist klar das er gegen nichts binden kann. Alternativ zum DataContext kannst du die Source ja explizit angeben.

Aber auch dann wirds nicht funktionieren. Du musst INotifyPropertyChanged implementieren, sonst kann das Binding ja nicht wissen, dass sich was geändert hat.

18.06.2012 - 17:12 Uhr

Hallo,

benutz als InputScope der Textbox einfach Default statt Text.

18.06.2012 - 15:44 Uhr

Hallo,

du hast in Prinzip zwar paar Schuhe hier.

Prism und MEF haben nichts damit zu tun, den Inhalt eines Containers zu ändern. Die bieten dir die Möglichkeit durch DI dein Programm zu modularisieren.

Das austauschen des Inhaltes eines Containers ist dagegen ja wa anders. Das setzt ja erst an, nachdem du die Module schon hast. Hier würde ich dir mal empfehlen die Navigation Features von WPF anzuschaun. Die werden imo viel zu sehr vernachlässigt, dabei sind sie recht mächtig. Vielleicht passen ja deine Anforderungen darauf.

18.06.2012 - 15:39 Uhr

Hallo,

was ist denn ViewModeWFItem fürn Typ? Ist der von DependencyObject abgeleitet? Falls ja, ist das der Fehler. DependencyObjects darf man nur ausm GUI Thread heraus erzeugen, da diese threadaffin sind (oder hier besser
dispatcheraffin)

18.06.2012 - 13:55 Uhr

Hallo,

wobie Sepa ja nur der Projektname ist. Die Übertragungsstandards dazu sind ja ISO20022 und EBICS. Fürs erste gibts sogar ne .Net Implementierung i20022 Project.

18.06.2012 - 12:34 Uhr

Hallo,

gar nicht. GUI Sachen laufen immer im GUI Thread, immer! Wenn der Viewer zum rendern lange benötigt, kannst du nichts machen. Sollte allerdings das Laden und Parsen der PDF so lang dauern kann man das natürlich schon auslagern in nem extra Thread und dann dem Viewer die geladenen Daten übergeben, wenn sie fertig geladen sind.

18.06.2012 - 11:12 Uhr

Hallo,

schau dir mal Procmon aus der Sysinternals Suite an.

13.06.2012 - 19:56 Uhr

Hallo,

zwei Kleinigkeiten am Anfang: Properties werden groß geschrieben. Immer! Beim Namen Property ist es sogar so, das es nicht korrekt ist, da der Wrapper Groß geschrieben ist, und das eigentliche DP klein - das muss auf jeden Fall zumindest übereinstimmen.Sonst gibts ganz subtile Fehler.

Und ansonsten ist nen Property von nem Listentyp doch nichts anderes als jedes sonstige Property. Also Pseudocode:


<Meins>
  <Meins.ListenProperty>
    <ListenTyp>
      <Item1 />
      <Item2 />
    </ListenTyp>
  </Meins.ListenProperty>
<Meins>

Bissle was zu beachten gibts aber. Kompiliertes XAML kann keine Generics (außer ner kleinen Ausnahme für das RootElement). Da behilft man sich einfach, indem man ne Minidummyklasse schreibt

class StringList : List<string> {}

ohne irgendwelchen Inhalt. Die kann man wiederum problemlos in XAML instanzieren.

13.06.2012 - 14:30 Uhr

Oder ist es einfacher in der Schleife direkt die bytes zu schieben und dann Pixel für Pixel mit dem Backpuffer zu schreiben? Natürlich ist das einfacher (auch performanter), da das genau das ist, was doch dein erster Code macht. Row und Column sind dann die entsprechenden Schleifenvariablen.

13.06.2012 - 12:11 Uhr

Es kann zwei Gründe geben. Er wird nicht kleiner weil man nicht aufgepasst hat und die Objekte immer noch referenziert werden. Oder, was hier wahrscheinlicher ist, es gibt einfach keinen Grund den Speicher frei zu machen. Man darf nie vergessen das Speicher freigeben, auch Zeit kostet und wenn kein Grund dazu besteht, weil einfach noch Speicher im Überfluss vorhanden ist, macht der GC das auch nicht.

Konkret nachforschen kann man, wie Abt schon gesagt hat, mit nem Profiler.

13.06.2012 - 12:09 Uhr

Hallo,

[Artikel] Bitoperationen in C#

Danach solltest du das OR verstehen. Vielleicht noch als kleiner Hinweis: Das Pixelformat ist dort ARGB, das vorderste byte ist also das Alpha Byte welches hier immer implizit auf 0 gesetzt wird, weils nicht explizit initialisiert wird.

13.06.2012 - 10:48 Uhr

Das Array allein sind ja dann schon 400 MB + die

den Button zum Threadstart klicke ist mein Arbeitsspeicher bei ca 295.000 K kommst du schon auf 700 MB. Dann noch temporäre Objekte aus der Berechnung und was man auch nicht vergessen darf, dazu noch der nicht verdichtete Large Object Heap. Also der beobachtete Speicherverbrauch ist wahrlich nichts ungewöhnliches.

13.06.2012 - 10:43 Uhr

Hallo,

normalerweise wird CanExecute aufgerufen, wenn CanExecuteChanged ausgelöst wurde (siehe dazu auch den Abschnitt in der Doku dazu). Desweiteren gibts die Methode CommandManager.InvalidateRequerySuggestet() welche dazu führt das alle Commands neu evaluiert werden.

Grad letzteres wird wohl häufiger automatisch aufgerufen (wie du ja auch beobachtet hast). Zu dem wann genau habe ich spontan aber auch keine Infos gefunden. Wobei es aber Sinn macht in den von die genannten Szenarien, dass wieder etwas sichtbar wurde etc.

13.06.2012 - 09:29 Uhr

Hallo,

Der Speicher vom Array bleibt konstant, aber wenn die Elemente Referenztypen sind, dann werden diese ja erstmal erzeugt in deiner Schleife und die verbrauchen ihrerseits natürlich auch Speicherplatz.

Dann dürfte ja nur für die Rechenoperationen ein wenig speicher gebraucht werden Wenn temporär Objekte erzeugt werden, dann räumt der GC die natürlich nicht sofort ab, weil das ineffektiv wäre. Dafür spricht eigentlich das von dir geschilderte Verhalten, das während der Methodenabarbeitung im Thread der Speicher ansteigt. Danach fällt er wieder sobald der GC einmal aufräumt oder?

12.06.2012 - 15:18 Uhr

Hallo,

hier (Visual Studio setup projects (vdproj) will not ship with future versions of VS) der Vollständigkeit halber mal noch die Quelle für obige Aussage. Dort ist auch ne Seite verlinkt (Choosing a Windows Installer Deployment Tool) wo ds VS Setup, InstallShield und WIX gegenübergestellt werden, vielleicht reicht der InstallShield ja doch für deine Belange.

12.06.2012 - 14:40 Uhr

Hallo,

zum Problem kann ich grad nicht viel beitragen, aber ich hoffe du steckst nicht allzuviel Aufwand in die Migration von InnoSetup zum Visual Studio Setup Projekt - das wirds mit der nächsten Version nämlich nicht mehr geben. Dort wird empfohlen entweder auf InstallShield zu setzen was ja auch schon bei VS 2010 angeboten wird, oder WIX.

12.06.2012 - 13:39 Uhr

Hallo,

ist das jetzt n fremder thread, nur weil der konstruktoraufruf in dem Create-Event vom FileSystemWatcher ausgeführt wird?

Ja, siehe Doku vom FileSystemWatcher. Da wird das explizit genannt, das die Eventhandler in nem Thread ausm Threadpool laufen.

invoken geht ja auch net so wie bei winForms.... Das Prinzip ist genau das gleiche, steht auch bei uns in der FAQ [FAQ] Controls von Thread aktualisieren lassen (Control.Invoke/Dispatcher.Invoke)

Der FileSystemWatcher hat das aber schon eingebaut, du musst nur das SynchronizingObject Property richtig setzen. Der marshallt das dann automatisch.

11.06.2012 - 17:41 Uhr

Die Idee mit der Loopback Adresse ist ja nicht schlecht, nur wird dir da kein Paket verloren gehen gg Ich denke am einfachsten gehts vielleicht noch lokal nen Proxy aufzusetzen, welches deine Zieladresse für den Client ist und welcher nur ne gewissen Anzahl an Pakete zum Server durchlässt wenn du Paketverlust simulieren willst.

11.06.2012 - 14:18 Uhr

Der Fehler 2 und 3 ist ja der gleiche und da sagt die Fehlermeldung doch eigentlich auch schon alles. x:Key darf man nur innerhalb eines Dictionaries verwenden wie es z.B. das ResourceDictionary von FrameworkElement ist.

11.06.2012 - 13:33 Uhr

Das funktioniert bei mir aber noch nicht...

Was soll man den mit so einer Fehlerbeschreibung anfangen? Zum Wahrsager gehen und fragen was falsch sein könnte? Bitte immer [Hinweis] Wie poste ich richtig? Punkt 5 beachten.

11.06.2012 - 12:28 Uhr

Hallo,

auf Selling apps, bzw. in den ganzen verlinkten Unterseiten, solltest du alle Infos finden.

11.06.2012 - 12:16 Uhr

Niederlande haben gut gespielt, aber es war viel Pech dabei. Robben hat halt das "Glück" der Bayern mit zu den Niederlanden genommen 😉 Im Endeffekt ists aber dann auch das gleiche wie bei Bayern in der CL - wer kein Tor schießt verliert halt und daher hat Holland verdient verloren, einfach weil sie kein Tor gemacht haben. Deutschlands Spiel war nicht wirklich schön, aber sie haben das Tor gemacht, und das noch nicht mal unverdient, da sie ja auch einige Torchancen hatten.

Ich finds persönlich schade wie die Gruppen ausgelost worden sind. Gruppe B ist imo wesentlich stärker als z.B. A. Aber manchmal macht ja auch genau diese Verteilung auch interessant wenn ein eher schwaches Team weiterkommt weil die Gruppe nicht so herausfordernd war und in der Endrunde dann die Chance erhält eins der starken Teams wegzukicken.

11.06.2012 - 11:03 Uhr

Hallo,

ich meins nicht böse, aber wie suchst du denn? Mit Pop3 hast du doch schon nen richtigen Suchbegriff. Du sagst du hast gegoogelt, mit welchen Begriffen denn? Alleine "C# pop3" liefert sofort massig Ergebnisse von einfachen Beispielen, bis Beispielclients.

10.06.2012 - 22:49 Uhr

Oki, jetzt hab ich dann die Schachtelung der Controls glaub ich verstanden 😉 Dann sieht das Binding doch ganz in Ordnung aus.

Deine DependencyProperties sind trotzdem völlig falsch definiert, du solltest dir in der MSDN Lib unbedingt angucken, was man alles beachten muss.

Beim BackgroundColorProperty verwendest du als Wrapper ein automatisch generiertes Property - wie soll sowas funktionieren? Im Wrapper muss im get GetValue und im set SetValue aufgerufen werden. Sonst kann man das doch gar nicht nutzen wenn man den Wert des DPs setzen wollte.

Bei ActiveState machst du es zwar richtiger, aber auch nicht korrekt. Wie schon gesagt, darf außer dem GetValue bzw. SetValue absolut gar nichts weiter drin stehen, da der Wrapper in Bindingszenarien überhaupt nicht aufgerufen wird. Wenn du etwas beim Setzten des Properties prüfen möchtest, gehört das ins Change Delegate welches du beim Registrieren des DependencyProperties mit angeben kannst. Wobei selbst das hier eigentlich keine schöne Lösung ist. Das einfachste ist hier nen Style mit nem DataTrigger zu verwenden, der den Background entsprechend des States setzt.

PS: Nur ne Kleinigkeit, aber ich halte es auch für verwirrend, dass BackgroundColor gar keine Color ist, sondern nen Brush. Da passt die Benennung nicht zum Typ.

10.06.2012 - 22:12 Uhr

Hallo,

du hast da zwei Fehler drin. Der DataContext vom DataGrid ist ja null, daher kann bei

SelectedItem="{Binding SelectedItem}

gegen gar kein Objekt gebunden werden. Wenn das behoben ist, ist das zweite Problem der Typ von SelectedItem. Wie kommst du drauf das es ne DataRowView sein soll, wenn du UserCredential Objekte reintust? Einfach mal im Debugger die Bindingfehler angucken, da siehst du dann das es nen Fehler gibt und er die Typen natürlich nicht konvertieren kann.

10.06.2012 - 21:51 Uhr

Hehe, wobei das ja schon wesentlich besser ist als momentan, wo es für jede Sprache ne eigene Edition gibt 😉