Zitat von
Simon1988:
Was aber hat es mit dem CallObjectMethodeA befehl oder dem CallObjectMethodeV Befehl auf sich. Welchen Unterschied hat dieser Befehl zum normalen CallObjectMethode?
Erstmal ein wenig zu der Frage. Die beiden anderen Methoden hatte ich nicht erwähnt, weil sie nicht wirklich gebraucht werden. Der Unterschied liegt eigentlich nur darin, wie du die Parameter übergibst.
Mit CallObjectMethode werden die Parameter einfach Kommagetrennt (wie bei einem lokalen Aufruf üblich) übergeben.
Eine CallObjectMethodeA würde hier ein Array erwarten, in dem alle Variablen stehen (so wie beim Format die Argumente übergeben werden)
Und CallObjectMethodeV erwartet die Parameter als va_list.
Du siehst letztlich ist es völlig äquivalent (ob intern nicht eh immer in die jeweils andere Form gewandelt wird, merkst du nicht einmal).
[ADD1]
Werde mich brav an die Forenregeln halten und ranhängen, solange hier keiner zwischendrin antwortet!
Zitat von
Simon1988:
Gut also zum Befehl ReleaseIntArrayElement.
Dieses Release heißt ja sowas wie freigabe. Was bedeutet das in Java ?
Ups, ganz übersehen. Also was das angeht, so bekommst du von Arrays einfach eine Kopie in dein natives Programm. Alle Änderungen, die du an dem Array vornimmst (es ist nur eine Kopie) sind nur solange gültig, bis du diese mittels Release freigibst. Möchtest du nur die gelesenen Werte darstellen oder nur noch lokal mit ihnen Arbeiten, hast du einfach den Vorteil, dass die (dann überflüssige) Kommunikation mit Java entfällt (was gut für die Performance ist).
Rufst du Release für dieses Array auf, so muss der Zustand des Arrays im Java-Programm nicht mehr konsistent mit dem in deinem nativen Teil übereinstimmen. Vielmehr würde es dazu kommen, dass die Änderungen nur noch lokal stattfinden und Java das "alte" Array wieder herstellt.
[/ADD1]
[ADD2]
Sorry, hab gerade noch ein paar Dinge nebenbei zu erledigen und gleichzeitig immer ein paar Minuten die ich eh warten muss, so dass ich hier etwas sprunghaft schreibe.
Deswegen kommen jetzt erstmal die Stellen, die ich sofort und/oder kurz beantworten kann.
Zitat von
Simon1988:
Achso ich hab noch den Befehl PopLocalFrame und PushLocalFrame gefunden. Vielleicht ist der ja des Rätsels lösung.
Na ja, korrekterweise muss ich wohl sagen, kommt auf das Rätsel an. Das was du damit machen möchtest ist nicht möglich. Ich gehe hier einfach mal davon aus, dass du das Frame hier als grafisches Element verstehst. Sicherlich hat die Methode ihre Rechtfertigung, aber mir fällt gerade kein (mir bekanntes) Problem dazu ein (wäre hier aber auch total
OT).
Ja, hier solltest du Frame wörtlich verstehen, es ist nur eine Rahmen. Genau genommen kannst du dir hier die Größe eines Rahmen, der x-Referenzen aufnimmt zusichern lassen. Mehr ist es nicht. Du kannst hier dann einfach bestimmen ob die Anzahl der Referenzen übergeben werden kann oder ob nicht genug Speicher zur Verfügung steht.
Es bezieht sich alles auf die LocalReferences (auch das wäre wohl wieder ein Thema für sich). Ja, die Referenzen müssen auch (geht ja aus dem Namen der Methode hervor) localReferences sein. Die bekommst du wenn du die JNI newObject Methode verwendest (wie auch immer die heißt, weißt schon was ich meine).
[/ADD2]
[ADD3]
Zitat von
Simon1988:
So ein großer Absatz und ein großer Sprung. Ich hab nun einiges an Informationen über die Klasse in Erfahrung gebracht. Also das mit der Bitmap variante ist möglich, hat aber den nachteil, dass ich den schon bestehenden Eventlistener in Delphi neu proggen muss. Mit diesem Eventlistener kann man zum Beispiel ein gebief mit der Maus markieren welches rangezoomt werden soll.
Ok, was das angeht, so sehe ich hier immer noch keine gute Alternative. Mir ist zumindest kein Weg bekannt, wie du direkt auf die Fenster eines Java-Programms zugreifen kannst. Zudem denke ich treffen hier dann wirklich verschiedene Welten aufeinander. Wie ein Fenster in Java gezeichnet wird, kann stark varrieren, der Unterschied zwischen Swing und AWT könnte hier schon zum Problem werden.
Ich denke der Weg bürgt dann doch einige (mögliche) Probleme in sich. Da ist es dann doch besser, wenn du einfach einen anderen Weg wählst.
Was die neuen Listener angeht, so hast du nicht unrecht. Ich denke man kann halt nicht mal eben ein Java Programm komplett in einer anderen Umgebung zum laufen bekommen. Dafür ist Java ja auch nie gedacht gewesen, deswegen muss ich hier sagen, dass JNI trotz allem schon bis zu diesem Punkt gezeigt hat, wie mächtig es trotz alledem ist!
Damit du wenig Inkonsistenz zwischen dem Java Programm und dem Delphi-Code hast, würde ich dir ein raten, dass du hier eine Art Adapter baust. Du zeigst einfach das gerendert Bild an (wie ist jetzt erstmal egal). Um an dieses Bild zu kommen gibt es halt eine Schnittstelle, die dir das aktuelle Bild (das sonst auf einem Panel dargestellt werden würde) liefert. Dieses kannst du dann in Delphi anzeigen. Hier gibt es dann für alle implementierten Ereignisse einen Beobachter, der jedes dieser Ereignisse einfach an das Java-Programm weiterreicht.
Also um es einfach zu sagen, um das Zoomen sollte sich dann weiterhin dass Java-Programm kümmern, nur der auslöser ist dann halt dein Delphi-Programm. Obwohl, hier kommt dann natürlich das Problem zu tragen, dass du einen Auswahlrahmen dann in Delphi zeichnen musst...
Na ja, versuch einfach sowenig wie möglich nach Delphi zu übernehmen und weiterhin Java die Arbeit machen zu lassen, dann sind Änderungen leichter möglich (ohne dass es zu Inkonsistenzen kommt).
Wie gesagt, es ist nur meine Meinung, dass das der beste Weg ist, vielleicht gibt es eine schöne Zusammenarbeit zwischen den beiden Welten.
[/ADD3]