Framework Studio

Als die Megos vor einiger Zeit vor der wichtigen Frage stand, womit sie in Zukunft ihre Software entwickeln will, haben wir uns ein Produkt der deutschen Firma Framework Systems näher angeschaut, das sich Framework Studio nennt.

Ich war überrascht, was ich da zu sehen bekam, denn dieses System hat eine sehr interessante Architektur. Es läuft für mich quasi unter dem Motto „Erstaunlich, was man mit .NET alles machen kann“.

Beim Framework Studio handelt es sich um ein Software-Entwicklungssystem. Es entstehen Web-Applikationen, die man mit Hilfe einer Java-basierten Client-Komponente und einer C#/.NET-basierten Server-Komponente ausführt, zwischen denen via SOAP kommuniziert wird. Applikationen entstehen einerseits durch stark Tool-unterstützes Spezifizieren von Forms, Datenbank-Strukturen und Verarbeitungs-Logik, und andererseits durch Programmieren spezieller Logik direkt in C#.

Wie ein ausführlicher Artikel (Teil 1, Teil 2) erläutert, erlauben die Architektur des Systems und die Struktur der damit geschaffenen Applikationen eine ziemlich weit gehende Anpassbarkeit von Standard-Software.

Die Firma Nissen & Velten Software GmbH hat offenbar eine ERP-Lösung namens NVinity mit Hilfe des Framework Studio realisiert.

Trotz aller Faszination über das, was Framework Systems hier geleistet hat, haben wir auf den Einsatz von Framework Studio verzichtet. Ein Hauptgrund war unsere Entscheidung, nicht oder zumindest nicht ausschliesslich auf Web-Applikationen zu setzen, wie das hier nötig gewesen wäre. Jemandem, der hierin kein Problem sieht, kann ich aber durchaus empfehlen, sich die kostenlose Probeversion des Produkts mal anzuschauen. Selbst wenn es am Schluss nicht zu einem tatsächlichen Einsatz reicht, kann man als Software-Architekt mindestens die eine oder andere Idee mitnehmen und in seine „konventionelle“ C#-Applikation einbauen.

Wenn dies nun etwas gar nach Werbung klingt: Nein, ist es nicht, aber ich kann eben meine Sympathie für eine Firma nicht verhehlen, die wie die Megos gegen Ende der 1980er-Jahre mit EMBASSY den Mut hat, Neues in einer Art zu versuchen, die man eher bei viel grösseren Firmen erwarten würde.

Etwas beunruhigend, dass offenbar NVinity immer noch die einzige vorzeigbare in Framework Studio realisierte Applikation ist. Da liegt noch viel Arbeit vor der Firma Framework Systems; Innovationen haben es eben oft schwer…

Advertisements
Veröffentlicht in 1. Schlagwörter: , . Leave a Comment »

Bookmarks in Visual Studio

Es muss irgendwie so sein, dass die Anzahl Zeilen meiner C#-Source-Files eine entscheidende Grösse überschritten hat, denn ich begann mich vor kurzem dafür zu interessieren, ob man in Visual Studio Textstellen markieren und dann auf einfache Weise zu diesen Stellen zurückkehren kann. Die Antwort: Ja, natürlich kann man, mit Hilfe von Bookmarks.

Wie man in der Microsoft-Original-Doku zu diesem Thema hier nachlesen kann, gibt es ein eigenes Fenster für das Verwalten von Bookmarks, die Möglichkeit Bookmarks einen Namen zu geben und sogar einen Mechanismus, sie zu Gruppen zusammenzufassen. Eine Kurz-Anleitung inklusive Tastenkürzel findet man z.B. hier.

Ich versuchte daraufhin, eine Arbeitsweise mit Hilfe von Bookmarks zu unterstützen, die wir in der Megos seit vielen Jahren verwenden: Unsere Source-Files enthalten spezielle textuelle Markierungen, die jeweils am Beginn bestimmter Sektionen in den Files stehen, und unser eigener Programm-Editor kann bei Bedarf automatisch Bookmarks auf diese Markierungen setzen.

Auf diese Weise löst man – elegant, wie ich meine – das Problem, dass Bookmarks eine recht flüchtige Sache sind und zudem schlecht von einem Rechner zum nächsten transportiert werden können.

Ich dachte, etwas Ähnliches sei in Visual Studio sicher mit Hilfe eines recht einfachen Macros zu implementieren: Text von vorne bis hinten nach den fraglichen Markierungen absuchen, für jede gefundene Markierung ein Bookmark mit dem in der Markierung enthaltenen Namen definieren, fertig. Es sieht allerdings so aus, als könne man den Namen eines Bookmarks nicht „von aussen“ setzen, weil die entsprechende COM-Schnittstelle (EnvDTE.TextSelection) dies leider nicht anbietet. Das wartet irgendwie noch auf eine gute Umgehungslösung…

Zwei Dinge noch, die vielleicht interessant sind, wenn Sie Bookmarks ernsthafter einsetzen wollen: Gespeichert werden sie in .suo-Files (Solution User Options), die normalerweise nicht sichtbar sind, da sie das hidden-Attribut tragen. (Diese Files sind nicht geeignet, sie per Source Control zu verwalten, was die von mir beschriebene Bookmark-Auto-Regenerier-Funktion umso dringender macht.) Und hier wird beschrieben, wie man die Farbe der markierten Zeile ändern kann, so dass das Bookmark besser sichtbar wird – mit der Nebenwirkung zwar, dass man Breakpoints nicht mehr so einfach setzen kann.

Veröffentlicht in Keine Kategorie. Schlagwörter: . Leave a Comment »

.NET als Nachfolger von Win32

Kürzlich kam mir Petzolds Original-„Hello World“ für Windows in C wieder mal in die Hände. Als ich so am Staunen war über die Schönheit des Win32-API in seiner unverfälschten, puren Form, erinnerte ich mich daran, dass vor nicht allzu langer Zeit ziemlich heftig darüber spekuliert worden ist. Man fragte sich, ob Microsoft .NET nicht nur baut, damit wir Applikationsprogrammierer etwas produktiver werden, sondern um mittelfristig Win32 abzulösen und damit die gesamte Windows-Programmierung auf das nächste Level zu heben: das .NET-Framework als das neue Windows, zumindest was das API angeht.

Das hat meine Neugierde geweckt, und ich habe etwas recherchiert, wie es unterdessen um diese Spekulationen steht.

Per Google findet man relativ leicht heraus, dass der Höhepunkt dieses „Memes“ so um 2003/2004 herum gewesen sein muss, als die Gerüchte ins Kraut schossen, wie wohl das neue Windows Code-Name Longhorn aussehen würde. Von grossen, in .NET implementierten Betriebssystem-Teilen war die Rede. Und in diesem Longhorn FAQ, das offenbar als seriös genommen werden will, findet man folgende Aussage: „In the technology generations leading up to Longhorn, Microsoft has been moving to a .NET-based managed code environment dubbed WinFX, and the Longhorn generation will finally mark a clean split with the Win32 APIs of the past.“

Es ist mir hingegen nicht gelungen, unter Stichworten wie future windows API interessante aktuelle Informationen zu finden. Vielleicht hat ja Microsofts lange und schmerzreiche Schwangerschaft mit Windows Vista zu einer gewissen Ernüchterung geführt, wie schnell man Win32 ablösen könnte und wie gross der Aufwand dafür wirklich wäre.

In einer Diskussion aus dem Jahre 2004 stiess ich noch auf folgendes Argument, das mir heute noch relevant scheint und das ich ganz interessant fand: Microsoft verdient bekanntermassen nur mit 2 Dingen richtig massig Geld, einerseits mit Windows selbst, und andererseits mit Office. Die Office-Programme basieren auf Win32. Wenn also Microsoft mit .NET als Win32-Ablösung wirklich ernst machen will, ohne eine der beiden „cash cows“ zu verlieren, müsste sie einen kompletten Rewrite der Office-Programme ins Auge fassen. Von einem solchen ist nichts bekannt.

Aber wie dem auch sei, ob nun Microsoft etwas zu hoch gezielt hat ursprünglich oder nicht, gedeiht das .NET-Framework prächtig, und es kommt wohl kaum mehr jemandem in den Sinn, ein normales Applikationsprogramm auf Win32 aufzusetzen.

Dass das Framework unterdessen durchaus das Zeug hätte, als Windows-Programmieroberfläche zu fungieren, sieht man übrigens an der PowerShell, die ja mit Hilfe von .NET implementiert worden ist.

Zu guter letzt noch ein paar Links: ein Artikel von Joel Spolsky aus dem Jahre 2004 (immer noch lesenswert, falls man ihn nicht schon kennt), und die Website The Old New Thing mit manchmal geradezu abenteuerlichen Geschichten über die Entstehung gewisser Dinge rund um Win32, etwa diese Story mit dem Titel What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?.

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . Leave a Comment »

Des Programmierers liebste Schrift

Wenn man als Programmierer mehrere Stunden pro Tag auf Source-Code blickt, spielt es natürlich eine grosse Rolle, in welchem Font dieser Code angezeigt wird, speziell dann, wenn man eine relativ kleine Schrift bevorzugt, um viel Code auf einmal sichtbar zu haben.

Die Megos hat vor über 15 Jahren sogar zwei Windows-Bitmap-Fonts namens EMBASSY Proportional und EMBASSY Monospaced selbst erstellt, weil damals für kleine Punkt-Grössen einfach nichts zu finden war, was wir als wirklich brauchbar bezeichnet hätten. Es ist denn auch EMBASSY Monospaced 8 Punkt, was ich heute für die C#-Programmierung im Visual Studio verwende.

Als ich kürzlich ausprobieren wollte, ob es nicht mit 9 Punkt noch etwas besser aussehen würde, und ich feststellen musste, dass die nächste mögliche Grösse 10 Punkt ist, habe ich mich im Internet etwas umgeschaut, was andere Leute heutzutage denn so verwenden und empfehlen.

Dabei war ich ziemlich überrascht über die Fülle von Artikeln, Blog-Einträgen und Forum-Postings zu diesem Thema. Auch heute scheinen einige Leute noch nicht den Font gefunden zu haben, den sie sich für ihren Code-Editor – auf welcher Plattform auch immer – eigentlich wünschen würden.

Das hat mich bewogen, hier etwas Werbung zu machen für unsere EMBASSY-Fonts, welche wir nach wie vor als „konkurrenzfähig“ ansehen, die wir als Freeware zur Verfügung stellen und die vielleicht etwas mehr Aufmerksamkeit als bisher durchaus vertragen könnten. Man findet sie auf der Megos-Website hier zum Download.

Und hier noch ein Ausschnitt eines Screenshots, EMBASSY Monospaced in 8 Punkt in Visual Studio:

Veröffentlicht in Keine Kategorie. Schlagwörter: . Leave a Comment »