 |
 |
 |
 |
 |
|
Antwort
|
|
Registriert seit: 19. Mai 2006
 Use Google Maps API inside your Delphi application. Free, easy to use and much more powerful than a component. Der Kern besteht aus einer Delphi-To-JavaScript-Bridge, mit deren Hilfe Delphi-Programme über das COM-Interface des Internet Explorers auf JavaScript-Objekte und -Funktionen zugreifen können. Die Kommunikation ist dabei bidirektional: Das bedeutet, daß Objekt- und anonyme Methoden aus JavaScript heraus aufgerufen werden können - zum Beispiel als Callback-Funktion, Event-Handler oder "injizierter" Code. In diesem Framework wurde mit Hilfe dieser Delphi-To-JavaScript-Bridge das komplette Google Maps API abgebildet. Damit ist es möglich, alle Funktionen und Objekte dieses API's anzusprechen, ohne eine einzige Zeile JavaScript schreiben zu müssen. Nun gibt es schon eine Reihe von Lösungsvorschlägen und Komponenten für Delphi, die das Google Maps API kapseln (ohne Anspruch auf Vollständigkeit):
Weshalb dann noch dieses Framework? Ganz klar zwei Gründe:
Mit diesem Framework können JavaScript-Beispiele ohne Probleme nach Delphi umgesetzt werden - mit den Vorteilen einer Code-Vervollständigung und komfortablen Debugging-Möglichkeiten. Ein kleines Beispiel:
Code:
[...]
<script type="text/javascript"> function CreateMap() { var Options = {zoom: 13, center: new google.maps.LatLng(47.651743,-122.349243), mapTypeId: google.maps.MapTypeId.SATELLITE}; new google.maps.Map(document.getElementById("div_map"),Options); }; </script> </head> <body onload="CreateMap()"> [...]
Delphi-Quellcode:
In der aktuellen Version 2.0 besteht das Framework aus rund 30000 Quelltextzeilen, 10000 Zeilen Dokumentation im XML-Format und rund 10000 Zeilen in reichlich 80 Demos.
procedure TForm1.FormShow(Sender: TObject);
begin if Script=nil then with TScript.Create(WebBrowser1) do LoadAPIAsync(InitMap); end; procedure TForm1.InitMap(Sender: TObject); var Options: TMapOptions; begin with TScript(Sender) do begin Options:=TMapOptions.Create; with Options do begin Zoom:=13; Center:=New(Google.Maps.LatLng(47.651743,-122.349243)); MapTypeID:=Google.Maps.MapTypeID.Satellite; end; New(Google.Maps.Map(Options)); end; end; Systemvoraussetzungen
Das Framework wurde bisher mit folgenden Delphi-Versionen getestet:
Bekannte Probleme In Zusammenhang mit dem Internet Explorer 6 (sollte eigentlich keiner mehr benutzen):
Installation, Migration bestehender Projekte Da es sich um ein Framework handelt, muß nichts in der IDE installiert werden - es müssen lediglich die Pfade zur gmConfig.inc sowie den Verzeichnissen API und JScript eingetragen werden (global oder in den Projekt-Optionen). Die Umstellung von bestehenden Projekten unter Verwendung der Versionen 1.x auf die Version 2.0 sollte sich in der Regel auf die Anpassung der Unit-Namen beschränken. Um eine bessere Übereinstimmung zur Google Maps API-Dokumentation zu erzielen, wurden einige Units umbenannt. Auf die Einführung eines Namespace wurde mit Rücksicht auf ältere Delphi-Versionen (noch) verzichtet. Es wird empfohlen, die Initialisierung der Karte in eine separaten Methode auszulagern, um den Refresh-Mechanismus (Taste F5) des Frameworks nutzen zu können. Lizenz (Möglichst) kurz und schmerzlos: Ich mag keine seitenlangen Texte, die meist nur verunsichern (siehe aktuelle Problematik mit einer speziellen Datenbank) und die sowieso kaum jemand liest. Noch weniger mag ich Quelltexte, die am Anfang einen Hinweis enthalten, der länger ist als der eigentliche Code. Auch bin ich aus dem Alter heraus, in dem ich nach jeweils drei Zeilen mein Copyright hinterlassen muß, als hätte ich die genialste Erfindung aller Zeiten gemacht und müßte wie ein Hund mein Revier markieren. Wer das nötig hat, soll das machen - ich jedenfalls nicht. Deshalb nur folgende Regeln:
Erweiterungen
Viel Spaß!  (1) Wer für die Starter Editionen (XE bzw. XE2) keine TWebBrowser-Komponente besitzt, kann diese  hier nachrüsten.(2) siehe Beitrag(3) Spenden über PayPal (Bitte Name und Email-Adresse angeben, damit ich die Bonus-Units versenden kann.)
Geändert von Thom (17. Sep 2013 um 13:03 Uhr) Grund: gmConfig.inc für Delphi XE5 |
|
Delphi XE3 Professional |
#291
24. Okt 2012, 22:47
Hallo Stefan,
vielen Dank für das Lob!  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.
Thomas Nitzschke
Geändert von Thom (24. Okt 2012 um 22:52 Uhr) |
Zitat
|
|
Delphi XE3 Professional |
#293
30. Okt 2012, 19:31
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?
Mein Unverständnis fängt schon an beim FormShow der Demo-Routinen. Basierend auf der Demo "Overlay / Marker Simple":
Code:
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?
procedure TForm1.FormShow(Sender: TObject);
begin if Script=nil then with TScript.Create(WebBrowser1) do LoadAPIAsync(InitMap); end; 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:
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.
if Script(WebBrowser1)=nil then
TScript.Create(WebBrowser1)...; if Script(WebBrowser2)=nil then TScript.Create(WebBrowser2)...; 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.
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?
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; 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?
Wie würde ich die FormShow-Routine erweitern müssen, um ZWEI separate TWebBrowser-Objekte gleichzeitig verwenden zu können? Geht das überhaupt?
Ich hoffe, mein Vortrag war einigermaßen verständlich. Wenn Du noch weitere Fragen hast oder neue aufgetaucht sind, kannst Du sie gern stellen.
Thomas Nitzschke
Geändert von Thom (30. Okt 2012 um 21:11 Uhr) |
|
Zitat
|
|
Delphi XE3 Professional |
#295
30. Okt 2012, 23:01
Oh - da legst Du den Finger auf eine offene Wunde...
 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.
Thomas Nitzschke
Geändert von Thom (30. Okt 2012 um 23:20 Uhr) |
|
Zitat
|
|
Delphi XE7 Enterprise |
#296
1. Nov 2012, 17:06
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.
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? |
|
Zitat
|
|
Delphi XE3 Professional |
#299
1. Nov 2012, 21:08
Danke, das hört man gern!
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:
, dann sollte es funktionieren.
procedure TForm1.FormCreate(Sender: TObject);
begin if Script=nil then with TScript.Create(WebBrowser1) do LoadAPI(InitMap); MakeMarker; end;
Thomas Nitzschke
|
|
Zitat
|
| Themen-Optionen | Thema durchsuchen |
| Ansicht | |
ForumregelnEs ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.
BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus. Trackbacks are an
Pingbacks are an
Refbacks are aus
|
|
| Erstellt von | For | Type | Datum |
| DELPHI | (google maps) | This thread | Refback | 11. Nov 2011 09:07 |
| Twebbrowser HTML tag to UniHTMLFrame1 - uniGUI Discussion Forums | This thread | Refback | 4. Nov 2011 06:52 |
| DoraDev1975: google maps | This thread | Refback | 23. Sep 2011 08:18 |
| delphi osm - Google Search | Post #0 | Refback | 19. Sep 2011 09:02 |
| DoraDev1975: ?ิ????? 2011 | This thread | Refback | 11. Sep 2011 16:39 |
| DoraDev1975 | This thread | Refback | 30. Aug 2011 10:13 |
| Untitled document | This thread | Refback | 25. Jun 2011 19:57 |
| Interact with Google Maps in a TWebBrowser from Delphi | Ramblings | This thread | Refback | 26. Jan 2011 05:12 |
| google maps mit delphi link - Google Search | This thread | Refback | 24. Jan 2011 14:24 |
| google maps mit delphi - Google Search | This thread | Refback | 24. Jan 2011 14:20 |
| Untitled document | This thread | Refback | 19. Jan 2011 21:49 |
Linear-Darstellung
