agraham Expert Licensed User Longtime User Jun 12, 2021 #1 I've just noticed that when examining a Map in B4J it is represented as an openable item with the entries on separate lines like Visual Studio. B4A shows it as a single line of comma separated items. I don't know what B4i does. I much prefer the B4J presentation and would suggest the B4A adopts it. EDIT: Ditto for Lists and any other multi-item object.
I've just noticed that when examining a Map in B4J it is represented as an openable item with the entries on separate lines like Visual Studio. B4A shows it as a single line of comma separated items. I don't know what B4i does. I much prefer the B4J presentation and would suggest the B4A adopts it. EDIT: Ditto for Lists and any other multi-item object.
Erel B4X founder Staff member Licensed User Longtime User Jun 13, 2021 #2 Are you using the deprecated legacy debugger? It should show the same in B4A and B4J.
agraham Expert Licensed User Longtime User Jun 13, 2021 #3 Erel said: Are you using the deprecated legacy debugger? Click to expand... Ah! That's it. I don't normally use a debugger at all but when I do I always (irrationally) use the legacy debugger in B4A because I trust that more than the new-fangled one, and the new one doesn't work with events in some of my apps. However I am a bit surprised that both debuggers don't use the same UI.
Erel said: Are you using the deprecated legacy debugger? Click to expand... Ah! That's it. I don't normally use a debugger at all but when I do I always (irrationally) use the legacy debugger in B4A because I trust that more than the new-fangled one, and the new one doesn't work with events in some of my apps. However I am a bit surprised that both debuggers don't use the same UI.
Erel B4X founder Staff member Licensed User Longtime User Jun 13, 2021 #4 The rapid debugger has came a very long way since its early versions. The legacy debugger is not maintained for many years now and is likely to fail with resumable subs. agraham said: one doesn't work with events in some of my apps Click to expand... There is a solution for this. agraham said: However I am a bit surprised that both debuggers don't use the same UI. Click to expand... It is not a matter of UI. It is a matter of the way the data is being sent.
The rapid debugger has came a very long way since its early versions. The legacy debugger is not maintained for many years now and is likely to fail with resumable subs. agraham said: one doesn't work with events in some of my apps Click to expand... There is a solution for this. agraham said: However I am a bit surprised that both debuggers don't use the same UI. Click to expand... It is not a matter of UI. It is a matter of the way the data is being sent.
agraham Expert Licensed User Longtime User Jun 13, 2021 #5 Erel said: There is a solution for this. Click to expand... If that is the @RaisesSynchronousEvents annotation then it doesn't always work as that needs the method to be public and listed in the XML. Erel said: It is a matter of the way the data is being sent. Click to expand... OK, I can see that.
Erel said: There is a solution for this. Click to expand... If that is the @RaisesSynchronousEvents annotation then it doesn't always work as that needs the method to be public and listed in the XML. Erel said: It is a matter of the way the data is being sent. Click to expand... OK, I can see that.
Erel B4X founder Staff member Licensed User Longtime User Jun 13, 2021 #6 1. Best way is to switch to RaiseEventFromUI when possible. 2. The internal methods do not matter. What matters is that when the B4A code calls a method that can eventually lead to a synchronous event, that method should be marked with the above annotation. Code: Copy SomeLibrary.SomeMethod 'if a synchronous event can be raised as a result of this call then the debugger needs to stop pushing instructions to the pipeline. MoreCodeHere
1. Best way is to switch to RaiseEventFromUI when possible. 2. The internal methods do not matter. What matters is that when the B4A code calls a method that can eventually lead to a synchronous event, that method should be marked with the above annotation. Code: Copy SomeLibrary.SomeMethod 'if a synchronous event can be raised as a result of this call then the debugger needs to stop pushing instructions to the pipeline. MoreCodeHere
agraham Expert Licensed User Longtime User Jun 13, 2021 #7 Erel said: 1. Best way is to switch to RaiseEventFromUI when possible. Click to expand... I can't always. For example the extensions to my BasicLib interpreter rely heavily on RaiseEvent to call back into B4A code and the performance hit of going through the message loop is too much - the calls need to run synchronously. Erel said: 2. The internal methods do not matter. What matters is that when the B4A code calls a method that can eventually lead to a synchronous event, that method should be marked with the above annotation. Click to expand... That public method would be BasicLib.Run that starts the interpreter. Perhaps I'll try that sometime when I recompile the library to see if it works . I didn't think it would work but perhaps it will.
Erel said: 1. Best way is to switch to RaiseEventFromUI when possible. Click to expand... I can't always. For example the extensions to my BasicLib interpreter rely heavily on RaiseEvent to call back into B4A code and the performance hit of going through the message loop is too much - the calls need to run synchronously. Erel said: 2. The internal methods do not matter. What matters is that when the B4A code calls a method that can eventually lead to a synchronous event, that method should be marked with the above annotation. Click to expand... That public method would be BasicLib.Run that starts the interpreter. Perhaps I'll try that sometime when I recompile the library to see if it works . I didn't think it would work but perhaps it will.
