Manchmal muss man einen Schritt zurück gehen, um weiteren Fortschritt zu machen. Was das für die beiden Projekten Better Access Charts und Better Access PivotTable bedeutet, zeigt dieser Beitrag.
Gehen wir zurück an den Anfang meiner Bemühungen. Begonnen hat alles mit einer statischen Html-Datei. Diese habe ich im Webbrowser-Steuerelement zur Anzeige gebracht. Fertig war das erste Diagramm mit Chart.js. Im weiteren Verlauf des Projektes habe ich dann immer mehr Einstellungen verfügbar gemacht. So kamen unter anderem eine Datenbindung, der Titel oder die Achsen hinzu. Alle diese Einstellungen schlugen sich am Ende immer in der generierten Html-Datei nieder. Basis war also immer die Html-Datei.
Damit Java Script im Webbrowser Steuerelement ausgeführt wurde, nahm ich anfangs in der Registry Einträge für die Feature Browser Emulation vor. Später kam die Erkenntnis, dass dieser Eingriff in die Registry nicht notwendig ist, wenn in der Html-Datei die Direktive "meta http-equiv='X-UA-Compatible' content='IE=Edge'" vorhanden ist.
Im Oktober diesen Jahres durfte ich mein Projekt im Rahmen der Access Entwickler Konferenz einem größeren Publikum vorstellen. Im Laufe der Gespräche bei der AEK wurden viele Gedanken zu weiteren Ausbaumöglichkeiten an mich herangetragen. Einige Teilnehmer fragten auch, ob es nicht möglich wäre, auf die HTML-Datei zu verzichten und den generierten HTML-Code direkt im Webbrowser-Steuerelement zur Anzeige zu bringen.
Dieser Gedanke trieb mich die nächsten Tage an. Schnell hatte ich eine Lösung gefunden. Anstatt den Html-String in eine Datei zu speichern, nutze ich die Methode Write des im Webbrowser angezeigten Html-Dokuments. Alles funktionierte bestens. Gleichzeitig hatte ich sich auch noch das Problem mit der Anzeige von Umlauten gelöst. Aus meiner Sicht lief alles perfekt. So war es auch keine Frage, dieses Vorgehen beim Projekt Better Access PivotTable eins zu eins zu übernehmen.
Irgendwann später tauchte bei mir auf dem Rechner dann eine Fehlermeldung auf, wenn ich einen Chart erzeugen wollte. Ich nahm diesen Fehler nicht ernst und führte ihn auf die Konstellation auf meinem Rechner zurück. Bei mir sind Office 365 und Office 2010 parallel installiert. Da ich für ein Kundenprojekt nochmal mit Access 2010 arbeiten mußte nahm ich an, dass hier irgendwelche Einträge in der Registry verbogen wären. Ich heilte das Problem, in dem ich in der Registry die Einträge für die Feature Browser Emulation vornahm. Für mich war das Problem damit erledigt.
Wie sich jetzt herausstellte war dies ein Irrtum. Bereits Anfang November meldete sich ein Benutzer bei mir. Er hatte das selbe Problem. Auch ihn verwies ich auf den Registry-Eintrag für die Feature Browser Emulation. Im Dezember war ich dann mit dem Zug unterwegs. Während der Fahrt wollte ich auf meinem Laptop weiter an Better Access PivotTable arbeiten. Hier tauchte das selbe Problem auf. Dabei wurde mir dann klar, dass die Ursache an anderer Stelle zu suchen ist.
Meine Recherchen führten mich zu der Erkenntnis, dass die Direktive "meta http-equiv='X-UA-Compatible' content='IE=Edge'" nur funktioniert, wenn der Html-String aus einer Datei geladen wird. Wenn ich den Html-String mit der Write-Methode zur Anzeige bringe, zeigt er keine Wirkung. Hier hilft dann nur noch der Eintrag in der Registry.
Den Eintrag in der Registry kann ich mit Better Access Charts oder Better Access PivotTable nicht vornehmen. Es bleibt also nur der Weg über die Direktive im Html-Code. Diese funktioniert wiederum nur, wenn das Html-Statement aus einer Datei geladen wird.
Diese Erkenntnisse bringen mich dazu, beide Projekte anzupassen. Künftig wird das Html-Statement wieder in einer Datei gespeichert und von dort in das Webbrowser-Steuerelement geladen.
Die Anpassungen werden ich in den nächsten Tagen auf GitHub veröffentlichen.
Keine Kommentare:
Kommentar veröffentlichen