Leaderboard

It appears you have already asked a similar question, here: https://stackoverflow.com/questions/65345853/is-it-possible-to-write-the-following-java-program-in-delphi The principal for your present issue is identical, i.e. if OnPrintListener is a class, then you. cannot do it in Delphi. If it's an interface (which, given your other question, it's likely), then you already have an example of how to implement a Java interface, in the StackOverflow answer. A possible example for this case: uses Androidapi.JNIBridge, Androidapi.JNI.JavaTypes, Androidapi.Helpers; type JOnPrintListener = interface; JOnPrintListenerClass = interface(IJavaClass) ['{076904DD-77D9-497D-BA21-992A9B8FED3E}'] end; [JavaSignature('com.nexgo.oaf.apiv3.device.printer.OnPrintListener')] JOnPrintListener = interface(IJavaInstance) ['{F688775D-067F-4521-A045-9106599F4C4A}'] procedure onPrintResult(retCode: Integer); cdecl; // *** NOTE *** There may be other methods for this interface end; TJOnPrintListener = class(TJavaGenericImport<JOnPrintListenerClass, JOnPrintListener>) end; TRunnable = class(TJavaLocal, JRunnable) private FCallback: TProc; public { JRunnable } procedure run; cdecl; public constructor Create(const ACallback: TProc); end; TPrintListener = class(TJavaLocal, JOnPrintListener) private FRetCode: Integer; FRunnable: JRunnable; procedure DoRun; public { JOnPrintListener } procedure onPrintResult(retCode: Integer); cdecl; public constructor Create; end; { TRunnable } constructor TRunnable.Create(const ACallback: TProc); begin inherited Create; FCallback := ACallback; end; procedure TRunnable.run; begin FCallback; end; { TPrintListener } constructor TPrintListener.Create; begin inherited; FRunnable := TRunnable.Create(DoRun); end; procedure TPrintListener.DoRun; begin // Do the toast thing here, using FRetCode end; procedure TPrintListener.onPrintResult(retCode: Integer); begin FRetCode := retCode; TAndroidHelper.Activity.runOnUiThread(FRunnable); end; { TForm1 } procedure TForm1.Button1Click(Sender: TObject); begin // Assuming FPrintListener is defined as: FPrintListener: JOnPrintListener FPrintListener := TPrintListener.Create; // Assuming you have created an instance of Printer (imported as JPrinter) called FPrinter FPrinter.startPrint(False, FPrintListener); end; Note all of the assumptions being made - the biggest one being that OnPrintListener is an interface. Also I don't have the .jar, nor the printer, so of course it is untested

MMX forms are not HDPI conform, they are only ok if you are using the IDE in "blurry" mode.

Not sure about waht you need to do, TL;DR; but why not exchange TThread.Synchronize(TThread.Current, to TThread.Queue(TThread.Current, For a simple notification in the UI, like a Label text, that should be good enough, and decouples much better.

So you should be able to make a reproducible test case - in case there is none already. I did report this with a reproducible test case, but they knew about it long before then. https://quality.embarcadero.com/browse/RSP-32666

Accessing a string one char beyond the length of the string is fine because Delphi string contains an implicit zero terminating zero. Doing the same on an empty string once worked the same but now causes an AV because the string is nil. I don't know when this changed but it was before 10.3 var Foo: string; begin Foo := 'Hello World'; ShowMessage(IntToStr(Ord( Foo[Length(Foo)+1] ))); // No problem Foo := ''; ShowMessage(IntToStr(Ord( Foo[Length(Foo)+1] ))); // Access Violation end; My guess is the code predates Delphi 2009 since it uses WideString to support unicode.

The code is something of a disaster zone. That leak looks dire. If the component contains this, then who knows what else is there! As for the two minute fix, I gave that above. Replace temp[1] with Pointer(temp)^. But we're still making assumptions because we can't see the exception details.

Talking frankly, this code is piece of garbage, the fact it worked before is just a big luck. You address 1-th char of an empty string and expect it to pass.

What kind of issues did you have? BPLs for different version need to be in different directories if they do not have any kind of naming convention for Delphi IDE version. Some components will complain they cannot be found unless the folder they are in is on the path. Instead of adding to either your system path or user path; try modifying the path variable in the IDEs environment variables so that its isolated to that version of the IDE - this has worked for me in the past.