Google Maps über COM (Component Object Model)

[Thom]

Hallo Stefan,

vielen Dank für das Lob! :-D

Du bringst es auf den Punkt: Egal wie gut eine Komponente programmiert wurde - sie kann den direkten Zugriff auf ein API niemals ersetzen.

Zu Deiner Frage:
Bei den vielen Punkten beziehungsweise Streckenabschnitten würde sich eventuell ein KML-Layer empfehlen.

[HJay]

Hallo Thom!


Ich habe ein paar Anfängerfragen zu dem genialen Framework. Leider begreife ich das Konzept dahinter noch nicht ganz. Vielleicht hast Du Zeit und Lust, ein paar Grundlagen zu erklären?

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?

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.

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?

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;

Muss ich auch Marker2 nicht selbst freigeben?

Wie würde ich die FormShow-Routine erweitern müssen, um ZWEI separate TWebBrowser-Objekte gleichzeitig verwenden zu können? Geht das überhaupt?

[Thom]

Hallo HJay,

vielen Dank für Dein Interesse und das Lob!

Zitat:

Zitat von HJay (Beitrag 1189110)

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.

Zitat:

Zitat von HJay (Beitrag 1189110)

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.

Zitat:

Zitat von HJay (Beitrag 1189110)

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.

Zitat:

Zitat von HJay (Beitrag 1189110)

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.

Zitat:

Zitat von HJay (Beitrag 1189110)

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.

Zitat:

Zitat von HJay (Beitrag 1189110)

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.

Zitat:

Zitat von HJay (Beitrag 1189110)

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.

[HJay]

Wow, vielen lieben Dank für die ausführliche und kompetente Erklärung. Ich habe soweit hoffentlich alles verstanden und werde mich jetzt erst einmal einarbeiten und viel ausprobieren -- ganz bestimmt kommen dann noch weitere Fragen auf...

Aber eine weitere Frage schon jetzt: Wie kommt man denn an die im ersten Beitrag angesprochene XML-Hilfe?

[Thom]

Oh - da legst Du den Finger auf eine offene Wunde... :roll:

Die XML-Hilfe spielte in letzter Zeit (leider) eine recht untergeordnete Rolle. Im Vordergrund standen die Umstellung auf Interfaces, die Integration aller Neuerungen des API's, die Überarbeitung der Demos, die Umstellung auf einen Namespace (Dateinamen mit Punkten) und der Aufbau einer Homepage.
Besitzer älterer Delphi-Versionen müssen keine Angst haben: Durch einen Trick konnte ich die Namespace-Dateien auch diesen Compilern schmackhaft machen.

Sehr viel Arbeit war die Einführung von Interfaces, da die Lebensdauer der dahinter steckenden Objekte wesentlich kürzer ist und sie sich damit nicht mehr zur Speicherung von zusätzlichen Daten - wie zum Beispiel Ereignishandlern oder den bei Delphi-Entwicklern beliebten Properties Tag und Data - eignen. Außerdem mußte eine Möglichkeit gefunden werden, referenzgezählte Objekte explizit und ohne Rücksicht auf noch vorhandene Referenzen freigeben zu können.

Dadurch ist der Quelltext auf fast das Doppelte gewachsen (ca. 60000 Zeilen) und es sind reichlich 10 Demos neu hinzugekommen, so daß es jetzt insgesamt über 100 Beispielprojekte gibt.

So vergeht die Zeit wie im Flug und ehe man sich versieht, hat die Umsetzung der Version 3 fast ein Jahr Arbeit gekostet.

Für die XML-Hilfe muß ich mir noch etwas einfallen lassen. Sie war/ist auf die IDE-Erweiterung Documentation Insight zugeschnitten. Leider funktionierte sie bei den letzten Tests gar nicht mehr - wahrscheinlich kommt der Parser bzw. die Auswertung des Parserergebnisses mit den vielen Compilerschaltern nicht mehr zurecht. Documentation Insight verhält sich deshalb etwas bockig und zeigt nur noch ein leeres Fenster an.
Abgesehen davon hätten die Besitzer älterer Delphi-Versionen sowieso nicht allzuviel davon.

Wenn die Version 3 fertig ist und der Beta Test erfolgreich absolviert wurde, werde ich mich eventuell mal an die Arbeit machen und auf der neuen Homepage eine Onlinehilfe gestalten.
Bis dahin habe ich eine gute Ausrede: Nutzt die Dokumentation des JavaScript API's von Google! Da das Framework weitestgehend eine 1:1 Umsetzung dieses API's ist, ist diese Dokumentation der beste Ratgeber. :thumb:

[HJay]

Zitat:

Zitat von Thom (Beitrag 1189137)

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.

Ein TMarkerOptions-Objekt sollte wann genau freigegeben werden? Kann es schon freigegeben werden, direkt nachdem es verwendet wurde (scheint auf den ersten Blick zu funktionieren)? Oder erst, sobald der zugehörige Marker nicht mehr gebraucht wird?

Code:

    MarkerOptions := TMarkerOptions.Create;
    with MarkerOptions do begin
      Position := MyLatLng;
      Map := MyMap;
      Title := 'Hello World!';
    end;
    New(Google.Maps.Marker(MarkerOptions));
    MarkerOptions.Free; // hier schon?

[Thom]

Die Optionsobjekte werden nur während der Erstellung des eigentlichen Objektes benötigt und können deshalb so freigegeben werden, wie von Dir beschrieben.

Die Optionsobjekte kann man als eine Liste mit Name-Wert-Paaren ohne Methoden betrachten.

[HJay]

Bisher klappt alles sehr gut -- echt ein ganz tolles Framework! An dieser Stelle nochmals vielen Dank!

Ein Problem habe ich derzeit aber leider:

Ich führe in FormCreate die Initialisierung aus. Wenn ich dann direkt in Anschluss ebenfalls in FormCreate() oder auch in FormShow() einen Marker erzeugen will, dann scheitert dies mit einer Zugriffsverletzung (auf 000000).

Habe ich exakt die gleiche Routine aber auf Button1Click(), dann funktioniert alles prächtig. Hast Du irgendeine Idee dazu, woran das liegen könnte? Muss man irgendwas abwarten? Gibt es dazu ein Event?

Code:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, OleCtrls, SHDocVw,

  gmAPI, gmMap, gmBase, gmOverlaysMarker;

type
  TForm1 = class(TForm)
    WebBrowser1: TWebBrowser;
    Button1: TButton;
    procedure FormCreate(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    procedure InitMap(Sender: TObject);
    procedure MakeMarker;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  MakeMarker;  // läuft ohne Probleme!
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  if Script=nil then with TScript.Create(WebBrowser1) do LoadAPIAsync(InitMap);
//  MakeMarker;  // stürzt ab!
end;

procedure TForm1.InitMap(Sender: TObject);
  var MyOptions : TMapOptions;
begin
  with Sender as TScript do begin
    MyOptions := TMapOptions.Create;
    with MyOptions do begin
      Zoom := 12;
      Center := New(Google.Maps.LatLng(51.250249, 9.835209));
      StreetViewControl := False;
      MapTypeID := Google.Maps.MapTypeID.Roadmap;
    end;
    New(Google.Maps.Map(MyOptions));
  end;
end;

procedure TForm1.MakeMarker;
  var MarkerOptions : TMarkerOptions;
begin
  with Script(WebBrowser1) do begin
    MarkerOptions := TMarkerOptions.Create;
    with MarkerOptions do begin
      Position := New(Google.Maps.LatLng(51.250249, 9.835209));
      Map      := Maps[0];
    end;
    New(Google.Maps.Marker(MarkerOptions));
    MarkerOptions.Free;
  end;
end;

end.

[Thom]

Danke, das hört man gern! :-D

Ja - das kann nicht funktionieren. Das API (genauer gesagt: die JavaScript-Bibliothek) muß erst von den Google-Servern geladen werden. Das dauert natürlich je nach Internetverbindung, Serverauslastung und Rechnergeschwindigkeit eine Weile.
Die Methode LoadAPIAsync() führt diesen Vorgang durch und ruft anschließend die Methode InitMapProc (die übergebene Callback-Methode) auf. Erst zu diesem Zeitpunkt wurde das API vollständig geladen und die (JavaScript-)Objekte Google und Maps angelegt. Vorher existieren sie nicht und der Zugriff darauf führt zu einer Zugriffsverletzung bzw. Exception.
Lädst Du das API asynchron, hat das den Vorteil, daß Deine Anwendung inzwischen weiter initialisiert und die Fenster angezeigt werden können.

Die zweite Möglichkeit besteht im blockierenden Laden des API's über die Methode LoadAPI() (also ohne Async). Diese Funktion kehrt erst nach der kompletten API-Initialisierung zurück und blockiert damit natürlich den Hauptthread. Das würde ich nicht empfehlen - deshalb wird in sämtlichen Demos die Methode LoadAPIAsync() verwendet.

Schreibst Du also

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  if Script=nil then with TScript.Create(WebBrowser1) do LoadAPI(InitMap);
  MakeMarker; 
end;

, dann sollte es funktionieren.

[jonathan]

Hi,
wie kann man die aktuelle GOOGLE Maps Kartenansicht ausdrucken?
Gibt es dafür eine Lösung direkt aus der API heraus?

Oder ist der Weg über die TWebPanel Komponente der geschicktere?
z.B. WebPanel.ControlInterface.ExecWB(OLECMDID_PRINT, OLECMDEXECOPT_PROMPTUSER, vIn, vOut) ...