Hallo HJay,
vielen Dank für Dein Interesse und das Lob!
Leider begreife ich das Konzept dahinter noch nicht ganz. Vielleicht hast Du Zeit und Lust, ein paar Grundlagen zu erklären?
Kein Problem. Lust: Immer - Zeit: Leider viel zu wenig.
Mein Unverständnis fängt schon an beim FormShow der Demo-Routinen. Basierend auf der Demo "Overlay / Marker Simple":
Code:
procedure TForm1.FormShow(Sender: TObject);
begin
if Script=nil then with TScript.Create(WebBrowser1) do LoadAPIAsync(InitMap);
end;
Wieso gibt die Funktion Script hier nil zurück, so dass der WebBrowser1 korrekt zugeordnet wird? Die Funktion scheint doch ein TCustomScript-Objekt zu erzeugen und zurückzugeben?
Die Funktion
Script gibt es in mehreren überladenen Varianten. Die ursprüngliche Version liefert tatsächlich ein
TCustomScript-Objekt. Die Variante in der
Unit gmApi gibt jedoch ein
TScript-Objekt zurück.
TScript ist von
TCustomScript abgeleitet und beinhaltet die Verwaltung aller Objekte, die mit dem Google Maps
API zusammenhängen - also aller Karten, Marker, Overlays usw..
Die Funktion
Script kann mit oder ohne Parameter aufgerufen werden, wobei als Parameter
TOleControl akzeptiert wird, um neben
TWebBrowser auch
TEmbeddedWB zu unterstützen. Wird die Funktion ohne Parameter (oder mit
nil) aufgerufen, so liefert sie immer das zuletzt erstelle Script-Objekt zurück. Wird also nur mit einem IE-
ActiveX gearbeitet, reicht es aus,
Script ohne Parameter aufzurufen. Anders sieht es dagegen aus, wenn mit mehreren IE-Komponenten gearbeitet wird: Dann
muß der Browser als Parameter übergeben werden:
Delphi-Quellcode:
if Script(WebBrowser1)=nil then
TScript.Create(WebBrowser1)...;
if Script(WebBrowser2)=nil then
TScript.Create(WebBrowser2)...;
Pro Browser-Komponente darf immer nur ein Script-Objekt erstellt werden - alles andere wird mit bösen Laufzeitfehlern quittiert. Das hat mit den verwendeten Interfaces zu tun.
Alle erstellten Script-Objekte werden frameworkintern verwaltet - sie brauchen nicht freigegeben zu werden. Sie dienen intern dem Zugriff auf die JavaScript-Engine des Browsers.
In der Version 3 des Frameworks entfällt die manuelle Erstellung des Script-Objektes: Hier liefert die Funktion
Script(WebBrowser) immer ein güliges Script-Interface.
Ich verstehe auch nicht, was beim Aufruf "LoadAPIAsync(InitMap)" der Prozedur InitMap als Sender übergeben wird, so dass die Anweisung "with TScript(Sender)" mit Sinn erfüllt wird. Sehr kryptisch für mich.
Das Google Maps
API arbeitet an den meisten Stellen asynchron. Das bedeutet, daß nach erfolgter Ausführung einer Aufgabe - die meistens eine Kommunikation mit den Servern von Google beinhaltet - eine Callback-Methode aufgerufen wird.
Die asynchrone Arbeitsweise beginnt schon beim Laden des eigentlichen
API's. Erst danach kann eine Karte erstellt und angezeigt werden. Deshalb wurde in der Version 2 des Frameworks die Möglichkeit geschaffen, die Initialisierungsroutine an die Ladefunktion zu übergeben. Das funktioniert übrigens sowohl mit Objekt- als auch mit anonymen Methoden.
Der zweite Grund, weshalb der Initialisierungscode in eine separate Methode ausgegliedert werden sollte, liegt in der Behandlung der Refresh-Funktion. Hat die Browser-Komponente den Fokus, bewirkt die Betätigung der Taste F5 das Neuladen des Browserinhaltes. In der ersten Version des Frameworks hatte das noch das unschöne Ergebnis, ein leeres Fenster zu erhalten, falls der Programmierer vergessen hatte, diese Tastenbetätigung abzufangen. Das ist allerdings nicht ganz so einfach und deshalb wurde die Behandlung des Refreshvorganges komplett im Framework integriert. Das Neuladen des Browserfensters kann ganz unterbunden werden, manuell oder automatisch erfolgen. Standardmäßig wird ein Dialog angezeigt und nach erfolgreicher Bestätigung alle bisher erstellten Objekte gelöscht, das
API neu geladen und die beim erstmaligen Ladevorgang angegebene Initialisierungsmethode aufgerufen. Die Initialisierungsmethode wird also nicht als
Sender übergeben, sondern als
InitMapProc.
Beim Aufruf der Methode
InitMapProc übergibt das Script eine Referenz auf sich selbst. Dadurch ist es möglich, die selbe Initialisierungsmethode für mehrere Browser-Komponenten zu nutzen. Wichtig ist hier nämlich, daß alle
API-Objekte im richtigen Script-Kontext erstellt werden. So kann zum Beispiel ein Marker, der im Browser1 erstellt wurde, nicht im Browser2 genutzt werden. Werden allerdings zwei Karten im selben Browser-Fenster erstellt, ist der Austausch ohne Probleme möglich.
So weit ich weiß, ist übrigens diese Framework die einzige Delphi-Lösung, die es gestattet, mehrere Karten oder eine Karte mit danebenliegendem Streetview-Panorama innerhalb eines IE-Controls unterzubringen.
In der kommenden Version 3 des Frameworks werden übrigens alle Objekte auf Interfaces umgestellt. Deshalb sollte man schon jetzt auf die Typumwandlung
TScript(Sender) verzichten und besser
Sender as TScript verwenden - dann ist die Anpassung auf Interfaces schneller erledigt (
Sender as IScript) und führt zu keinen Laufzeitfehlern.
In den Demo-Routinen werden die mit New() erzeugten Objekte MyMap oder Marker nur lokal verwendet und nicht freigegeben. Muss man auch zusätzlich erzeugte TMarker-Objekte nicht freigeben? Kümmert sich darum wirklich das Framework vollautomatisch?
Ja: Alle erzeugten Objekte werden intern verwaltet.
Bei den Framework-Objekten handelt es sich immer um Wrapper, die den direkten Zugriff auf das zugehörige JavaScript-Objekt gestatten.
Das Delphi-Wrapper-Objekt kann dabei auf zwei Arten arbeiten: Es kann einerseits als reiner Adapter über ein schon vorhandenes JavaScript-Objekt gelegt werden - dann kann das Delphi-Objekt freigegeben werden, ohne daß das Einfluß auf die Lebensdauer des zugehörigen JavaScript-Objektes hat. Andererseite kann das Delphi-Objekt das entsprechende JavaScript-Objekt erstellen und steuert dessen Existenzdauer. Wird in diesem Fall das Delphi-Objekt freigegeben, geschieht das auch mit dem JavaScript-Objekt.
Um bei dem Marker-Beispiel zu bleiben: Hier wird ein neues JavaScript-Marker-Objekt erstellt und demzufolge auch wieder gelöscht, wenn das Delphi-Marker-Objekt freigegeben wird.
Dieses Verhalten ist in Version 2 zwar noch nicht vollständig implementiert - man sollte es aber jetzt schon beachten, denn das war auch einer der Hauptgründe für die Umstellung auf Interfaces in der Version 3 mit einem wesentlich besseren Speichermanagement.
Lange Rede - kurzer Sinn: Nein - das erstellte Marker-Objekt muß (darf) nicht freigegeben werden. Es befindet sich nach seiner Erstellung in der
Script-internen Liste
Markers.
Anders verhält es sich momentan mit den Options-Objekten - zum Beispiel
TMarkerOptions. Diese können/sollten freigegeben werden - müssen aber nicht. Können/sollten deshalb, weil sie zwar bei Beendigung des Programmes automatisch abgeräumt werden, bis dahin aber unnötig Speicher belegen. Bei drei Markern spielt das keine Rolle - bei 30000 aber schon.
Wenn es nicht unbedingt notwendig ist, würde ich aber trotzdem darauf verzichten, da durch die kommenden Interfaces das Problem automatisch gelöst wird.
Dem Speichermanagement und der besseren Lesbarkeit des Quelltextes dient ebenfalls die
New-Funktion. Sie wurde in der Version 2 eingeführt und soll verdeutlichen, daß an dieser Stelle ein neues Objekt erstellt wird. Momentan ist die Verwendung diese Funktion optional und hat keinerlei Auswirkungen (es wird lediglich das Argument zurückgegeben). In der Version 3 ist sie allerdings verbindlich und sollte auch bei allen Options-Objekten Anwendung finden.
Wäre die folgende Routine so korrekt in Deinem Sinne programmiert, um einen weiteren Marker einzufügen:
Code:
TForm1= ...
private
MyMap : TMap;
Marker2 : TMarker;
procedure TForm1.Button1Click(Sender: TObject);
var MarkerOptions: TMarkerOptions;
begin
with Script do begin
MarkerOptions := TMarkerOptions.Create;
with MarkerOptions do begin
Position:=New(Google.Maps.LatLng(-25.363882,131.044922));
Map:=MyMap;
end;
Marker2 := New(Google.Maps.Marker(MarkerOptions));
end;
end;
Ja - das sollte so funktionieren.
MyMap und
Marker2 braucht Du aber nicht unbedingt im Form-Objekt zu speichern. Mit
Script(WebBrowser1).Maps[0] hast Du Zugriff auf die (erste) Karte und mit
Script(WebBrowser1).Markers[1] auf den zweiten Marker.
Muss ich auch Marker2 nicht selbst freigeben?
Kannst Du, wenn Du ihn nicht mehr benötigst. Hier solltest Du aber momentan vorher noch
Marker.SetMap(TMap(nil)) aufrufen, um ihn von der Karte zu entfernen. Das wird in der Version 3 ebenfalls automatisch erfolgen.
Wie würde ich die FormShow-Routine erweitern müssen, um ZWEI separate TWebBrowser-Objekte gleichzeitig verwenden zu können? Geht das überhaupt?
Ja. Siehe oben.
Ich hoffe, mein Vortrag war einigermaßen verständlich. Wenn Du noch weitere Fragen hast oder neue aufgetaucht sind, kannst Du sie gern stellen.