More information about this annotation.
The rapid debugger is made of two components: debugger engine and device shell app. The code is executed by the debugger engine (which runs on the desktop). The debugger engine sends commands to the shell app. The result is the same as running the code directly on the device.
To avoid network latency the debugger engine doesn't wait for the result of each method. It sends a large chunk of commands and only when it must it waits for a result.
If however an event is raised directly from a call to another method then the debugger engine must wait for the result or else the buffers state will be broken.
For example, consider this code:
'Class module
Sub Class_Globals
End Sub
'Initializes the object. You can add parameters to this method if needed.
Sub Initialize
End Sub
Sub SubThatCanRaiseEvent (target As Object, i As Int)
If i = 3 Then
CallSub(target, "test")
End If
End Sub
CallSub method is marked with @RaisesSynchronousEvents so the engine knows that it can raise an event and it will be ready for it.
If however you compile this code into a library and run it, you will get an error message saying:
Unexpected event (missing RaiseSynchronousEvents): test
The program will then crash.
The engine doesn't know that the method
SubThatCanRaiseEvent can raise an event so when the event is raised it corrupts the buffers.
The solution for Java libraries is to add the @RaisesSynchronousEvents annotation on those methods.
For B4A compiled libraries you should use the new RaisesSynchronousEvents attribute:
'Class module
#RaisesSynchronousEvents: SubThatCanRaiseEvent
Sub Class_Globals
End Sub
'Initializes the object. You can add parameters to this method if needed.
Sub Initialize
End Sub
Sub SubThatCanRaiseEvent (target As Object, i As Int)
If i = 3 Then
CallSub(target, "test")
End If
End Sub
Note that you can add this attribute multiple times, for each of the relevant subs.