Markieren beim Umbenennen

Beim direkten Umbenennen von Dateien in SpeedCommander wird im Eingabefeld der gesamte Dateiname inklusive der Erweiterung markiert. Die Dateierweiterung behält SpeedCommander automatisch bei, zum Entfernen der Erweiterung schließt man den Dateinamen einfach mit einem Punkt ab.

Wer dieses Verhalten nicht kennt, der markiert erst den Dateinamen, um die Erweiterung nicht zu verlieren. Der Explorer in Vista markiert deshalb nur noch den Dateinamen ohne Erweiterung, so dass der Anwender frei drauflos schreiben kann, ohne sich um die Erweiterung kümmern zu müssen.

Dieses Verhalten habe ich nun auch SpeedCommander beigebracht. Der erste Tastendruck (F9 bei Verwendung des Standardkürzels) öffnet das Eingabefeld und markiert nur den Namensbestandteil. Ein weiterer Tastendruck markiert die Erweiterung, der nächste den gesamten Text:

Markierung beim Umbenennen

Mit <F9><F9> kann man so schnell die Erweiterung ändern, <F9><F9><Backspace> löscht die Erweiterung. Zusätzlich lässt sich im Einstellungsdialog festlegen, welche Anfangsmarkierung (gesamter Text, Dateiname, Erweiterung) bevorzugt werden soll.

Fehler in CListCtrl::SortGroups

Die MFC-Unterstützung für die ComCtl32.dll von Windows XP war ja lange ziemlich mager, und so habe ich mir damals meine eigenen Wrapper-Funktionen geschrieben. Die MFC9 von Visual Studio 2008 ist mittlerweile auf dem aktuellen Stand, und so habe ich meine Wrapper-Funktionen zugunsten der MFC-Funktionen entfernt.

Dabei ist mir aufgefallen, dass in der CListCtrl-Methode SortGroups die Parameter vertauscht sind. Die Implementation schaut so aus:

AFX_INLINE BOOL CListCtrl::SortGroups(PFNLVGROUPCOMPARE _pfnGroupCompare, LPVOID _plv)
{
    ASSERT(::IsWindow(m_hWnd));
    return (BOOL)::SendMessage(m_hWnd, LVM_SORTGROUPS, (WPARAM)(LPARAM)_plv, (LPARAM)_pfnGroupCompare );
}

während das API-Makro ListView_SortGroups aus der commctrl.h so lautet:

#define ListView_SortGroups(hwnd, _pfnGroupCompate, _plv) \
    SNDMSG((hwnd), LVM_SORTGROUPS, (WPARAM)(_pfnGroupCompate), (LPARAM)(_plv))

Beim Aufruf von SortGroups bekommt die Listenansicht also vertauschte WPARAM und LPARAM-Parameter und macht entweder gar nichts oder stürzt ab.

Damit SortGroups richtig funktioniert, muss es in afxcmn3.inl wie folgt geändert werden:

AFX_INLINE BOOL CListCtrl::SortGroups(PFNLVGROUPCOMPARE _pfnGroupCompare, LPVOID _plv)
{
    ASSERT(::IsWindow(m_hWnd));
    return (BOOL)::SendMessage(m_hWnd, LVM_SORTGROUPS, (WPARAM)_pfnGroupCompare, (LPARAM)_plv );
}

Zu diesem Problem gibt es übrigens auch einen Connect-Eintrag. In diesem wird das Problem der vertauschten Parameter klar erläutert, aber Microsoft kann es ohne Demoprojekt oder Minidump nicht nachvollziehen…

Eine Beta zwischendurch

Der 3-Monatsrhythmus für SpeedCommander-Updates hat sich eigentlich ganz gut bewährt. Er gibt mir als Entwickler genug Zeit für neue Funktionen und Bugfixes und der Anwender freut sich über die regelmäßige Produktpflege.

Mein kleiner privater Betatesterkreis bekommt während der ganzen Entwicklung ständig neue Versionen zum Testen vorgesetzt. So können neue Funktionen sehr zeitnah getestet werden. Zudem ist es sehr viel einfacher, Fehler zu beseitigen, wenn man noch im Thema drinsteckt und weiß, was man gerade gemacht oder geändert hat.

Um euch die Zeit bis zum nächsten Update etwas zu verkürzen, werde ich in unregelmäßigen Abständen immer wieder mal eine frische Betaversion zum öffentlichen Testen anbieten. Der Einsatz der Betaversion geschieht selbstverständlich auf eigene Gefahr. Da größere Neuerungen aber immer zuerst intern abgeklopft werden, sollte das Risiko eigentlich recht überschaubar sein.

Für eure Rückmeldungen habe ich im Forum eine neue Sektion eingerichtet. Neue Betaversionen werden entweder dort oder hier im Blog angekündigt. Und wer weiß, vielleicht wird ja der eine oder andere später in den internen Betakreis aufgenommen.

Dateigrößen in KiB

Einige Anwender haben sich die Anzeige der Dateigrößen in ganzzahligen KiBs gewünscht. In SpeedCommander 12.20 wird es daher neben den bisherigen Optionen Byte, Byte/KiB und Automatisch auch die Option KiB geben:

Dateigrößen in KiB

SysLink-Control unter Windows 2000

Mit Hilfe des SysLink-Controls lassen sich anklickbare Hypertext-Elemente in einem Fenster darstellen. Die Formatierung des Textes erfolgt mit Hilfe von <a>anklickbarer Text</a>-Tags. Bei Aktivierung durch Maus oder Tastatur wird das Elternfenster informiert und es kann die jeweilige Aktion durchführen. Leider ist das SysLink-Control erst ab der ComCtl32.dll V6 enthalten und lässt sich so nur ab Windows XP verwenden.

Unter Windows 2000 gibt es ebenfalls ein SysLink-Control. Es ist aber nicht Bestandteil der ComCtl32.dll, die Implementierung erfolgt in der Shell32.dll. Mit Hilfe der Funktion LinkWindow_RegisterClass lässt sich das Control registrieren und verwenden. Der hauptsächliche Unterschied zum SysLink-Control von Windows XP ist der Name der Fensterklasse. Unter Windows XP heißt das Control SysLink, unter Windows 2000 Link Window. Zudem unterstützt die Windows 2000-Implementierung keine HREF und ID-Attribute innerhalb des Anchor-Tags.

Die verschiedenen Fensterklassen-Namen erschweren die Verwendung von SysLink-Controls in Dialogvorlagen. Der Dialog kann nur erzeugt werden, wenn alle verwendeten Fensterklassen registriert sind. Der Dialogeditor von Visual Studio verwendet SysLink als Fensterklasse, das verhindert aber die Anzeige des Dialogs unter Windows 2000.

Mit einem kleinen Trick lässt sich das Problem recht einfach lösen. Beim Start der Anwendung wird geprüft, ob die Fensterklasse SysLink existiert. Wenn nicht, dann wird mit Hilfe von LinkWindow_RegisterClass die Fensterklasse Link Window registriert. Anschließend ruft man die Fensterklassen-Daten für Link Window ab, ändert den Namen auf SysLink und registriert die Klasse unter dem neuen Namen. Nun kann man auch unter Windows 2000 mit SysLink arbeiten.

Das ganze sieht dann so aus:

BOOL RegisterCommonControls()
{
    // Common Controls initialisieren
    INITCOMMONCONTROLSEX initCCex;
    initCCex.dwSize = sizeof(initCCex);
    initCCex.dwICC = ICC_WIN95_CLASSES | ICC_LINK_CLASS;

    // Common Controls initialisieren
    InitCommonControlsEx(&initCCex);

    // Erfolg?
    BOOL fSuccess = FALSE;

    // Fensterklasse abrufen
    WNDCLASSW wndLinkClass;
    if (!GetClassInfoW(NULL, L"SysLink", &wndLinkClass))
    {
        // Registrierungsfunktion
        typedef BOOL (WINAPI* pfnLinkWindowRegisterProc)();

        // Shell32-Dll laden
        HINSTANCE hModShell32 = LoadLibraryW(L"shell32.dll");
        if (NULL != hModShell32)
        {
            // Funkion importieren
            pfnLinkWindowRegisterProc pfnLinkWindowRegister = reinterpret_cast<pfnLinkWindowRegisterProc>(GetProcAddress(hModShell32, MAKEINTRESOURCEA(258)));
            if (NULL != pfnLinkWindowRegister)
            {
                fSuccess = pfnLinkWindowRegister();
            }

            // Dll freigeben
            FreeLibrary(hModShell32);
        }

        // Fensterklasse fuer "Link Window" registriert
        if (fSuccess)
        {
            // Fensterklasse abrufen
            if (GetClassInfoW(NULL, L"Link Window", &wndLinkClass))
            {
                // Fensterklasse auf SysLink setzen
                wndLinkClass.lpszClassName = L"SysLink";

                // Fensterklasse registrieren
                if (!RegisterClassW(&wndLinkClass))
                {
                    fSuccess = FALSE;
                }
            }

            // Fehler beim Abruf der Fensterklasse
            else
            {
                fSuccess = FALSE;
            }
        }
    }

    // Fensterklasse existiert bereits
    else
    {
        fSuccess = TRUE;
    }

    // Erfolg
    return fSuccess;
}

Saubere Abstürze

Für die nächste Version (12.20) habe ich den Dialog, der nach einem unverhofften Absturz angezeigt wird, etwas funktioneller gestaltet. Per Mausklick kann man das Einstellungsverzeichnis öffnen, in welchem die Reportdateien gespeichert werden, und sich den Fehlerreport auch gleich anschauen:

Hinweis nach Absturz

Beim Klick auf die eMail-Adresse oder auf Fehlerbericht senden wird eine eMail mit Reportdatei und Speicherabbild erstellt, der Anwender muss nur noch eine kurze Beschreibung hinzufügen, nach welcher Aktion der Absturz passierte:

eMail an Support

Voraussetzung dafür ist ein MAPI-kompatibles eMail-Programm, Webmail-Portale müssen hier leider passen.

Vom Pech verfolgt

Das Anfang der letzten Woche zum Download freigegebene Feature Pack für Visual Studio 2008 steht unter keinem guten Stern. Nachdem sich schon die Betaversion vom Ende des letzten Jahres unter bestimmten Konfigurationen nicht installieren ließ, bringt die finale Version nun neue Installationsprobleme mit sich. Auf nicht-englischen Systemen bzw. auf englischen Systemen mit deutscher Regions- und Spracheinstellung lässt sich das Feature Pack nur installieren, wenn man die Regions- und Spracheinstellung vorher auf Englisch (USA) stellt.

Das 32-bittige Laufzeit-Installationspaket lässt sich auf Windows Vista und Windows Server 2008 erst gar nicht installieren, während der Installation wird folgende Fehlermeldung angezeigt:

Fehler bei der Installation unter Vista

Auf Systemen, auf denen die Installation funktioniert, werden die Assemblies für ATL und OpenMP für eine falsche Prozessorarchitektur installiert, so dass Anwendungen, welche diese Module verwenden, nicht funktionieren.

Es ist schon verwunderlich, dass diese Probleme beim internen Test nicht aufgefallen sind. Man kann nur hoffen, dass der eigentliche Quellcode besser getestet wurde. Auf meine Arbeit hat das aber alles keine Auswirkungen, weil ich das Feature Pack auf meinem Entwicklungssystem nicht installieren werde.

Seriennummer kopieren

Ein häufig geäußerter Wunsch war, dass man die Seriennummer aus dem Info über SpeedCommander-Dialog in die Zwischenablage kopieren kann, um beim Abschreiben Tippfehler zu vermeiden. Mit dem nächsten Update 12.20 (geplant für Juni) wird das endlich möglich sein. Manchmal braucht man nur die richtige Idee, und dann geht alles ganz fix:

Seriennummer kopieren

Wenn die Seriennummer nicht markiert ist, dann sieht es so aus wie bisher.

Unter der Haube

Es ist ja allgemein bekannt, dass das von True Image Home erstellte Notfallmedium auf Linux basiert. Als Anwender bekommt man davon kaum etwas mit, da man nur eine grafische Oberfläche zu sehen bekommt, die zudem noch wie Windows ausschaut.

Drückt man aber nach der Anzeige der grafischen Oberfläche Strg+Umschalt+F2, dann befindet man sich plötzlich in der Kommandozeilenumgebung und kann sich z.B. mit /bin/sysinfo die Systemumgebung sowie die Startmeldungen anschauen oder sich auf Entdeckungsreise durch Linux begeben. Mit Strg+Umschalt+F1 wechselt man wieder zur grafischen Oberfläche zurück.

Eierköpfe

Man sollte keine eMails schreiben, wenn man sich gerade geärgert hat. Ansonsten kommt so etwas dabei heraus:

Morgen erst mal Ihr Eierköpfe,

Kann ja wohl nicht sein das ich den Reg.Schlüssel richtig im Programm eingebe und damit freien Zugang zum Programm habe, aber es unmöglich ist den selben Schlüssel auf eurer Webside einzugeben um support zu erhalten, sprich wenn updates raus kommen. Jedes mal bekomme ich die Meldung ” falscher Freischaltcode”.

Wenn Ihr keinen Support leisten wollt, ist das Euer Ding, aber geht mir mit dieser Fehlermeldung nicht auf den Sack. Dann gibt es halt keine Weiterführung unserer Geschäftsbeziehung.

PS: Und fangt mir nicht an mit wie man in den Wald hinein ruft…

Ihr könnt mich mal

Max (Name geändert) 

Auf meinen freundlichen Hinweis, dass auf der Registrierungsseite alles erklärt wird, hat sich der Anwender für seine Wortwahl entschuldigt.

Ich beobachte schon seit längerer Zeit, dass sich die Umgangsformen im eMail-Verkehr stetig verschlechtern. Immer häufiger wird auf die Anrede und/oder die Grußformel verzichtet, auch der Ton verschärft sich zunehmend. Eine Ursache dafür ist vielleicht der Umstand, dass man eine eMail schnell ohne Nachdenken schreiben und verschicken kann. Bei Briefen dauerte der Vorgang erheblich länger, zzgl. dem Gang zum nächsten Briefkasten.