.NET Blog   ·   .NET Casts   ·   .NET GUI Foren   ·   .NET BlogBook   ·   WPF Blogger   ·   visual studio one   ·   ASP.NET professional

  • ACHTUNG - NEUES BLOG

    Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
Download .NET Essentials Installer
Trickkiste

Microsoft hat es auch nicht leicht die Tage ...

20.02.08 - Internet, Community, Kunterbunt
Beitrag von Norbert Eder
 Also nicht nur, dass Yahoo irgendwie nicht so recht will, dann auch noch ein ganz hochoffizieller Red Ring of Death (RRoD) auf der 2008 Game Developers Conference und schließlich auch noch das Aus für HD-DVD.

Daher bin ich jetzt grundsätzlich mal sehr froh, doch zu einer PS3 gegriffen zu haben, was vermutlich auch viele andere tun werden. Abgesehen davon, dass dein HD-DVD-Laufwerk bei der 360er per default gar nicht dabei ist. Das läßt aber durchaus auch vermuten, dass hier hauptsächlich auf Downloads gesetzt wurde und weniger auf HD-DVD selbst. Genau das wird wohl auch ein größerer Schlag in die Magengrube Toshiba's gewesen sein, die ja teilweise mit Dumping-Preise in den US-Markt gegangen sind und nun ihr Format zu Grabe tragen können. Schade eigentlich, gefällt mir grundsätzlich BD+ ja nicht besonders.

Bezüglich des RRoDs fällt mir auch noch etwas ein: Betrachtet man die Bilder unter dem angegebenen Link, dann dürften die Bedingungen für die dortigen XBoxen auch nicht unbedingt den Idealbedingungen für elektronische Geräte entsprechen ... da wird wohl jemand gewaltig eine auf's Dach bekommen haben ...
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Unable to find manifest signing certificate in the certificate store

14.02.08 - .NET, Visual Studio, Allerlei
Beitrag von Norbert Eder
 Heute bekam ich diese Meldung und wusste im ersten Moment auch nicht so ganz genau, was es damit auf sich hat. Hier nun die Aufklärung:

Gegeben ist ein Projekt, welches über einen TFS verwaltet wird. Für dieses Projekt wurde ClickOnce aktiviert und somit die ClickOnce Manifests signiert. Dafür wurde ein temporärer Key (pfx) angelegt, welcher nicht eingecheckt wurde. Daraus resultiert nun dieser Fehler. ABER:

In den Projekteigenschaften kann nun in der Lasche Sign der Haken von Sign the ClickOnce manifests entfernt werden, was jedoch dieses "Problem" nicht behebt. Der Fehler erscheint weiterhin. Um diesen Fehler los zu werden, muss manuell die Projekt-Datei (csproj, vbproj, etc.) geöffnet werden, um folgende Tags zu entfernen:
<ManifestCertificateThumbprint>
<ManifestKeyFile>
<GenerateManifests>
<SignManifests>

Nun das Projekt bzw. die Solution neu laden und es kann wieder gebuildet werden.

Daher:
  • Derartige Änderungen an einem Projekt unbedingt mit den Kollegen absprechen
  • Key-Dateien ins Source Control einchecken
  • Bei einem Test nichts einchecken

  2 Kommentare - 3506 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


.NET Snippets hat Geburtstag! Ein Gewinnspiel erwartet Euch!

11.02.08 - Internet, Community
Beitrag von Norbert Eder
 Jawohl! .NET Snippets hat Geburtstag. Das Projekt wurde zwei. Zur Feier hat Jan Welker ein Gewinnspiel gestartet. Instruktionen finden sich auf der gerade erwähnten Seite. Mitmachen kann man hier, jedoch ist eine erfolgreiche Anmeldung notwendig, kann aber unverbindlich und kostenlos vorgenommen werden.

Zu gewinnen gibt es natürlich auch etwas:
1. Preis: Ein Windows® Vista Ultimate® (NFR)
2. Preis: Eine Microsoft® LifeCam NX-6000
3. Preis: Ein Buch Hunting Security Bugs

Und was macht man, wenn man etwas gewinnen will? Mitmachen. Bis 24. Februar 2008 24:00 Uhr bleibt Zeit. Also ran an die Tasten, anmelden und tippen!
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Service-Oase Österreich - Internetprovider unleashed

11.02.08 - Internet, Kunterbunt
Beitrag von Norbert Eder
 Immer wieder liest man in diversen Blogs, wie es denn so um das Kundenservice in Deutschland bestellt ist. Eigentlich oft kaum vorstellbar. Hier eine kleine Geschichte von mir. Ein Beweis, dass es in Österreich leider nicht viel anders ist …

Am 19.11.2007 habe ich für meine Internetleitung einen Umzug angemeldet. Der eifrige Leser dieses Blogs hat sicherlich mitbekommen, dass ich umgezogen bin. Dauer in Österreich (es handelt sich um eine entbündelte Leitung) ca. 3 Wochen, da dies der Provider nicht selbst vornehmen kann und unsere Telekom die Leitung entbündeln muss, damit der Anschluss neuerlich vom Provider freigeschaltet werden kann.

Anfang Jänner 2008 habe ich mich dann an meinen Provider gewandt, da ich bis dahin nichts, weder vom Provider, noch von der Telekom gehört habe. Nach dem 3. Gespräch wurde mir dann mitgeteilt, dass meine Daten nicht ins System eingetragen wurden (der Umzugsantrag), das nachgeholt wurde und ich nun in ca. 3 Wochen meinen Anschluss zur Verfügung hätte. Hierzu drei Punkte:
  • Wie kann es sein, dass Umzugs-Unterlagen nicht ins System eingetragen werden, wenn man den Umzug direkt beim Kundenservice (also vor Ort) bekannt gibt und die hübsche Dame die Daten vor mir eingibt?
  • Der Kunde würde nie benachrichtigt werden, unabhängig um welchen Status es sich gerade handelt. Alles bleibt so lange liegen, bis sich dann der Kunde ohnehin von selbst meldet. Auch das finde ich nicht gerade sehr kundenfreundlich. Meldet sich der Kunde dann, gibt es maximal eine blöde Antwort auf die Frage, warum da nichts von alleine passiert und man ständig alles selbst antriggern muss.
  • Auf Emails wird ohnehin nicht reagiert. Kurz nach dem Absenden kommt eine nette automatisierte Email, die darauf hinweist, dass die Antwort etwas länger dauern kann, da gerade sehr viele Anfragen zu beantworten sind. Dass „etwas länger dauern“ jedoch mit „nie“ gleichzusetzen ist, war mir zu dem Zeitpunkt noch nicht so ganz bewusst. Jetzt weiß ich es.

Naja, auf jeden Fall habe ich 3 Wochen später auch nichts gehört und mich dann nochmals gemeldet um einen aktuellen Status zu erhalten. Komischerweise hatte ich dann zwei Tage später Post von der Telekom, in der mir ein Termin zur Entbündelung angekündigt wurde. Gut, Telekom kam, erledigte die Arbeit und meinte dann so im Gehen: „Ach ja, ihr Provider schaltet sie dann in ZWEI Tagen frei.“ Das war am 6. Februar 2008.

Bitte was? Erst in zwei Tagen? Kann ja wohl nicht sein. Dann also gleich wieder in der Hotline angerufen und nachgefragt, ob man dies nicht beschleunigen könne, denn das Freischalten eines Accounts kann doch wirklich keine 2 Tage in Anspruch nehmen. Die nette Dame am anderen Ende der Leitung wies mich dann schließlich darauf hin, dass die Freischaltungen automatisiert scheduled und vorgenommen werden. Ein Eingreifen sei nicht möglich. Aha. Sehr interessant. Dann hätten sie das besser „schedulen“ sollen, denn der Umstellungstermin war bekannt und ich kann mir beim besten Willen nicht vorstellen, dass ein Knopfdruck nicht möglich ist.

Am 8. Februar 2008 war es dann wider Erwarten soweit und die Leitung wurde tatsächlich freigeschaltet.

Es geht aber dann doch noch weiter: Gleichzeitig mit dem Umzug wurde auch ein Tarifwechsel beantragt. Es wurden neue Produkte geschaffen und die alten Produkte (von einer zugekauften Firma) wurden auf die neuen Produkte automatisch „gemappt“. Coole Sache. Selbst hat man einen Tarif, der mit 39 Euro im Monat zu Buche schlägt. Der neue resultierende Tarif wird um 35 Euro angeboten. Man wird automatisch auf diesen neuen umgestellt und muss weiterhin 39 Euro berappen. Nur wenn man ein Formular ausfüllt etc. „darf“ man auch nur mehr 35 Euro bezahlen (und bindet sich dann weitere x Monate). Auf jeden Fall habe ich auf einen anderen Tarif umgestellt. Und siehe da (Kontrolle über Online-Oberfläche): Die Adresse wurde nicht mit umgestellt. Der Tarif ist noch der GANZ alte. D.h. ich weiß weder meine Leitungsgeschwindigkeit, weder das Transfervolumen, noch den Preis, den ich zu bezahlen habe. Aber nachdem ich die ganzen Monate ohne Internet aufgefordert wurde, monatlich 39 Euro zu bezahlen, kann ich mir schon ausmalen, was da auf mich zukommt (der neue Tarif würde übrigens nur 27 Euro kosten und hätte eigentlich schon am 19.11.2007 aktiviert werden).

Hier wird also wohl der nächste Anruf und 25 Minuten in der Warteschleife (ja, ich hatte das letzte Mal die Stoppuhr laufen) fällig …

Merke: Bei einem Umzug unbedingt ca. 2-3 Monate vorher den Umzug beim Provider bekannt geben, damit die Leitung dann auch rechtzeitig bereit steht. Dies sollte auch vorgenommen werden, wenn man erst 3 Wochen vor dem tatsächlichen Umzugstermin weiß, dass man umziehen wird. Ergo? Alles in Butter, oder?

PS: Für die Monate ohne Internet wurde mir übrigens eine Gutschrift angeboten, aber von der hab ich bis jetzt nichts gesehen …

  3 Kommentare - 878 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


WPF Performanceprobleme unter Vista gelöst

08.02.08 - .NET, WPF
Beitrag von Norbert Eder
 ... das versprechen zumindest zwei verfügbare Hotfixes für Windows Vista (einmal für 32 Bit und einmal für 64 Bit). Diese sollen etwaige Performanceprobleme für WPF-Anwendungen beheben. Es empfiehlt sich, das jeweilige Hotfix nur dann einzuspielen, wenn auch tatsächlich entsprechende Probleme vorhanden sind.

Zu den Downloads:
Update für Windows Vista (KB938660) (32 Bit)
Update für Windows Vista (KB938660) (64 Bit)

Und hier der KB-Artikel:
Knowledge Base Artikel
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Über die Wichtigkeit der Windows Presentation Foundation

07.02.08 - Entwicklung, Diskussionen, .NET, WPF
Beitrag von Norbert Eder
 Im ersten Teil meiner WPF-Serie hatte ich bereits über WPF aus Sicht eines Unternehmens geschrieben. Mittlerweile ist etwas Zeit vergangen und viele Diskussionen zu diesem Thema wurden gefochten. Hier ein Zwischen-Konklusio zu diesem Thema.

Vermeintliche Argumente gegen WPF


Wohl niemand (der sich mit der WPF auseinander gesetzt hat) streitet ab, dass die Windows Presentation Foundation eine geile Sache ist. Jedoch kaum jemand setzt wirklich ernsthafte Projekte auf Basis der WPF um (zumindest nicht in meinem Umfeld). Auch im Internet nehmen lediglich Komponenten-Hersteller „WPF“ in ihr Programm auf. Standardsoftware und/oder Tools werden kaum in Form von WPF-Anwendungen angeboten.

Ausrede No. 1: Größe des .NET Frameworks
Die von mir meist gehörte „Ausrede“ hatte mit der Download-Größe des .NET Frameworks (Version 3.5) zu tun. Dem kann ich mich absolut nicht anschließen. Man nehme als Beispiel Java. Hier gibt es eindeutig weniger Berührungsängste, obwohl es sich hierbei grundsätzlich um das gleiche System handelt. Weiters sehe ich täglich, welche Datenmengen über die Leitungen flutschen, da fallen die paar Megabytes durchaus nicht ins Gewicht. Für mich ist dies definitiv kein Argument.

Ausrede No.2: Kunde will nicht
In Newsgroups, aber auch persönlichen Gesprächen musste ich feststellen, dass Kunden keine Anwendungen auf Basis WPF haben möchten. Auch dies halte ich durchaus für ein Gerücht. Natürlich gibt es Unternehmen, die spezielle Prozesse implementierten, wonach die Einführung eines gänzlich neuen .NET Frameworks einen Evaluierungsprozess durchlaufen muss. In kleinen Unternehmen ist dies zu 99% jedoch nicht der Fall. Vielmehr ist ihnen – aus meiner Erfahrung – meist völlig egal, womit die Anwendungen umgesetzt wurden, Hauptsache, sie funktionieren und das möglichst fehlerfrei. Ergo kann auch dieses Argument nicht komplett als solches gewertet werden.

Ausrede No.3: Fehlendes Know-How
Dies ist wohl das einzige Argument (von den von mir aufgezählten), welches ich gelten lasse. Natürlich bekommt nicht jeder Entwickler sofort sämtliches WPF-Know-How geimpft. Es müssen schon Erfahrungen gesammelt werden – und das nicht wenige. Tatsache ist, dass es im Vergleich zu Windows Forms einige Unterschiede konzeptioneller Natur gibt und diese berücksichtigt werden müssen. Die Entscheidung, ein Projekt mittels WPF umzusetzen ohne mit jeglichem Wissen aufwarten zu können ist mehr als gefährlich und sollte keinem Kunden zugemutet werden. Schließlich kann auf diese Art und Weise kein einziger Projektplan eingehalten werden. Dennoch muss man einmal ins kalte Wasser springen und den Schritt wagen.

Windows Forms als WPF-Killer


In den meisten Fällen – wir sprechen hier von reiner Windows-Client-Entwicklung – wird auf die guten alten Windows Forms zurück gegriffen. Diese gibt es seit der Einführung des .NET Frameworks, hier ist Know-How vorhanden, es wurden eigene Steuerelemente entwickelt und man weiß einfach, wie im Falle des Falles zu reagieren ist. Daraus resultiert, dass viele Unternehmen weiterhin zu Windows Forms greifen, WPF als interessant einstufen, aber eben nicht verwenden.

Community als Anlaufpunkt
Zu Windows Forms gibt es zahlreiche Ressourcen. Nicht nur englische Homepages beschäftigen sich damit, auch im deutschsprachigen Umfeld ist einiges an Know-How zu finden. Bezüglich WPF sieht dies etwas anders aus. Hier ist man großteils gezwungen, auf die englische Sprache zu setzen. Kann zwar fast jeder, dennoch liest es sich auf Deutsch einfach besser. Im deutschsprachigen Raum finden sich diesbezüglich kaum Personen, die den Spirit von WPF weitertragen – warum auch immer es so ist. Vermutlich liegt es daran, dass wir Mitteleuropäer um ein Vielfaches kontrollierter sind als andere und der Enthusiasmus sich daher in Grenzen hält.

Fehlende Umsetzungen
Viele Firmen, die kein Interesse haben, als Technologieführer aufzuscheinen warten auf andere Unternehmen, die mit entsprechenden Produkten dem Markt die Richtung vorgeben. Genau diese Produkte fehlen meiner Meinung nach. Wie bereits angesprochen gibt es kaum Anwendungen die auf WPF basieren und daher anderen Unternehmen zeigen, dass eine Umsetzung möglich ist, dass derartige Anwendungen von Kunden akzeptiert werden und dass dafür durchaus Potential vorhanden ist.

Hemmungen ablegen


Einer der wohl wichtigsten Punkte eines Entwicklers ist Neugierde. Diese gewährleistet stete Weiterentwicklung. Leider verharren sehr viele Entwickler in dem, was ihnen bekannt ist und sind daher wenig risikofreudig. Dies ist der falsche Weg, wie ich finde. In vielen Unternehmen ist es leider so, dass Entwickler nicht die Möglichkeit haben, sich mit neuen Technologien zu beschäftigen, Prototypen zu bauen, in Büchern/Zeitschriften/Online zu schmökern. Hier gibt es zwei mögliche Wege: Entweder setzt man dies durch (denn schließlich kommt zusätzliches Wissen auch dem Unternehmen zu Gute) oder man erlernt Neues in der Freizeit (was meist der schwierigere Weg ist).

Unterstützung nötig?


In meinem konkreten Fall kann ich sagen, dass ich mich schon seit Mitte 2006 mit WPF beschäftige und bereits mehrere Anwendungen erfolgreich auf Basis der WPF umgesetzt habe. Mittlerweile gibt es wohl kaum eine Anforderung, bei der mit größeren Problemen zu rechnen ist. Natürlich hat es seine Zeit gebraucht, viel Code wurde umsonst geschrieben, aber alle Projekte konnten in Zeit umgesetzt werden und laufen nun im Echtbetrieb. Anfangs war natürlich Skepsis vorhanden, doch konnte dies meisten aus dem Weg geräumt werden.
Da ich immer wieder Anfragen in diese Richtung bekomme und Bedenken behandelt werden müssen, biete ich auf diesem Wege öffentlich meine Hilfe an. Schließlich stehe ich für technologischen Vorsprung und unterstütze gerne. Bei Fragen kann man sich einfach via Kontaktformular an mich wenden. Hilfe ist asap unterwegs.

Fazit


Aktuell schätze ich die Windows Presentation Foundation eher noch als unwichtig ein, da sich viele – mangels vorhandenem Know-How – einfach nicht getrauen, diese Technik/Technologie einzusetzen. Ich denke aber auch, dass in ein paar Monaten/Jahren kaum ein Weg daran vorbei führen wird – man denke hierbei unter anderem an Silverlight, auch kein unwesentlicher Faktor.
  8 Kommentare - 2342 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Image aus einem WPF-Control erzeugen

07.02.08 - .NET, Base Framework, WPF
Beitrag von Norbert Eder
 Früher oder später stößt jeder WPF-Entwickler auf diese Aufgabe: Aus unterschiedlichsten Gründen muss von einem dargestellten Control eine Grafik erzeugt werden. Wer bereits mit Windows Forms gearbeitet hat, versucht nun vergeblich den Weg über CreateGraphics. Dieser Ansatz funktioniert unter der Windows Presentation Foundation nicht. Stattdessen muss ein anderer Kniff angewandt werden.
Im ersten Schritt kann mittels RenderTargetBitmap ein Bitmap mit der gewünschten Größe erstellt werden. Darin hinein wird nun das entsprechende Control gerendert. Nun müssen wir uns eines Kniffes behelfen (da eventuell die Größe nicht gänzlich korrekt ist). Dazu erstellen wir ein Image-Control, welches das Bitmap als Source erhält und aktualisieren die Größe des Elements entsprechend des Inhaltes mittels der Methoden Measure und Arrange. Nun wird das Image mit der korrekten Größe erneut gerendert und beispielsweise einem Objekt vom Typ PngBitmapEncoder übergeben. Nun kann das Image in einen Stream geschrieben und in ein System.Drawing.Image umgewandelt werden. Hier nun ein Beispielcode:
public System.Drawing.Image Convert(
  FrameworkElement controlToRender)
{
    RenderTargetBitmap rtb = new RenderTargetBitmap(
      (int)controlToRender.ActualWidth, 
      (int)controlToRender.ActualHeight, 
      90, 
      90, 
      PixelFormats.Default);
    
    Visual vis = (Visual)controlToRender;
    rtb.Render(vis);
    
    System.Windows.Controls.Image img = 
      new System.Windows.Controls.Image();
    img.Source = rtb;
    img.Stretch = Stretch.None;
    img.Measure(new System.Windows.Size(
      (int)controlToRender.ActualWidth, 
      (int)controlToRender.ActualHeight));
    System.Windows.Size sizeImage = img.DesiredSize;
    img.Arrange(new System.Windows.Rect(new 
      System.Windows.Point(0, 0), sizeImage));
    
    RenderTargetBitmap rtb2 = new RenderTargetBitmap(
      (int)rtb.Width, 
      (int)rtb.Height, 
      90, 
      90, 
      PixelFormats.Default);
    rtb2.Render(img);
    
    PngBitmapEncoder png = new PngBitmapEncoder();
    png.Frames.Add(BitmapFrame.Create(rtb2));
    
    Stream ms = new MemoryStream();
    png.Save(ms);
    
    ms.Position = 0;
    
    System.Drawing.Image retImg = 
      System.Drawing.Image.FromStream(ms);
    return retImg;
}

Zum PngBitmapEncoder: Hier stehen weitere Encoder bereit. Zusätzliche Informationen sind auf der MSDN-Seite zum Thema BitmapEncoder zu finden. Der Vollständigkeit halber hier die Liste der zur Verfügung stehenden Encoder:
  • BmpBitmapEncoder
  • GifBitmapEncoder
  • JpegBitmapEncoder
  • PngBitmapEncodery
  • TiffBitmapEncoder
  • WmpBitmapEncoder

  2 Kommentare - 3713 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


PropertyGrid löst Event PropertyValueChanged bei Collections nicht aus

07.02.08 - .NET, Grundlagen, Base Framework, WPF
Beitrag von Norbert Eder
 Das PropertyGrid besitzt ein Event namens PropertyValueChanged. Dieses wird ausgelöst, wenn eine Eigenschaft editiert wird. Dies funktioniert soweit auch gut, außer die Eigenschaft wird durch eine Collection dargestellt. In diesem Falle wird nichts ausgelöst.

Hintergrund


Das Problem liegt darin, dass sich die Collection selbst nicht ändert, wenn sich in einem der Werte eines Child-Objektes ein Wert ändert. Ebenfalls ändert sich die Collection nach außen hin nicht, wenn neue Elemente hinzugefügt werden. Sehen wir uns die Implementierung auf Seiten des PropertyGrids an.
Das PropertyGrid besitzt eine Auflistung GridEntryCollection. Diese beinhält GridEntry-Objekte, welche die einzelnen Properties darstellen. GridEntry besitzt nun eine Methode EditPropertyValue. Diese überprüft, ob sich der Wert verändert hat und setzt darauf hin ein Commit ab, oder nicht (wenn keine Änderung). Im Commit wird anschließend der besagte Event ausgelöst. Hier nun der relevante Teil aus der Methode:
object propertyValue = this.PropertyValue;
object obj3 = this.UITypeEditor.EditValue
    (this, this, propertyValue);
if (!this.Disposed)
{
    if ((obj3 != propertyValue) 
        && this.IsValueEditable)
    {
        iva.CommitValue(this, obj3);
    }
    if (this.InternalExpanded)
    {
        PropertyGridView.GridPositionData data = 
          this.GridEntryHost.CaptureGridPositionData();
        this.InternalExpanded = false;
        this.RecreateChildren();
        data.Restore(this.GridEntryHost);
    }
    else
    {
        this.RecreateChildren();
    }
}

Hier ist nun schön zu erkennen, dass lediglich die Objekte miteinander verglichen werden, was bei einer Collection natürlich grundsätzlich keine Änderung entdecken lässt. Dadurch muss man sich mit einem Workaround behelfen.

Mögliche Workarounds


Der erste Workaround ist vermutlich der, der mit dem geringsten Aufwand verbunden ist: Es gibt einige 3rd Party Produkte, welche diesen „Fehler“ erkannt und ausgemerzt haben. Damit muss selbst keine Implementierung vorgenommen werden, jedoch sind die meisten dieser Produkte kommerzieller Natur und kosten somit einige Euros.
Eine weitere Möglichkeit ist, selbst Hand anzulegen und in die Tasten zu klopfen. Dazu muss man sich nun einen grundsätzlichen Gedanken machen. Wie kann erreicht werden, dass der Objekt-Vergleich in oben gezeigter Methode erkennt, dass das Objekt geändert wurde? Korrekt, wir müssen die Collection klonen. Das heißt, die Objekte der Collection und auch die Collection selbst müssen das Interface ICloneable implementieren.
Die Collections selbst werden im PropertyGrid in einem CollectionEditor angezeigt. Dieser ist standardmäßig für alle Collections der gleiche. Diesen müssen wir nun für unsere Collection-Eigenschaft austauschen, indem wir eine eigene Klasse erstellen, die von UITypeEditor ableitet:
public class CustomCollectionEditor : UITypeEditor
{
    private CollectionEditor _editor = 
      new CollectionEditor(typeof(CustomCollection));
    
    public override object EditValue(
      ITypeDescriptorContext context, 
      IServiceProvider provider, 
      object value)
    {
        if (value != null)
        {
            value = this._editor.EditValue(context, provider, value);
            CustomCollection list = (CustomCollection)value;
            return list.Clone();
        }

        return base.EditValue(context, provider, value);
    }

    public override UITypeEditorEditStyle GetEditStyle(
      ITypeDescriptorContext context)
    {
        return this._editor.GetEditStyle(context);
    } 
}

Im Grunde passiert hier wenig Spannendes. Es wird lediglich bei einem Edit die Collection geklont und die neue Collection zurück geliefert. Dadurch erkennt nun das PropertyGrid eine Änderung und aktiviert ihrerseits das Event PropertyValueChanged. Daraufhin ist es nun möglich festzustellen, dass a) in der Collection eine Änderung passiert sein muss und b) können wir feststellen wo diese passiert ist.
Schlussendlich muss nun noch der jeweiligen Eigenschaft zugewiesen werden, dass diese mit dem eigenen CustomCollectionEditor zu öffnen ist. Dazu sind folgende Attribute bei der entsprechenden Property zu setzen:
private CustomCollection _collection = new CustomCollection();

[TypeConverter(typeof(CustomCollection))]
[Editor(typeof(CustomCollectionEditor), typeof(UITypeEditor))]
public CustomCollection MyCollection
{
  get { return this._collection; }
  set { this._collection = value; }
}

Hierzu gibt es noch einen kleinen Tipp: Es ist darauf zu achten, dass auch der Setter tatsächlich vorhanden ist. Im GridEntry wird abgefragt, ob das Object editierbar ist (IsValueEditable). Wäre nur ein Getter vorhanden, wäre IsValueEditable auf false und der Wert würde nicht committed warden, wodurch auch das Event PropertyValueChanged nicht ausgelöst werden würde.

Fazit


Schön wäre es natürlich, würde das PropertyGrid diese Funktionalität anbieten. Da das nicht der Fall ist, muss man selbst etwas nachhelfen. Die oben gezeigte Variante kommt dem gewünschten schon recht nahe, auch wenn der besprochene Event erst angetriggert wird, nachdem der CollectionEditor geschlossen wird. Zwar in manchen Fällen (Eingabevalidierung) nicht erwünscht, lässt sich aber so einfach nicht beheben. Dennoch bietet diese Variante eine einfache und gute Möglichkeit, das gewünschte Ziel zu erreichen.
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Jänner 2008 im Rückblick

04.02.08 - .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei
Beitrag von Norbert Eder
 Kommt es nur mir so vor, oder vergeht die Zeit wirklich so schnell? Jedenfalls ist wieder ein Monat um und somit hier ein kurzer Rückblick, was sich auf diesem Blog im Jänner so getan hat.

.NET Base Framework


Mit List.ForEach durch Listen iterieren
String.IsNullOrEmpty als Extension Method

Windows Presentation Foundation


Globales Exception-Handling in WPF
WPF: x:Code Element - eine Diskussion
Animationen mit WPF anhand einer kleinen Foto Gallery
WPF: Validierung von Eingaben

Visual Studio


Visual Studio Templates erstellen

Zu guter Letzt sei noch erwähnt, dass die neue Webpräsenz des .NET BlogBooks online gegangen ist: http://www.dotnet-blogbook.com
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Aufwandsschätzungen verbessern

04.02.08 - Entwicklung, Diskussionen, Qualitätsmgmt.
Beitrag von Norbert Eder
 Aufwandsschätzungen gehören quasi zur täglichen Arbeit eines Softwareentwicklers – zumindest sollte es das. Gerade für den Projektmanager ist es nicht unerheblich, über den zu planenden Aufwand Bescheid zu wissen, als auch feststellen zu können, wie der derzeitige Stand ist. Daher müssen Aufwände für erfasst werden für:
  • das gesamte Projekt
  • daraus resultierende Komponenten
  • daraus resultierende einzelne Tasks


Kontrolle der Aufwände


Einer der wichtigsten Aspekte daran ist es, dass die ursprünglich abgegebenen Schätzungen ständig neu betrachtet und gegebenenfalls aktualisiert werden. In vielen Unternehmen unterbleibt dieser Schritt, wodurch das Projektmanagement oft keine aktuellen Zahlen zur Verfügung hat und Verzögerungen nicht sofort erkannt werden.
Aber auch der Entwickler selbst kann von der Überarbeitung der Aufwandsschätzungen profitieren. Zumindest sollten die ursprünglich geschätzten Aufwände mit dem tatsächlichen Aufwand verglichen werden. Dadurch werden Verzögerungen festgehalten und stellen einen wichtigen Ansatzpunkt zur Analyse dar. Unter anderem können dadurch folgende Fragen beantwortet werden:
  • Bei welchen Aufgaben wurden die ursprünglichen Schätzungen überschritten?
  • Betrifft dies ähnliche Aufgaben bzw. die Arbeit mit speziellen Techniken/Technologien?
  • Welche Probleme sind dafür verantwortlich?

Auf Basis der Antworten zu diesen Fragen können Schritte eingeleitet werden, um die Aufwandsschätzungen beim nächsten Mal zu verfeinern bzw. um grundlegende Probleme aufzuarbeiten. Dies hilft nicht nur dem gesamten Projekt, sondern jeder einzelne Entwickler bekommt ein immer besseres Gefühl für die zu schätzenden Aufgaben und schließlich können dadurch eigene Schwachpunkte gefunden und bekämpft werden. Es resultiert also eine Verbesserungsliste der eigenen Fähigkeiten. Ganz gut, wenn man bedenkt, dass damit die Qualität der eigenen Arbeit wesentlich verbessert werden kann.

Gegenüberstellung


Welche Daten sollten nun gegenüber gestellt werden? Ich kann hier hauptsächlich aus meiner persönlichen Erfahrung sprechen und wiedergeben, welche Daten von mir ausgewertet werden:
  • Ticket (aus Ticketing-System)
  • Ursprüngliche Schätzung
  • Gesamter Aufwand
  • Abweichung in Stunden
  • Abweichung in Prozent
  • Bei Problemen eine entsprechende Angabe darüber

Diese Liste kann in entsprechenden Tools (beispielsweise Excel) gut erstellt und gewartet werden. Ebenfalls lassen sich entsprechende Diagramme anfertigen, die anhand des Verlaufs über zahlreiche Aufgaben hinweg eine Tendenz anzeigen und somit auch erkennen lassen, ob Reaktionen auf etwaige Verzögerungen tatsächlichen Einfluss ausüben.

Fazit


Aufwandsschätzungen müssen gemacht werden und in vielen Fällen passiert dies auch durch den tatsächlichen Entwickler. Damit dieser nun an seinen Fähigkeiten arbeiten kann empfiehlt es sich, die eigenen Angaben und Leistungen auch ständig zu messen und zu bewerten. Mit einfachen Mitteln können hier sehr gute Ergebnisse erzielt werden.

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL



Zurück Weiter