Zum Inhalt springen

Ich finde es ein nettes Feature, eine kleine Vorschau anzuzeigen, wenn ich ein Bild auf einer Webseite hochladen will.
Dazu folgendes kleines Snippet:

$(function() {
    $("#fileUpload").change(function() {
        if (this.files && this.files[0]) {
            var file = this.files[0];

            var preview = $('#imagePreview');

            var isImage = typeof file.type !== "undefined" && file.name.match(/\.(png|jpe?g)$/i);

            if (isImage && typeof FileReader !== "undefined") {
                var reader = new FileReader();

                reader.onload = function(e) {
                    preview.empty();
                    var img = $('<img>');
                    img.attr('src', e.target.result);

                    if (preview.css('max-height') != 'none') {
                        img.css('max-height', parseInt(preview.css('max-height'), 10));
                    }

                    preview.html(img);
                }

                reader.readAsDataURL(this.files[0]);

                preview.show();
            } else {
                preview.empty();
                preview.html($('<p>').text('Dateiname: ' + file.name));
                preview.show();
            }
        }
    });
});

Das passende Formular dazu:

<div class="form-group">
    <label for="fileUpload" class="control-label col-md-2">Datei: </label>
    <div class="col-md-10">
        <input type="file" name="fileUpload" id="fileUpload"/>
    </div>
</div>
                    
<div class="form-group">
    <div class="col-md-10 col-md-offset-2 fileInputPreview" id="imagePreview">
        <!-- empty tag for preview image -->
    </div>
</div>

Die passenden CSS Klassen, damit das Bild auch nicht aus dem Design rauswandert :)

.fileInputPreview {
    display: inline-block;
    max-height: 200px;
    width: 500px;
}

.fileInputPreview img {
    max-width: 100%;
    height: auto;
}

Am Ende sieht es dann etwa so aus:
imagePreview

Den File-Upload habe ich mit Bootstrap FileStyle optisch etwas ansprechender gestaltet.

Fast jedes Programm weißt den Benutzer darauf hin, wenn es ungespeicherte Änderungen gibt, sobald man das Programm verlassen will.
Im Browser gibt es sowas standardmäßig nicht, aber dank JavaScript ist das kein Problem. Und mit jQuery wird die ganze Sache sogar noch einfacher.

Und zwar kann man sich an das „beforeUnload“-Event hängen. Hier wird der zu erscheinene Text hinterlegt. Weiteren Einfluss auf die Gestaltungsmöglichkeit hat man nicht, dies hängt vom Browser ab.

$("form").one("change", ":input", function() {
    // einen Hinweis anzeigen (wer es möchte)
    $('#saveInfo').show();

    // Bevor die Seite verlassen wird, wird der folgende Text angezeigt.
    $(window).on('beforeunload', function (e) {
            return "Es gibt ungespeicherte Änderungen.";
    });

    // Verhindern, dass ein Submit-Button (also z.B. "Speichern") auch den Hinweis hervorruft.
    $(this).parents("form:first").find(":submit").click(function() { $(window).off("beforeunload"); });
});

In dem Beispiel überwache ich alle Eingabefelder („:input„) innerhalb meiner Form. Sobald ein Feld geändert wird das „beforeunload“-Event scharf gemacht. Achtet auch auf die letzte Zeile, sollte ich über einen Submit-Button kommen („:submit„), wird das Event wieder aufgehoben. Schließlich will ich ja beim Klick auf „Speichern“ nicht den Hinweis bekommen.

2014

Jan 1

Und wieder beginnt ein neues Jahr. Viele nutzen den Jahreswechsel, um sich guten Vorsätzen hinzugeben und möchten nun ein paar Sachen ändern. Bei mir ist das eigentlich nicht so, denn für mich ist der Jahreswechsel genauso gut oder schlecht wie jeder andere Tag im Jahr. Ich brauche eigentlich keine Veränderungen, denn diese hatte ich in 2013 genug. Angefangen beim eigenen Haus, über einen neuen Arbeitgeber, weiter zur Hochzeit mit meiner Traumfrau weiter zur Glücksvollendung durch die Geburt meines Sohnes Max. Damit war 2013 vermutlich das aufregendste und spannendste Jahr meines Lebens (bis jetzt).
All das hat mein Leben komplett umgekrempelt und meine Prioritäten liegen nun komplett anders als beispielsweise vor einem Jahr. Nicht jede dieser Entwicklungen macht mich glücklich, allerdings wäre es auch keine Herausforderung, wenn alles so einfach zu meistern wäre.
Daher freue ich mich sehr auf das neue Jahr, es wird nicht langweilig und garantiert mit vielen Erlebnissen und Erfahrungen gespickt sein, welche ich mir überhaupt nicht vorstellen kann.
Daher wünsche ich euch auch ein spannendes Jahr und hoffe ihr freut euch auf eure Herausforderungen und nutzt 2014 vielleicht auch für die eine oder andere Veränderung. Es muss ja nicht gleich so radikal wie bei mir sein, aber es kann sich immer lohnen!

In diesem Sinne – Prost Neujahr!

Aktuell nutze ich Visual Studio 2013 RC in Verbindung mit dem TFS 2012. Dazu habe ich in den letzten Jahren TFS Sidekicks von Attrice lieben gelernt.
Jedoch wollte das Programm auf meinem Rechner nicht starten, die Fehlermeldung lautete „Application cannot read registry.“. Auch die Tipps aus dem Netz, dass man als Administrator starten sollte halfen nicht. Offiziell wird nur Visual Studio 2012 unterstützt, daher vermutete ich hier das Problem.

Mithilfe von meinem neuen Lieblings-Tool dotPeek kam ich auch schnell dahinter, warum er scheiterte:

        RegistryKey registryKey = Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\VisualStudio\\11.0");
        if (registryKey != null)
        {
          if (registryKey.OpenSubKey("TeamFoundation\\SourceControl") != null)
            str = registryKey.GetValue("InstallDir", (object) string.Empty) as string;
        }

Da ich Version 11 (VS 2012) nicht installiert hatte, konnte er den Pfad auch nicht finden. Die Ordner halt von Hand angelegt, den Schlüssel „InstallDir“ aus der 12er-Version kopiert, schon funktionierte alles. Ihr müsst auch den TeamFoundation/SourceControl – Ordner anlegen, der InstallDir-Schlüssel kommt aber unterhalb von „11.0“.

Wichtig: solltet ihr ein 64-Bit System haben, findet ihr die Ordner unterhalb von „Wow6432Node“ in der Registry!

Vor ein paar Tagen kam ein Kollege auf mich zu und meinte, er habe beim Unit-Test schreiben einen Fehler in meinem Code entdeckt. Um mir den Fehler zu zeigen, hat er mir eigens einen Unit-Test geschrieben, welcher in etwa so aussah:

// MyTypeList : List<string>
MyTypeList list = new MyTypeList {"a", "b", "c"};

if(list.ElementAt(0) == null)
{
    throw new NullReferenceException();
}

if(list[0] == null)
{
    // Hier knallt er!
    throw new NullReferenceException();
}

if(list[1] == null)
{
    throw new NullReferenceException();
}

Er knallte immer, wenn man auf list[0] zugreifen wollte. Im Debugger zeigte er mir alle Elemente an, list[1] usw. funktionierte auch. Ich stand erstmal auf dem Schlau. Da ich den Fehler nicht sofort identifizieren konnte, baute ich mir eine kleine Testapplikation, um mit einem Minimum an Code das Problem zu identifizieren.

Letzendlich lag es an einem Indexer, welchen ich selber erstellt habe. Und zwar erwartete dieser als Übergabetyp ein Enum. Dieser überschreibt zwar nicht den von List<T> geerbten Indexer this[int index], jedoch scheint der Compiler hier leichte Probleme zu machen.

Schauen wir uns mal den kompilierten Code in dotPeek an.

      MyTypeList myTypeList1 = new MyTypeList();
      myTypeList1.Add("a");
      myTypeList1.Add("b");
      myTypeList1.Add("c");
      MyTypeList myTypeList2 = myTypeList1;
      if (Enumerable.ElementAt<string>((IEnumerable<string>) myTypeList2, 0) == null)
        throw new NullReferenceException();
      if (myTypeList2[MyEnum.Value1] == null)
        throw new NullReferenceException();

Den ersten Zugriff auf den numerischen Indexer wurde auf den Enum-Indexer geändert. Eine Erklärung dazu konnte ich nicht wirklich finden, bzw. keine die ich nachvollziehen konnte. Letztendlich hat es damit zu tun, dass ein Enum im Bauch eigentlich nur ein int-Typ ist. Dies passiert immer, wenn ich den numerischen Indexer mit 0 zugreife, wohlgemerkt, nur mit 0. Alle anderen Werte funktionieren problemlos.

Wie kann ich das Problem lösen / umgehen?

Dafür gibt es mehrere Wege.

Wird der Index-Wert woher in eine Variable (z.B. innerhalb einer for-Schleife) gesetzt, kann er den korrekten Indexer auflösen.

int index = 0;
if(list[index] == null) {
...
}

Ein Cast direkt auf int hingegen funktioniert nicht (er nutzt wieder den Enum-Indexer):

if(list[(int) 0] == null) {
..
}

Lustiger Weise lässt sich die Solution nicht mehr kompilieren, sobald ich einen weiteren Enum-Indexer hinzufüge:

The call is ambiguous between the following methods or properties: 'DumpSolution.MyTypeList.this[DumpSolution.MyEnum]' and 'DumpSolution.MyTypeList.this[DumpSolution.MyEnum2]'

Die simpelste Lösung ist, einfach den Standard-Indexer zu überschreiben:

    public class MyTypeList : List<string>
    {
        public string this[MyEnum myEnum]
        {
            get { return this.FirstOrDefault(item => item == Enum.GetName(myEnum.GetType(), myEnum)); }
        }

        public string this[MyEnum2 myEnum]
        {
            get { return this.FirstOrDefault(item => item == Enum.GetName(myEnum.GetType(), myEnum)); }
        }

        public new string this[int index]
        {
            get { return base[index]; }
            set { base[index] = value; }
        }
    }

Danach funktioniert der Code oben problemlos und korrekt. Ach ja, ein anpassen des Enums wie folgt brachte auch keinen Erfolg.

enum MyEnum {
   Value1 = 1,
   Value2 = 2
}

Ich kann mir vorstellen, dass es das Problem auch bei anderen Listen gibt, ich selbst habe es aber aktuell nur bei List<T> festgestellt. Im Netz findet man einige Einträge dazu, dazu auch eine Erklärung (welche mich aber nur bedingt zufrieden stellt)

Ich habe ein kleines Beispiel, welches ihr hier herunterladen könnt.