Stingray war Mitte/Ende der neunziger Jahre zusammen mit Dundas einer der führenden Anbieter für MFC-Komponenten. Ich kann mich noch genau daran erinnern, wie perplex ich damals war, als mich unmittelbar nach einer Bestellung Scott Wingo (Mitbegründer von Stingray und MFC-Experte) anrief und mir für die Bestellung dankte.

Im Januar 1998 wurde Stingray dann von Rogue Wave übernommen. Anfangs lief alles wie gewohnt weiter, aber nach einem Jahr wurden die Strukturveränderungen dann sichtbar. Die Stingray-Produktreihe war  plötzlich nur noch eine unter vielen, die Preise stiegen an und auch die Aktualisierung der Komponenten verlangsamte sich spürbar. Das war dann der Moment, in dem ich mich nach anderen Alternativen umgeschaut und bis 2003 die BCGControlBar verwendet habe.

Heute kam wieder ein Newsletter von Rogue Wave, in dem die Verfügbarkeit von Objective Studio 10.2 angekündigt wird. Beim Anschauen der Demos fand ich mich in der Vergangenheit wieder. Im Vergleich zu der letzten von mir gekauften Version 6 vor 10 Jahren hat sich kaum etwas geändert. Alles scheint auf dem Stand von Office 2000 stehengeblieben zu sein.

Kurz nach dem Erscheinen von Windows 7 ermöglicht die Preview von Objective Studio 11, dass sich Symbolleisten, Menüs und Bedienelemente wie die von nativen Vista-Applikationen verhalten. Bei Erscheinen von Windows 8 kommt dann sicher auch Unterstützung für Windows 7.

Mein Interesse an einem Produkt lässt auch spürbar nach, wenn Preisinformationen nicht öffentlich sichtbar sind und diese erst nach einer Registrierung angefragt werden können. Wenn ich mir die in der eMail aufgelisteten Preise anschaue, dann erschließt sich auch, warum Rogue Wave das so handhabt.

Objective Toolkit kostet in der 32-bit Ausführung 1.045 €, die 32/64-bit Variante ist für 1495 € erhältlich. Für das ganze Studio (Toolkit, Edit, Views, Chart, Grid) zahlt man 2495 € in der 32-bit Ausführung und 3395 € für die 32/64-bit Kombination. Die Preise verstehen sich netto zzgl. der entsprechenden Mehrwertsteuer. Das braucht man wohl nicht mehr zu kommentieren, wenn man sich mal die Preise von Codejock und BCGSoft anschaut. Das Produkt des damaligen Mitbewerbers Dundas gibt es übrigens mittlerweile für lau.

Mit Datenbankprogrammierung hatte ich bisher weniger zu tun. Einzige Ausnahme war das kleine Programm SpeedCD, welches seine Daten in einer dBase-Datenbank abgelegt hat. Aber das ist schon lange her, damals war ich noch glücklich mit Turbo Pascal für Windows.

Meine Erfahrungen mit dem MSSQL-Server beschränken sich daher auf das Ausführen eines Installationsprogramms sowie das Installieren eines Servicepacks. Mehr war für das Aufsetzen des TFS vor einem Jahr auch nicht nötig. Ich hatte aber keinen blassen Schimmer, wie man die Datenbankdateien mit Boardmitteln sichert und wiederherstellt. Ab und zu soll es ja mal passieren, dass einen die Daten aus unerfindlichen Gründen verlassen oder man im TFS etwas macht, was man hinterher tief bereut. Sicherungen sollen da helfen.

Glücklicherweise fand ich in der c’t einen Hinweis auf das Programm DBSave. Die der Zeitschrift beiliegende ältere Vollversion war leider etwas eingeschränkt, sie sicherte nur eine Datenbank. Eine Lizenz der aktuellen uneingeschränkten Version kostet 49 Euro. Wenn man aber nur eine Serverinstanz hat und auf automatische oder inkrementelle Sicherungen verzichtet, dann kann man DBSave auch als Freeware einsetzen (kommerziell und privat). Beim ersten Start muss dann die Eingabe des Freischaltcodes abgebrochen werden.

DBSave präsentiert sich als Formularanwendung mit mehreren Registerkarten. Auf der ersten Seite wird der Name des SQL-Servers eingetragen. Nach erfolgreicher Verbindungsaufnahme werden die Datenbanken angezeigt:

Die dritte Seite fragt das Ziel der Sicherung ab. Unterhalb des Ordners wird dann für jede Datenbank ein eigener Ordner erstellt, in dem die Sicherungsdaten abgelegt werden:

Ist alles eingetragen, dann kann man die Konfiguration über die Symbolleiste speichern. Der Start der manuellen Sicherung ist etwas schwer zu finden, da er über das Kontextmenü des Symbols im Infobereich erfolgt:

Der Abschluss der Sicherung wird über eine Statusmeldung mitgeteilt:

Die Sicherung erfolgt im laufenden Betrieb, am SQL-Server muss nicht herumgespielt werden. Also genau das richtige für einen, der sich nicht weiter auskennt.

z42 fragte gestern in einem Kommentar zu Projektspezifischen Umgebungsvariablen, mit welchem Programm ich die Screenshots unter Vista mache. Bis einschließlich Windows XP habe ich immer SnagIt v6 verwendet, was auch schon etwas älter ist. Mit Vista hatte SnagIt aber so seine Probleme, auch die neueren Versionen haben bei Dialogen nicht immer 100%ig funktioniert.

Während den Anfängen der Vista-Programmierung habe ich oft im Blog von Kenny Kerr gelesen und somit auch die Entwicklung seines Screenshot-Tools Window Clippings mitverfolgt. Im Gegensatz zu anderen Programmen entfernt Window Clippings den durchscheinenden Hintergrund unter Vista (z.B. bei Titelzeilen) automatisch, so dass auf den Screenshots keine Unschönheiten auftauchen. Das Programm kann natürlich auch eine ganze Menge mehr, aber das ist alles auf der Webseite beschrieben.

Mit der Version 2.0 wurde die Software kostenpflichtig, $18 sind aber ein fairer Preis.

Das sagte gestern früh der UPS-Mensch, als er mir ein am Dienstag bei Intel Press bestelltes und am Mittwoch verschicktes Bücherpaket in die Hand drückte und ich es einfach nicht glauben konnte, dass die Auslieferung so schnell erfolgte.

Wer das bis zum 30. Juni geltende Angebot auch noch wahrnehmen möchte: Zu den $69,95 für die beiden Bücher kommen noch einmal $26,00 für die UPS-Expresszustellung (einzige Versandoption) sowie knapp 15 Euro Zollgebühren (bei Übergabe fällig). Eins der beiden Bücher (Multi-Core Programming) gibt es ab Mitte Juni auch in Deutsch, bei Amazon wird es bereits für 54,90 Euro gelistet.

Ich habe schon immer eine Abneigung gegen die Anzeige von Symbolen im Explorer-Kontextmenü. Das hatte anfangs damit zu tun, dass dieses Menü dafür einfach nicht vorgesehen war und diese Symbole aufgrund der beschränkten Möglichkeiten in der Regel nur 14 Punkte groß waren und mit maximal 16 Farben angezeigt wurden. Meistens brauchte man also viel Phantasie, um eine mögliche Information erkennen zu können.

Mit der Zeit waren aber immer mehr Programmierer der Meinung, mit einem entsprechenden Symbol punkten zu können. Ein Farbklecks mag ja bei einem Menü ohne weitere Symbole noch herausragen, aber bei vielen Farbklecksen fällt die Auswahl schon schwerer.

Unter Vista sind die einzelnen Kontextmenü-Einträge etwas größer, was vermutlich mit dem Befehl Als Administrator ausführen zusammenhängt. Dieser Befehl enthält als einziger ein Symbol, was wohl mit seiner besonderen Bedeutung zusammenhängt. Anfangs war das etwas ungewohnt, aber mit der Zeit empfand ich die Menüs aufgrund der größeren Abstände auch als besser lesbar.

Nach der Installation von TortoiseSVN sah das Kontextmenü aber plötzlich ganz anders aus. Die Abstände zwischen den Einträgen waren extrem verkürzt, zudem ist das Schneckensymbol Schildkrötensymbol (Korrektur) in meinen Augen nicht wirklich eine Augenweide, vom fehlenden Abstand zwischen Symbol und Text mal ganz abgesehen:

Beim Stöbern im Quellcode von TortoiseSVN fand ich glücklicherweise eine Option, über die man das Verhalten im Kontextmenü steuern kann:

REGEDIT4

[HKEY_CURRENT_USER\Software\TortoiseSVN]
“OwnerdrawnMenus”=dword:00000002

Damit unterlässt es TortoiseSVN, die Proportionen vom Kontextmenü zu verändern und fügt keine eigenen Symbole hinzu. So gefällt mir es dann wieder.

Seit mehr als 11 Jahren nutze ich Visual SourceSafe als Quellcodeverwaltung, letzte Woche habe ich meine Projekte auf Subversion umgestellt. Als SourceSafe-Geschädigter muss man sich aber erst einmal an das neue Modell gewöhnen. Unter SourceSafe checkt man die zu bearbeitenden Dateien einzeln oder in Gruppen aus, editiert sie und checkt sie dann wieder ein. Eingecheckte Dateien werden mit einem Schreibschutz-Attribut versehen und können daher nicht einfach so bearbeitet werden. Damit das Auschecken funktioniert, muss Visual Studio eine ständige Verbindung zum Server mit der Quellcodeverwaltung haben. Arbeitet man mal unterwegs, dann simuliert Visual Studio ein Auschecken, indem es das Schreibschutz-Attribut der lokalen Datei entfernt. Beim nächsten Andocken an den Server werden die Dateien dann richtig ausgescheckt.

Mit Subversion ist das alles ein wenig anders. Nach dem Abruf einer Arbeitskopie vom Subversion-Server kann man Dateien beliebig editieren. Sind die Änderungen abgeschlossen, werden die Dateien wieder auf den Subversion-Server übertragen. Dieser speichert dann nur die Unterschiede und hält so seine Datenbank möglichst klein. Eine Verbindung zum Subversion-Server muss nur während des Abrufens/Aktualisierens der Arbeitskopie und des Übertragens zurück bestehen. Damit lässt es sich auch problemlos unterwegs arbeiten.

Die Unterstützung von mehreren Entwicklungszweigen (Branches) ist in SourceSafe quasi gar nicht vorhanden. Zudem wird die Verbindung eines Projekts zur Quellcodeverwaltung direkt in der Projektdatei gespeichert, was die Ablage von Projektkopien in anderen Ordnern (z.B. bei einem neuen Release) sehr erschwert. Wenn man dann die Verbindung nicht löst, möchte Visual Studio immer die Verbindung zum Originalprojekt herstellen.

Mit Subversion gibt es diese Probleme nicht. Verschiedene Entwicklungszweige sind einfach zu verwalten, auch die Übernahme von Änderungen in andere Zweige ist problemlos möglich. Die Projektdateien sind anderen Dateien gleichgestellt und enthalten keine datenbankspezifischen Informationen mehr.

Das ermöglicht es mir jetzt endlich, ein paar Wochen vor der Veröffentlichung eines Updates einen separaten Zweig dafür zu erstellen, die aktive Entwicklung dafür einzustellen und wirklich nur noch nötige Korrekturen vorzunehmen. Die normale Entwicklung an der nächsten Version kann dann schon weitergehen, ohne auf das geplante Update Einfluss zu nehmen.  Damit entfällt nun auch die Wohlverhaltensperiode vor und nach dem Release, in der ich mich zwingen musste, meine Finger im Zaum zu halten. Treten nach dem Update doch noch unerwartete Fehler auf, so können diese im separaten Zweig behoben und schneller als Fix zur Verfügung gestellt werden.

Die Einrichtung von Subversion ist sehr einfach. Nach der Installation wechselt man in der Kommandozeile in das bin-Verzeichnis und richtet svnserver.exe als Dienst ein:

sc create svnserve binPath= “C:\Programme\Subversion\bin\svnserve.exe –service -r D:\Projekte\Subversion” DisplayName= “Subversion” depend= tcpip start= auto

Anschließend muss nur noch ein neues Projektarchiv erstellt werden. Alternativ kann man sich auch das Rundum-Sorglos-Paket VisualSVN Server herunterladen. Dieses installiert einen Apache-Server samt Subversion-Integration und erstellt auch gleich das Projektarchiv. Damit hatte ich meine ersten Gehversuche gemacht, bin aber anschließend auf die performantere Dienst-Methode umgestiegen.

Auf dem Client-Rechner wird TortoiseSVN installiert, damit erfolgt der Zugriff auf die Quellcodeverwaltung bequem aus SpeedCommander (oder dem Explorer) heraus. Für die Integration in Visual Studio empfiehlt sich VisualSVN. Die Einzellizenz kostet $49 und macht sich schnell bezahlt.

Letztlich kann ich jedem SourceSafe-Anwender nur empfehlen, auf Subversion zu wechseln. Beim Einstieg beantwortet die umfangreiche Dokumentation viele Fragen, für die ersten Gehversuche kann man sich ein Projektarchiv zum Spielen einrichten. Mit einer möglichen Konvertierung der SourceSafe-Datenbank habe ich mich nicht beschäftigt, ich wollte einen frischen Start ohne Altlasten.