Wish Difference in Map debug representation between B4A and B4J

[agraham]

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]

Are you using the deprecated legacy debugger?

It should show the same in B4A and B4J.

 

[agraham]

Are you using the deprecated legacy debugger?

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]

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.

one doesn't work with events in some of my apps

There is a solution for this.

However I am a bit surprised that both debuggers don't use the same UI.

It is not a matter of UI. It is a matter of the way the data is being sent.

 

[agraham]

There is a solution for this.

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.

It is a matter of the way the data is being sent.

OK, I can see that.

 

[Erel]

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.

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]

1. Best way is to switch to RaiseEventFromUI when possible.

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.

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.

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.