Erfahrungen mit Visual WebGui Version 6.4.0 Beta (Preview 4)


Erfahrungen mit Visual WebGui Version 6.4.0 Beta (Preview 4)
Visual WebGui, wie komme ich dazu?
Visual WebGui ist ein wirklich interessantes Werkzeug wenn man über Windows Forms Basiswissen verfügt und Anwendungen erstellen möchte, welche im Browser betrieben werden sollen. Ich habe vor ein paar Jahren eine recht umfangreiche ASPX .net Web-Anwendung aufgesetzt. Die Anwendung funktioniert selbst in den aktuellen Browsern noch recht gut. Der Kunde wünscht sich aber heute eine etwas moderne Umsetzung welche auch auf den iPad eingesetzt werden kann. Ebenfalls wäre der Einsatz auf Android Tabelts wünschenswert. Bei diesem Kunden hat man einige kleinere Anwendungen mit Visual WebGui umgesetzt. Warum wurde dort keine native Web-Technik eingesetzt? Ganz einfach, die Kollegen dort verfügen über sehr gutes Fachwissen was Windows Forms Anwendungen angeht. Mit dem ganzen so modernen Web-Kram habe sie keine große Erfahrung. Ziel war es das vorhandene Wissen ohne große Schulung und Weiterbildung schnell produktiv in Web-Anwendungen fließen zu lassen. Da man damit sehr erfolgreich war, sollte ich prüfen ob sich Visual WebGui ebenfalls für eine neue Version der alten ASPX .net Web-Anwendung eignen würde.

Visual WebGui, erst mal Misstrauen…
Erst einmal musste ich mich mit diese Technik vertraut machen. Ich hatte eher kein so großes Vertrauen, konnte mir nicht vorstellen, dass so etwas funktioniert. Ich vermutete das ganze würde langsam laufen und sich zudem durch lange Antwortzeiten und jede Menge Trafik auf der Leitung auszeichnen. Aber schnell erkannte ich, Hut ab, Gizmox eine unglaublich gute Arbeit.

Visual WebGui Wie funktioniert das ganze?
Man installiert einfach die passende Software für sein Visual Studio. Ich arbeite erst mal mit der recht aktuellen 6.4 Beta (Preview 3) Version fürs Visual Studio 2010 Web. In diese Kombination ist das ganze soweit noch völlig Kostenlos. Der gesamte Visual WebGui Source Code kann auf Bedarf von svn Source Code Server von Gizmox herunter geladen werden. Gut ich bekomme hier nicht alles übersetzt, aber zumindest kann man reinschauen.
Das Installieren der Version 6.4 Beta klappte problemlos. Die von mir vorher getestet Version 6.4 Preview 2 hatte noch ein paar kleine Probleme gemacht.

Visual WebGui Hello World,
Ein erster Versuch einfach mal so eine WebGui Form anlegen und sich das Verhalten ansehen. Fühlt sich bis auf kleine Besonderheiten an, als ob man mit Windows Forms arbeiten würde. Verwendet man der Form1.cs aus einem neuen Visual WebGui Application Projekt, funktioniert alles recht einfach. Startet man das Projekt geht der Internet Explorer 9 auf und zeigt die Form an. Was mich hier schon positiv überraschte, es sieht aus wie eine Windows Forms Anwendung und verhält sich so. Ich erweiterte die Form mit den üblichen Controls und stellte fest, wie bei einer echten Windows Forms Anwendung. Nur ohne das ich mich nicht mit HTLM oder ASPX beschäftigen muss. Visual WebGui verkapselt die gesamte Umsetzung für die Browser.

Visual WebGui universell für alle Browser auf dem Windows Desktop?
Nun das wäre auch viel zu schön wenn die Jungs alle gängigen Browser im Griff hätten. Primäre erste Tests auf den großen 3 (IE, FireFox, Chrom) im Desktop Bereich unter Windows XP, Vista, Windows 7 und Windows 8 zeigten zwar geringfügige Unterschiede, aber mit diesen kann man leben. Es ging hier in erste Linie um Buttons die einfach in den unterschiedlichen Browser anders darstellt wurden. Klar mit nativem HTML kann man jedes Pixel beeinflussen, die Frage ist aber, was will man umsetzen.
Visual WebGui 6.4 Preview 2 mochte den Opera nicht!
Der Opera wurde egal auf welche Plattform mit 6.4. Preview 2 nicht unterstützt aktuell. Versucht man die URL der Visual WebGui Anwendung zu öffnen, erscheint einfach eine leere weiße Web-Seite. Gut damit kann ich zumindest sehr gut leben. Meine Kunden sind primär stark auf den IE ausgerichtet. Die paar welche alternativ FireFox oder neuerdings Chrom einsetzen, sind damit ebenfalls zufrieden. Die mittlerweile aktuelle Version 6.4 Beta unterstützt jetzt auch den Opera Browser. Allerdings scheint es mir im Android Opera noch langsamer als in den andern Browsern.

Visual WebGui 6.4 Beta IE 9 / IE 10!
Seit dem IE8 versucht Microsoft immer den Modus zu erkennen, in welchen eine Web-Seite optimal angezeigt wird. Mit der 6.4 Version von Visual WebGui klappt das meist nicht. IE9 ist hier noch halbwegs gut und zeigt die Seiten direkt an, allerdings hatte ich immer wieder das Problem, das sie Seite nur nach Umschaltung in den IE8 Modus voll funktioniert. Ab und an meinte der IE 9 sogar in den Quirks Modus schalten zu müssen. Im IE10 ging das komplett schief. Hier musste man erst einmal von Hand den IE9 Modus wählen. Mittlerweile verwende ich eine Browser Erkennung und setze den entsprechenden Meta Tag vom Microsoft um den IE in den passenden Modus zu schalten.

Visual WebGui Android Tablet, Smartphone und Apple iPad?
Hier kann man fast sagen, sehr gut gemacht. Leider nur fast, Ärger kann man bekommen wenn etwa ein Grid größer als der zur Verfügung stehende Bildschirm ist. Hier streiten sich dann die Controls, für wen ist jetzt das Wischen oder zoomen. Hier kann man mit der Projektierung etwas entgegen wirken. Übel ist ein fetter Fehler, einen Dialog öffnen. Klappt erst mal Klasse, wenn der Bildschirm groß ist. Sollte man es jetzt schaffen die Seite größer zu zoomen, kann man sich nur in der darunter liegende Seite bewegen, die allerdings disabled ist. Man sieht nur die linke obere Ecke des Dialoges. Die Buttons welche meist rechts unten in einem Dialog liegen, sind somit nicht erreichbar. Ein Verschieben des sichtbaren Dialog Ausschnittes ist einfach nicht möglich. Verhindern jetzt Visual WebGui Controls das verringern des Zoomfaktors, ist unter Umständen ein Deadlock erreicht, den man nur durch das Abbrechen der Anwendung gelöst bekommt. Das Zoom und Bewegungsverhalten wird auf einen Smartphone natürlich noch extremer, das hier die Auflösung geringer ist. Das hochgelobte iPad bekleckert sich hier ebenfalls nicht gerade mit Ruhm, der Safari Browser scheint mir hier der schwächste Kollege im ganzen Feld.

Visual WebGui Grafiken…
An dieser Stelle zeigt sich ein großer Unterschied zur normalen Windows Forms Programmierung. Visual WebGui ist in erste Linie der Vermittler zwischen den Web-Server und den Browser. Also wird hier alles irgendwie vermittelt. Ganz klar dass man nicht so einfach direkten Dateisystemzugriff hat und einfach so mal auf eine Datei im Browser zugreifen kann. Der Trick in diesem Fall sind Ressourcen welche Visual WebGui kapselt. Wenn man sich daran mal gewöhnt hat, kann man mit diese Variante ebenfalls recht gut leben.

Visual WebGui GROSSE Grafiken
Wenn ich große Grafiken meine, denke ich an 12000 * 18000 Pixel bzw. größer. Die ASPX .net Anwendung welche ich mit Visual WebGui neu aufsetzen soll, ist eine Dokumentenverwaltung. Die große Masse der Dokumente sind große Pixel Dateien. Ein Viewer soll diese Dokumente anzeigen. Klar, das ist der Hammer eine solche Zeichnung auf einem Tablet zu betrachten. Da ist das Zoomen und einfach hin und her verschieben sehr fein. Aber leider hat die Sache einen großen Hacken. Jetzt vergessen wir einfach mal, dass große Bilder grundsätzlich mal eine lange Ladezeit haben. Für die erste Implementierung wurde die gesamte Zeichnung geladen, nicht wie in der ASPX.net Anwendung nur ein Ausschnitt. Bei den durchschnittlichen Grafiken funktionierte das ganze ohne Probleme. Nun ich böser Entwickler habe aber auch ein paar richtig große Grafiken im Test Angebot. Die Größe welche 32T Pixel in Höhe oder Breite überschreiten. Hier kommt es dann zu spannenden Effekten auf Tablets, Smartphones oder iPads. Weder Rechenleistung noch Speicher diese Light Computer können mit den was heute ein 0815 PC oder Laptop hat mit. Daher so nett es wäre, die Grenzen der Technik zwingen hier wieder eine Ausschnitts Lösung zu implementieren.

Visual WebGui, eine Bewertung,
ein sehr gelungenes Werkzeug, welches einem eine sehr schnelle Entwicklung von Web-Anwendungen ermöglicht. Wie bei allen Werkzeugen / Frameworks bedarf es einer gewissen Lernzeit sich mit den Besonderheiten zu beschäftigen.
Wie ich in meinem ersten Block zu Visual WebGui beschrieben habe, für jemand der in den Microsoft Windows Forms zuhause ist, eine sehr steile Lernkurve. Innerhalb kürzester Zeit sind normale Anwendungsoberflächen wie gewohnt unter Visual WebGui am laufen.
Für die Anzeige von Grafiken sollte man sich einfach etwas Zeit nehmen und verstehen lernen wie Visual WebGui diese handhabt.
Die Controls sind im großen Ganzen sehr gute Umsetzungen in Web Versionen der Windows Forms Controls. Besonders loben will ich hier das GridView von Visual WebGui anführen. Hier wurde in Paging Mechanismus eingebaut der einfach von vor allem sehr schnell funktioniert.
Die Arbeiten an meiner aktuellen Anwendung laufen sehr positiv und nach nun ca. 10 Wochen Entwicklungszeit sind fast alle Vorgaben des Auftraggebers umgesetzt. Wie bei jedem Projekt muss man das ein oder andere Zugeständnis machen. Die erste Version beinhaltet einige weniger elegante Lösungen, die einfach wegen Einschränkungen der aktuellen Android Browser in Kauf genommen werden mussten.
Aber das sind interessante Aspekte, die man in Zukunft noch verbessern kann.

Ich plane noch weitere Blocks zu diesem Thema Visual WebGui:
Beschreibung der Technik einer „ein Form“ Applikation, welche ich für mich ausgewählt habe.
dynamische Meta Tag Erzeugung „viewport“ für mobile Browser

Advertisements

Erfahrungen mit Visual WebGui Version 6.4.0


Spannende Sache, ein Framework welches Windows Forms im Web abbilden soll. Klingt erst mal sehr interessant. Wo ist der Haken bzw. gibt es da einen?

Installation der Version VWG Express Studio with Sources 6.4.0 NETHTML5 Preview2 NET4.0.
Auch wenn ich diese Version jetzt schon mehrfach mit verschiedensten Optionen versucht habe zu installieren, so richtig läuft es leider nicht. Die Registrierung der Visual WebGui Assemblies im globalen Assembly Cache klappt einfach nicht mit dieser Version. Lediglich die Assembly Gizmox.WebGUI.Server wird installiert. Aber egal, man findet die Assemblies im installieren Source Code. Also füge ich diese einfach von Hand in jedes Visual WebGui Projekt mit ein. Ich habe es sowohl unter Windows 7 Professional als auch Windows 8 Professional versucht, in beiden Fällen leider dasselbe Ergebnis.

Sources übersetzen, Beispiel Anwendungen,
Bekomme ich trotz Auflösung der Assemblies nicht zum Laufen. Selbst die vom svn von Visual WebGui abgezogene Version ist alles andere als Übersetzbar. Es fehlen massiv enums. Die müssen da irgendwas am umstellen sein, aktuell kann man sich die Sources leider nur ansehen. Zudem sind die Projektdateien von Visual WebGui nicht mit meiner Visual Studio Web Edition kompatibel. Schade drum, werde ich im Auge behalten.

Erste Analyse wir sieht so ein Programm aus?
Sehr ähnlich den Windows Forms. Man erzeugt einfach ein Projekt vom Typ Visual WebGui Application und fügt die passenden Assemblies hinzu. Schon startet eine leere Form im Browser. Zum Test mal die üblichen Verdächtigen der Gizmox Version der Controls in die Form gezogen und ein wenig getestet.

Interner Web-Server des Visual Studio 2010 versus IIS
Erst mal Ernüchterung, im IE 9 / 10 wird nur eine leere Seite angezeigt. Komisch die Demo Seite vom Visual WebGui läuft doch. Also erst mal der Versuch das ganz im IIS zu Hosten. Klippen des wgx Handlers Typ umschifft und siehe da die Seite kommt aus dem IIS. Mr. Chrome zeigt jetzt schon mal recht gut eine Form an. Im IE nach wie vor eine leere Seite. Mit den Entwicklertools Umschaltung im IE 8 Modus und siehe da, die Form ist ebenfalls im IE vorhanden. Also die Web-Config um einen Eintrag erweitert:


	<WebGUI>
		<ApplicationsMetaData>
			<!-- needed ! because works not right on ie 9 or 10... -->
			<meta http-equiv="X-UA-Compatible" content="IE=8" />
		</ApplicationsMetaData>
		...
	</WebGUI>

Nach dieser Erweiterung startet die Anwendung dann im IE 8 Modus und läuft.

Bug oder Feature MainMenu?
Eine meiner Hauptkomponenten ist das MainMenu. Also mal sehen wie das Ding funktioniert. Siehe da es verhält sich sehr komisch. Fährt man mit der Maus über ein Menuitem wird dieses wie erwarten farblich hervorgehoben, leider bleibt diese Hervorhebung im IE bis zum jüngsten Tag bestehen. Wieder komisch, im Demo Projekt von Visual WebGui funktioniert es. Der Fehler ist weg, sobald das Projekt im IIS gehostet wird. Gut damit kann man leben.

Erstes Resümee,
eine feine Sache, mit der man sich näher beschäftigen sollte. Vor allem sehr schnell, mit ASPX .net Web-Projekten nicht zu vergleichen. Scheint erst mal erheblich besser.

Browser Kompatibilität,
zumindest was die drei großen IE, Chrome und FireFox unter Windows angeht, sieht das mal sehr gut aus. Meine Android Geräte sollten zwar ebenfalls mit den Seiten umgehen können, allerdings klappt das nur Bedingt. Immerhin funktioniert zumindest eine der Android Versionen halbwegs. Ganz so einfach scheint es dann doch wohl nicht mit der völlig Browser unabhängigen Entwicklung. Mal sehen wir der Auftraggeber diese Einschränkungen seine Wunschsystems sieht. Es sieht ebenfalls in jedem Browser etwas anders aus, aber ich denke mit diesen optischen Unterschieden kann man leben. Dafür setzt man halt ein Framework ein, auf das man nur bedingten Einfluss hat. Bin gespannt was die iPad anstellen, Safari hat auch so seine Tücken. In erster Linie will der Endkunde die App neu aufsetzen um sie besser im iPad nutzen zu können.

Grafiken,
ein wenig ein Krampf. So einfach wie in Windows Forms stellt sich das ganze leider nicht dar. Man muss über sogenannte Gateways an diese Stelle agieren. Gibt ein paar Beispiele in Netz, aus denen ich mir eine Lösung zusammenstellen konnte. Ich muss in dieser Anwendung auf einen großen dynamischen Cache von Pixel Dokumenten zugreifen, daher kann ich nicht einfach wie von Visual WebGui Standard gemäß vorgesehen, meine Grafiken statisch einbinden. Auf jeden Fall ist die Laufzeit recht gut daher kein Killer Kriterium zur Umsetzung der Anwendung.

So weiter, lernen wie man mit Visual WebGui arbeitet.