Google Maps über COM (Component Object Model)

[DelphiFan2008]

Hi Thom,

Zitat:

Deshalb kann ich Dir nur empfehlen, ein eigenes TDirektionsRenderer-Objekt zu programmieren. Alles was dazu notwendig ist (TMarker, TPolyline, TDirectionsResult), ist vorhanden.

Für die Umsetzung eines eigenes TDirektionsRenderer-Objekt sehe ich keinen Ansatz. Verwendung TMarker, TPolyline o.k., habe ich in vielfältiger Weise in meiner App. Die Verknüpfung mit TDirectionsResult stellt mich vor ein Rätsel. Kannst du in kurzen Worten deine Idee zum "Ansatz" erklären?

Meinst du BikeRouteToaster oder GPSies macht dies in ähnlicher Weise, siehe JPG? Bin leider nicht in der Lage über den Browser/Quelltext den JavaScript Code zu verstehen :cry:

Gruß DelphiFan2008

[hewy]

Hallo

{Nachtrag: Alles klar konnte es selbst lösen. in dem ich den GeoCoder in ruhe lasse. Danke }

Das Framwork liegt schon länger auf meiner ToDo Liste, nun ist es endlich soweit.
Hab eine kleine Applikation erstellt in welche ich Lat/Long eingeben und mir dann einen Marker an die Eingegebene Position setzt.
Nun scheint es so dass eine Optimierung vorgenommen wird bevor der Marker an die Position gelangt.
Daher meine Frage: wie setze ich einen Marker an genau die Koordinaten welche eingegeben werden?

Die folgenden Koordinaten hatte ich zum Testen verwendet: Diese sollte nach meiner Auffassung eine geradelinie ergeben.
Dem ist aber nicht so.

47.47356 8.4646488
47.47686 8.4679488
47.48021 8.4712988
47.48361 8.4746988
47.48706 8.4781488
47.49056 8.4816488
47.49411 8.4851988
47.49771 8.4887988
47.50136 8.4924488
47.50506 8.4961488
47.50881 8.4998988
47.51261 8.5036988
47.51646 8.5075488
47.52036 8.5114488
47.52431 8.5153988
47.52831 8.5193988

Besten Dank und Gruss
Heinrich^

[Thom]

@DelphiFan2008:

Entschuldige bitte die späte Antwort.
Ja - es sieht wirklich so aus, als ob die beiden von Dir genannten Beispiele die Route mit eigenen Mitteln anzeigen und nicht das DirectionsRenderer-Objekt aus dem API benutzen. Will man etwas mehr Einflußmöglichkeiten (wie zum Beispiel Kontextmenüs oder Ereignishandler für die einzelnen Wegpunkte), ist das DirectionsRenderer-Objekt leider völlig ungeeignet, da es nach dem Black-Box-Prinzip so gut wie alle Funktionen kapselt und nur sehr geringe Einflußmöglichkeiten durch den Programmierer zuläßt.

Momentan habe ich leider keine Zeit, ein alternatives Objekt zu entwickeln, da ich mit Hochdruck an der Fertigstellung der Version 3 des Frameworks arbeite. Das ist aber auf der ToDo-Liste vermerkt.


@Heinrich:

Die Marker befinden sich doch auf einer Linie!? :gruebel:
Anhang 36850
Falls das bei Dir nicht der Fall sein sollte, wäre es schön, wenn Du mal den Quelltext und/oder einen Screenshot zeigen würdest.

Edit: Alles klar - ich hatte Deinen Nachtrag zu spät gelesen...

[alibaba]

Hallo.

Erst mal großes Lob und Danke für das Framework,
beschäftige mich erst ein paar Tage damit aber läuft toll !

Habe hier Delphi 6 auf XP mit IE 8, wobei aber anscheinend der IE8 die
Krücke ist, delphichromiumembedded läuft auch mit Delphi 6 wie ne 1.

Hat jemand einen Tip für mich wie ich das Framework mit delphichromiumembedded zum laufen
bekommen könnte der Geschwindigkeitsunterschied würde mich interessieren ?

lg
Albert

[Thom]

Hallo Albert,

vielen Dank für das Lob!

Inwiefern gibt es Probleme mit dem Internet Explorer ActiveX?
Auf meinem Entwicklungsrechner arbeite ich ohne Probleme mit XP und dem IE8. Auch auf einem Netbook läuft Google Maps mit akzeptabler Geschwindigkeit. Allerdings habe ich auch feststellen müssen, daß mit jeder neuen Version das API etwas zäher wird - das liegt einfach auch am ständig zunehmenden Funktionsumfang. Außerdem sitzen die Jungs/Mädchen von Google wahrscheinlich an schnelleren Kisten... Und JavaScript bleibt nun mal JavaScript.

Um auf Deine Frage zu antworten: Das Framework arbeitet ausschließlich mit dem IE. Sollen andere Browser unterstützt werden, ist der Zugriff über COM nicht geeignet und Du müßtest andere Komponenten benutzen. Die wichtigsten mir bekannten sind im ersten Beitrag aufgelistet. TECMap unterstützt Chromium Embedded. Auf Anfrage schickt Dir der Entwickler auch gern eine Demo-Komponente zu. Damit könntest Du dann einen Vergleich zwischen den Browsern machen.

Möchtest Du einen Geschwindigkeitsvergleich beim IE zwischen der von allen Komponentenentwicklern genutzen Exec-Methode zur Ausführung von JavaScript und dem direkten Zugriff über COM, so ist die von diesem Framework verwendete Methode etwa doppelt so schnell. Das liegt daran, daß das Parsen und Ausführen des JavaScript-Codes entfällt.

[fduenas]

Thomas:
Are planning some day to port your component to be uses to intraweb or annother web solution for delphi?

[Thom]

Hi fduenas!

IntraWeb: Probably not. The documentation of IntraWeb is unfortunately very bad. And buy source code for the development of a freeware component is currently too expensive to me.

Other web solutions: At which do you think?

Currently I am working on version 3 of the framework. Then I will proceed with the development of a solution without Internet Explorer or another browser components. So may be a cross-platform application would be possible.

[gregshrek]

Zitat:

Zitat von Thom (Beitrag 1084599)

Nach den positiven Worten über den OpenLayers-Player hatte ich ihn mir in den letzten Tagen angeschaut und mir einen ersten Überblick verschafft:

...

Da der Quelltext des Beispiels momentan nicht compilierbar ist (ich habe einige Erweiterungen an den Units des Frameworks vorgenommen), hänge ich einfach die fertige Demo an.

Hallo Thom

Ich bin sehr an dem Quellcode interessiert. Würdest du ihn mir zur Verfügung stellen?


Gruss Greg

[Thom]

Hallo Greg,

vielen Dank für Dein Interesse und das Lob!

Bitte entschuldige, daß ich Dich so lange habe warten lassen. Das liegt daran, daß ich momenentan mehr Arbeit habe, als Zeit zur Verfügung steht. Dadurch sind leider etliche Anfragen länger liegen geblieben, als es höflich ist.

Zu Deiner Frage: Selbstverständlich kannst Du den Quelltext zur Ansteuerung des OpenLayer-Players haben. Allerdings muß ich Dich vorwarnen: Die Umsetzung ist absolut unvollständig und paßt wahrscheinlich nicht mehr zur aktuellen Frameworkversion.

Das Framework selbst ist in zwei Teile gegliedert:

Der erste Teil - der Kern - besteht aus einer DelphiToJavaScript-Bridge (D2JS-Engine), die ausschließlich über COM-Interfaces mit der JScript-Engine des IE-ActiveX kommuniziert. Damit kann auf beliebige JavaScript-Funktionen und -Objekte zugegriffen werden. Das geschieht in Form von Wrapper-Objekten, die über vorhandene JavaScript-Objekte gelegt werden oder die selbst neue JavaScript-Objekte erstellen.

Darauf baut der zweite Teil des Frameworks auf, der damit alle Objekte und Methoden des Google Maps API's zugänglich macht.

Genauso kann man das natürlich mit allen anderen JavaScript-Frameworks machen - es ist nur eine Frage des Aufwandes, den man treiben möchte. Darauf basieren dann auch die Anfänge der Umsetzung des OpenLayer-Players. Ich hatte das allerdings nur zum Testen geschrieben und hatte nicht geplant, es in dieser Form weiterzuentwickeln. Insofern ist es nur eine Studie nach dem Motto "So könnte man das auch machen...".

Zu den Gründen, weshalb ich den OpenLayers-Player nicht auf die Art in Delphi einbinden möchte:
JavaScript in Verbindung mit einem Browser(-Plugin) kommt von der Geschwindigkeit her nicht annähernd an ein kompiliertes Programm heran. Tests haben gezeigt, daß ein in Delphi geschriebener Player zur Darstellung von Kartendaten ohne Probleme um den Faktor 10 schneller ist, als eine Kombination aus Browser und JavaScript. Selbst auf einem gemächlichen Netbook sind ruckelfreie Animationen (wie das Verschieben der Karte oder die Veränderung des Zoomfaktors) möglich.
Deshalb investiere ich lieber die Zeit in einen nativen Delphi-Player. Für das Datenmaterial des Open StreetMap-Projektes ist das möglich - Google besteht in seinen Lizenzbedingungen (momentan) aber leider auf den ausschließlichen Zugriff über das JavaScript-API.

Du kannst den Ansatz des OpenLayers-Players aber gern weiterentwickeln. Um das Ganze dann auch mit der D2JS-Engine der neuen Version des Frameworks kompatibel zu machen, sind allerdings einige Anpassungen notwendig, da die Version 3.0 auch Delphi-seitig Interfaces unterstützen wird. Bei Fragen würde ich Dir selbstverständlich helfen.

Den Quelltext der Demo mit dem OpenLayers-Player schicke ich Dir per Email.

Viele Grüße
Thomas

[Borni]

Erstmal eine RIESENLOB, feine Arbeit, das gehört belohnt *Spende ist unterwegs*

und gleich die erste Frage:

Wie kann man auf einen Link im InfoFenster eines Markers, intern vom Programm reagieren, habe (noch) nichts gefunden.

Gruß Borni

[Thom]

Hallo Borni,

vielen Dank für das Lob und die Spende!
Die aktuelle Frameworkversion und die Bonus-Units sind per Email zu Dir unterwegs.

Zu Deiner Frage:
Links können über das OnBeforeNavigate2-Ereignis der Browser-Komponente überwacht werden. Das funktioniert auch mit Links innerhalb des Info-Fensters. Legst Du den Inhalt des Info-Fensters selbst fest, lassen sich über das Framework sogar anonyme und Objekt-Methoden direkt aufrufen. Meinst Du so etwas?

Viele Grüße
Thomas

[Borni]

JO, genau so, klappt es auch.... super

Gruß Borni

[Borni]

@Thom: Gibt es eine Möglichkeit eine grosse Anzahl von Markern(Koordinaten sind bekannt) als Liste zu Google zu senden ( ca. 2500-5000 Stk), um auf noch mehr Geschwindigkeit zu kommen ?


Gruß Borni

[Thom]

Du könntest die MarkerClusterer-Bibliothek aus den Zusatz-Units nehmen oder einen KML-Layer verwenden. MarkerClusterer kann intern eine große Anzahl von Markern verwalten und ein KML-Layer wird von Google gerendert - die Marker sind dann alle sichtbar, aber nicht mehr einzeln ansprechbar. Dazu bräuchtest Du einen Server, von dem Google die KML-Datei abholen kann. Mit einer lokalen Datei funktioniert das aber auch, wenn man zum Beispiel in das Programm zusätzlich einen HTTP-Server mit den Indy-Komponenten einbaut.

[korffi]

Also in der autocomplete demo stürzt bei mir nix ab (win7x64,ie9,Dxe2 recompiled) egal was ich ins edit feld eintrag es sei denn ich tippe ein "t"

und zwar nur beim kleinen t da möchte er die map reloaden

kann mir einer sagen was da das problem ist ? (gibt leider kein onkeydown event was ich abfangen könnte um zu sehen was für ne taste ankommt im feld


thx im vorraus

korffi

[Thom]

Vielen Dank für den Hinweis!

Schön, daß bei Dir die Demo funktioniert.

Das Problem mit dem "t" habe ich gerade untersucht. Dummerweise entspricht der Code beim Loslassen der Taste T genau dem beim Betätigen der Taste F5. Deshalb muß eine Unterscheidung zwischen KeyDown und KeyUp in der Unit BrowserTools hinzugefügt werden:

Delphi-Quellcode:

unit BrowserTools;

uses
  ..., Messages;

function TDocHostUIHandler.TranslateAccelerator(const lpMsg: PMSG; 
  const pguidCmdGroup: PGUID; const nCmdID: DWORD): HResult;
begin
  Result:=S_FALSE;
  if Assigned(FOnTranslateAccelerator) and Assigned(lpMsg) and
     (lpMsg.Message=WM_KEYDOWN) and FOnTranslateAccelerator(Self,lpMsg.wParam)
    then Result:=S_OK;
end;

[korffi]

hehe das ja mal doof das des mit dem t der gleiche code ist aber
habs so umgebaut und funktioniert

nu bekomm ich immer nen scripterror den ich mit ja weiterklicken kann (ausm browser selbst )

http://maps.gstatic.com/cat_js/intl/...n,places%7D.js object erwartet

aber das wird wohl eher was vom ie sein oder bei google ;)

gruß

Korffi

[Thom]

Ja - das ist ein Scriptfehler. Das könnte am JavaScript API (Du verwendest die 3.9.11) liegen und/oder am verwendeten Browser. Bei mir (Windows XP 32 Bit, IE 8, Delphi XE) tritt dieser Fehler nicht auf.
Du könntest versuchen, eine ältere API-Version zu laden und zu testen, ob dieser Fehler dort auch auftritt

Delphi-Quellcode:

LoadAPIAsync(InitMap,'','',3.8,false,[libPlaces]);

oder schlicht und einfach die JavaScript-Fehlermeldungen des Browsers unterdrücken

Delphi-Quellcode:

WebBrowser1.Silent:=true;

und schauen, ob das Edit-Feld trotzdem seine Arbeit verrichtet.

[korffi]

funktioniert beides (also apiversion oder unterdrücken)

thx

korffi

[Thom]

Prima. :thumb:

[Borni]

Unterschied XP zu Win7

unter Windows7 klappt die Zuweisung eigener Images wunderbar
- icAdresse := New(Script.Google.Maps.MarkerImage(Encode64(TPNGOb ject(Image5.Picture.Graphic))));

unter XP wird das Symbol nicht angezeigt !!!!Hat da Encode64 ein Problem ?

Idee ???

Gruß Borni

[Thom]

Die Funktion Encode64 ist betriebssystemunabhängig.
Poste bitte Dein Projekt, bei dem die Darstellung der PNG-Bilder nicht funktioniert, als Anhang, damit ich das Problem untersuchen kann. Alle Beispiele, die ich bisher veröffentlicht habe und die, die dem Framework beiliegen, sind garantiert "XP-getestet".

[Borni]

das ganze Projekt wird schwierig......

Delphi-Quellcode:

...
 icKunde := New(Script.Google.Maps.MarkerImage(Encode64(TPNGObject(Image1.Picture.Graphic))));
 icLieferant := New(Script.Google.Maps.MarkerImage(Encode64(TPNGObject(Image2.Picture.Graphic))));
 icAdresse := New(Script.Google.Maps.MarkerImage(Encode64(TPNGObject(Image5.Picture.Graphic))));
...


procedure TDialogGeoCache.AddMarker(Map: TMap; fGeoPosition: TLatLng; fd: TData;
  Typ, funr: string);
var
  MarkerOptions: TMarkerOptions;

begin
  if fd.Name1 = '' then exit;
  MarkerOptions := TMarkerOptions.Create;
  try
    MarkerOptions.Map := Map;
    MarkerOptions.Position := fGEoPosition;
    if Typ = 'K' then // Image definieren
      MarkerOptions.IconImage := icKunde
    else
      if Typ = 'L' then
        MarkerOptions.IconImage := icLieferant
      else
        MarkerOptions.IconImage := icAdresse;

    MarkerOptions.Title := fd.Name1; // Hint für die Marke

    with New(Script.Google.Maps.Marker(MarkerOptions)) do begin
      OwnsData := false;
      Data := fd;
      Properties['unr'] := funr;
      OnClick := MarkerClick;
    end;

    fd.Markergesetzt := true;
  finally
    MarkerOptions.Free;
  end;

end;

wie gesagt unter Win7 kein Problem und XP sind die DAten zwar da, aber die Symbole sind nicht zu sehen (XP IE8)

Gruß Borni

[Thom]

Eine kleine Bitte: Setze den Quelltext in die Delphi-Tags (der Helm oben im Editor) - dann läßt er sich wesentlich besser lesen.
Ich teste Dein Beispiel einmal - dauert eine kleine Weile. Ich melde mich dann wieder.

OK. Fertig.
Ich konnte keinen Fehler in Deinem Quelltext feststellen. Das Problem muß also an anderer Stelle liegen.
Ich habe eine kleines Testprojekt angehangen, das Images über Encode64 ähnlich Deines Quelltextes verwendet. Das funktioniert bei mir (Windows XP, IE8, Delphi XE) ohne Probleme. Es wäre schön, wenn Du das mal auf Deinem System testen könntest und mir mitteilst, ob die Marker angezeigt werden oder nicht.

Noch ein kleiner Hinweis bezüglich der Verwendung der Data-Eigenschaft des Marker-Objektes: Dieses Property wird in Version 3 des Frameworks nicht mehr allgemein zur Verfügung stehen.

[Borni]

so, da ich unter D2007 das Projekt noch compilieren muss, ist die Original pngimage 1.564 aus D2009 installiert.
Die Images sind sauber unter Windows7 32/64, XP SP3 IE8 (frisch installiert) zusehen. Soweit so gut....aber
2,3 andere Rechner mit XP zeigen nichts an !!!

Hast du noch eine Idee ?

Gruß Borni

[Thom]

• Werden die Bilder aus meiner Demo auch nicht angezeigt?
• Ich habe SP3 installiert - ist das auch bei den betroffenen Rechnern bei Dir der Fall?
• Haben die von Dir verwendeten PNG's eventuell ein besonderes Format (Farbtiefe, Palettenfarben o.ä.) oder sind sie sehr groß (Base64-codierte Bilder dürfen eine gewisse Größe nicht überschreiten)?
• Du könntest zu Testzwecken auch einmal ein JPG-Bild verwenden um zu überprüfen, ob Marker Icons prizipiell nicht angezeigt werden, wenn sie mit Base64 codiert wurden oder nur PNG's.
• Als nächstes könntest Du versuchen, die betroffenen Marker-Bilder nicht Base64 zu codieren, sondern von einem eigenen Server oder der lokalen Festplatte laden zu lassen.

[Borni]

Zitat:

Zitat von Thom (Beitrag 1175884)

• Haben die von Dir verwendeten PNG's eventuell ein besonderes Format (Farbtiefe, Palettenfarben o.ä.) oder sind sie sehr groß ....

Daran hat es gelegen, unter XP gingen 3,62KB für ein png nicht durch (Photoshop). Mit einem anderen Programm bearbeitet =734 Bytes und siehe da, es funzt auch mit XP.

Danke nochmals für den Tipp, habe mich den ganzen Tag zu Tode gesucht....

Gruß Borni

[Thom]

Super!

[rzzanatta]

Hallo, ich heruntergeladen habe die Demo und nicht kompilieren, dieser Fehler [DCC Fatal Error] Unit1.pas(9): F1026 File not found: 'BrowserTools.dcu' was mache ich jetzt?

Ich benutze Delphi 2010

Zitat:

Zitat von Thom (Beitrag 1070741)

Die Demos 1 bis 4 im Quelltext (ohne exe). Sie wurden sowohl mit Delphi 5, Delphi 2005 PE, Delphi 2010 als auch mit Delphi XE getestet.

Achtung:
Zur Compilierung sind die Units in den Unterverzeichnissen API und JScript notwendig, die bei mir separat angefordert werden können!

Neue Version der Wrapper-Objekte: Jetzt ist nicht mehr TWebBrowser zur Darstellung der Karten notwendig - es wird auch TEmbeddedWB unterstützt. Genauer gesagt: Es können alle IE-ActiveX-Komponenten genutzt werden, die auf TOleControl basieren!
Das ist vor allem bei Delphi-Versionen hilfreich, die standardmäßig keine installierte TWebBrowser-Komponente in der Palette haben - das hatte ich gestern voller Entsetzen beim Test mit Delphi 2005 PE feststellen müssen. :shock:

[Thom]

Hallo Rodrigo,

die Unterverzeichnisse API und JScript sind jetzt im Framework enthalten (GoogleMaps\Source\API und GoogleMaps\Source\JScript). Sie müssen nur in den Suchpfad der IDE oder des Projektes aufgenommen werden.

[Gruber_Hans_12345]

Hi

Wollte es auch gerade ausprobieren, alles runtergeladen, suchpfade und co
aber beim compilieren bringt er mir einen fehler

Code:

DCC Fehler BrowserTools.pas(266): E2250 Es gibt keine überladene Version von 'Encode64', die man mit diesen Argumenten aufrufen kann

Delphi-Quellcode:

function Encode64(Data: TStream; MediaType: String): String;
var
  Stream: TStringStream;
begin
  Result:='';
  if not assigned(Data)
    then Exit;
  Stream:=TStringStream.Create('data:'+MediaType+';base64,');
  try
    Stream.Seek(0,soFromEnd);
    Encode64(Data,Stream); <<< Hier 
    Stream.Seek(0,soFromBeginning);
    Result:=Stream.DataString;
  finally
    Stream.Free;
  end;
end;

[Thom]

Doch:
Diese Funktion mit zwei Streams als Parameter gibt es. Sie befindet sich in der Unit Base64 (

Delphi-Quellcode:

function Encode64(Src, Dest: TStream): Boolean; overload;

). Diese Unit wird auch von der Unit BrowserTools, aus der die von Dir zitierte Funktion

Delphi-Quellcode:

function Encode64(Data: TStream; MediaType: String): String;

stammt, über die uses-Anweisung eingebunden.

Du könntest testhalber einmal versuchen, den Aufruf explizit zu formulieren:

Delphi-Quellcode:

Base64.Encode64(Data,Stream);

[Gruber_Hans_12345]

ah, habe es gefunden, ich habe ein anderes Base64 das auch im suchpfad ist, und das nimmt er als erstes her ...

eine andere Frage
was bedeuten all diese New `?

Delphi-Quellcode:

New(Google.Maps.Marker(MarkerOptions));

Die tuen gar nichts eigetnlich, sind die für zukünftige Sachen da, oder braucht es die für etwas?

[Thom]

Ja, Du hast vollkommen Recht:
Momentan hat die New-Funktion keinerlei Bedeutung - sie gibt lediglich den Eingangsparameter als Resultat zurück. Sie dient hier nur dazu, den Quelltext etwas leserlicher zu gestalten, indem darauf hingewiesen wird, daß ein neues Objekt angelegt wird/wurde. So erstellt die Funktion

Delphi-Quellcode:

Google.Maps.LatLng(...)

ein neues TLatLng-Objekt, was aber nicht sofort offensichtlich ist.
Insofern kann die New-Funktion momentan auch ohne Bedenken weggelassen werden.

Das wird sich aber in der kommenden Version grundlegend ändern: Dann wird das Objekt wirklich erst von der New-Funktion erstellt, die dann etwa wie der New-Operator in JavaScript arbeitet.
So liefert - um bei dem Beispiel zu bleiben -

Delphi-Quellcode:

Google.Maps.LatLng

nur die Klasse und New() erstellt eine Instanz. Das Ganze dient - wie schon erwähnt - der Lesbarkeit des Quelltextes.
Auch Hilfsobjekte werden dann über die New-Funktion erstellt, so daß der Delphi-typische Syntax

Delphi-Quellcode:

TObject.Create

bei der Verwendung des Frameworks überflüssig wird:

Delphi-Quellcode:

procedure TForm1.FormShow(Sender: TObject);
begin
  with Script(WebBrowser1) do
    if not APILoaded
      then LoadAPIAsync(InitMap);
end;

procedure TForm1.InitMap(Sender: IObject);
var
  MapOptions: IMapOptions;
begin
  with Sender as IScript do
  begin
    MapOptions:=New(Google.Maps.MapOptions);
    with MapOptions do
    begin
      Zoom:=8;
      Center:=New(Google.Maps.LatLng(-34.397,150.644));
      MapTypeID:=Google.Maps.MapTypeID.Roadmap;
    end;
    New(Google.Maps.Map(MapOptions));
  end;
end;

Zu beachten ist hier, daß die Objekte nur noch über Interfaces angesprochen werden, was der besseren Speicherverwaltung dient.

[Gruber_Hans_12345]

Hallo

Gibt es eine möglichkeit alle Marker zu lsöchen
und / oder einen spezifischen

Ich finde irgendwie noch nicht das richtige ;)

[Thom]

Jedes Objekt auf der Karte wird in einer entsprechenden Liste des Script-Objektes gespeichert und verwaltet.

Delphi-Quellcode:

with Script do
  while Markers.Count>0 do
  begin
    Markers[0].SetMap(TMap(nil));
    Markers.Delete(0);
  end;

Für neuere Delphi-Versionen wird auch der for-in-Syntax unterstützt:

Delphi-Quellcode:

with Script do
begin
  for Marker in Markers do
    Marker.SetMap(TMap(nil));
  Markers.Clear;
end;

In Zukunft wird der Aufruf von

Delphi-Quellcode:

Script.Markers.Clear;

ausreichen. Momentan werden dabei die Marker aber nicht von der Karte entfernt. Deshalb der explizite Aufruf von

Delphi-Quellcode:

SetMap(...)

;

[Gruber_Hans_12345]

Danke hat funktioniert :)

[jonathan]

hallo,

gibt es eine möglichkeit, das erstellen vieler Custom-Marker mit OnClick-Event zu beschleunigen?

beispiel:

Code:

MarkerArray:=TMarkerArray.Create;
for n:=1 to 3000 do begin
   newMarkerPos:=New(Script.Google.Maps.LatLng(... , ...));
   MarkerOptions:=TMarkerOptions.Create;
   with MarkerOptions do begin
      Position:=newMarkerPos;
   end;
   Marker:=New(Script.Google.Maps.Marker(MarkerOptions));
   MarkerArray.Push(Marker);
end;
MarkerClusterer.AddMarkers(MarkerArray,true);
MarkerClusterer.Repaint;

das läuft wunderbar (<1s)


packe ich in die MarkerOptions noch mehr rein:

Code:

      Title:=...;
      zIndex:=...;
      IconImage:=...;
      ShadowImage:=...;
      Shape:=...;

dauert es schon knapp 10s


natürlich würde ich aber auch gerne was mit den Markern machen...
setze ich

Code:

Marker.OnClick:=MarkerClick;

dauert das ganze dann allerdings schlappe 5min !!!
was natürlich nicht mehr bedienbar ist...

irgendwelche tipps oder ideen?
oder mache ich was grundlegendes falsch?
1000 dank!

[Thom]

Ja, was soll ich sagen: JavaScript bleibt nun mal JavaScript - und darauf muß das Framework leider aufbauen (Lizenzbestimmungen von Google).

Ich habe Deine Aussagen untersucht und mußte feststellen, daß die Zuweisung von Ereignishandlern tatsächliche überproportional viel Zeit kostet. Ein kleiner Patch in der Unit JScriptObjects sollte etwas Entspannung bringen:

Delphi-Quellcode:

procedure TCustomScript.MakeFunctionNameUnique(var FunctionName: String);
var
  s: String;
  GUID: TGUID;
begin
  if Assigned(FExternalMethods) then
  begin
    if FExternalMethods.IndexOf(FunctionName)>=0 then
    begin
      CreateGuid(GUID);
      s:=GUIDToString(GUID);
      s:=StringReplace(s,'{','',[rfReplaceAll]);
      s:=StringReplace(s,'}','',[rfReplaceAll]);
      s:=StringReplace(s,'-','',[rfReplaceAll]);
      FunctionName:=FunctionName+s;
      if AnsiChar(FunctionName[1]) in ['0'..'9']
        then FunctionName:='_'+FunctionName;
    end;
  end;
end;

Das Ganze ist zwar kein Wundermittel - brachte aber auf meinem Rechner reichlich 50% Zeitersparnis bei 1000 Markern.

Um für die Marker nicht die ganze Oberfläche zu blockieren, könntest Du deren Erstellung auch in das OnIdle-Ereignis der Anwendung auslagern oder zwischendurch Application.ProcessMessages aufrufen. Die Auslagerung in einen Thread geht leider nicht, da Microsoft's JavaScript-Engine nicht threadsicher ist.

Es wäre schön, wenn Du den Patch testen und mir mitteilen könntest, wie viel er gebracht hat. Wenn ich wieder etwas mehr Zeit habe, werde ich das Ganze noch einmal intensiver untersuchen und finde vielleicht noch die eine oder andere Optimierungsmöglichkeit.

[jonathan]

vielen dank, der patch funktioniert soweit - das ganze ist jetzt DEUTLICH schneller.
der schlimmste "zeitfresser" scheint wohl mit der GUID-methode behoben zu sein...
wobei ein wenig weitere optimierung natürlich nie schaden kann ;-)

falls du den patch in deine "offiziellen sourcen" übernehmen möchtest, müsstest
du beachten, dass CreateGUID unter Delphi 5 noch CoCreateGUID heisst und in der
unit ActiceX deklariert ist...