You need to add a variable x to your doBackgroundWork procedure.
2 Likes
just adding it will make it work ? i will try and see
And yes it worked thanks for the help mate 
1 Like
I want to be sure I have the latest itoo version...
I downloaded it from the link at the end of this initial itoo post and installed it...I expected the info to show "Sky 4.4.1"
The file size on windows is 93,033 bytes.
Is this the latest version? (4.4.1?)
Kind regards,
Randal
Yes, it is the latest version (built on march 2nd). I have likely forget to bump the extension version.
Thanks,
-Randal
1 Like
[Note I edited this post to change the logcat excerpts and made other minor changes/corrections. @Randal_Andress ]
I am getting a java Uncaught exception that I cannot track down which seems to be from a call to Itoo.FetchProperty.
9004 9004 E Form : Uncaught Exception
9004 9004 E Form : java.lang.RuntimeException: Error receiving broadcast Intent { act=UI_ITOO_X_RECEIVER flg=0x10 pkg=appinventor.ai_randal_andress.DelayDio3_v0_4_badURLcase (has extras) } in xyz.kumaraswamy.itoox.UIProcedureInvocation$1@91afb98
9004 9004 E Form : Caused by: java.lang.RuntimeException: com.google.appinventor.components.runtime.errors.YailRuntimeError: The operation FetchProperty cannot accept the arguments: , [xyz.kumaraswamy.itoo.Itoo@3d8310b]
It would seem that FetchProperty is being called with bad/null arguments:
" , [xyz.kumaraswamy.itoo.Itoo@935a46]" but I cannot see where this is happening in my code 
Before I go any further, I want to apologize for the size of this case. If you have any problem spotting the problem, I will try to give you something smaller. I plan to be working on that while you are looking at it.
I have modified the app mostly by making some components invisible and by adding a toggle button which switches at runtime between a state which causes the error and another which does not cause the error (by not making the call to ui_DumpItooProperties)
The error occurs when procedure ui_DumpItooProperties is called from Screen1_ErrorOccurred.
The Screen1 error is caused intentionally by attempting to set a player source to an invalid URL. This is an error from which the app needs to be able to recover - and which it does as long as ui_DumpItooProperties is not called from the Screen1 error handler in the itoo service (background).
This recovery can be demonstrated by default in the test case by clicking
"Select a Station"
Then by selecting "WTWX ..."
After a few seconds the error is caught and presents two notification boxes to be dismissed.
To illicit the error, tap the button
"Dump=No"
which will then change to
"Dump=Yes"
and repeat: Select a Station, WTWX.
This time control is not returned to the user until a timeout generates a notice/choice to wait or terminate the app.
The "DumpItooProperties" button may be clicked at any time before selecting a bad URL, and if "Dump=Yes", it will display each itoo property=value in the space at the bottom of the screen.
I am attaching excerpts from the logcat output for each case. The "-1" named files contain only selected lines from the larger contiguous files.
the "Dump=No" case:
delaydio-badurlcase-nodump-1.txt (474 Bytes)
delaydio-badurlcase-nodump.txt (939.4 KB)
and the "Dump=Yes" case:
delaydio-badurlcase-dump-1.txt (2.6 KB)
delaydio-badurlcase-dump.txt (938.3 KB)
I believe the blocks file is too large (~5 Mbyte) to upload.
Here is the .aia
DelayDio3_v0_4_badURLcase.aia (199.5 KB)
Again, I plan to work on a smaller reproducer, but it may take a bit...
Thanks,
Randal
Hi Randal, there is a fundamental mistake that happens while calling the ui_DumpItooProperties from the Itoo Service.
I need to first explain you how the call is redirected from the Itoo thread to the application's UI thread.
Itoo looks for calls on the procedure names starting with ui_. If it intercepts such a call, it will begin JSON serialization process of the arguments provided. We use App Inventor's own JSON serialization methods that are fine tuned for App Inventor data types.
It is important to note that, during this step, a runtime object (like the ItooPlayerService) cannot be serialized for transportation. Instead what the Application UI thread receives is a string of the component (package_name.Itoo@xyzdata).
Think of it as attempting to store an App Inventor component in a TinyDB. It does store, but it's not the component. It's a value of the .String() method called on the component.
Hmmm... I do not think I understand: Does this mean that this serialization failure occurs on any ui_xxxxx procedure call from the Itoo service? surely not, because that is what the ui_ magic is for, correct? 
Or is there something about the ui_DumpItooProperties procedure itself OR the call site from within the Screen1_ErrorOccurred hander that causes this to happen?
Is this something that is likely to be changed/fixed?
Could I work around this by using a ItooPlayerService.Broadcast message from the Screen1_ErrorOccurred procedure that is picked up by the ItooPlayerService.BroadcastEvent which would then call ui_DumpItooProperties? Or would that cause a similar problem?
-Randal
Hi Randal, this is a technological limitation and cannot be fixed.
The problem is that you are trying to pass a component to a procedure starting with ui_xxx. That call is not a normal one, only the standard App Inventor data types are allowed.
Ahhh... Now I understand! It is the second argument/parameter to ui_DumpItooProperties that is the problem!
In my case then, since there is no need for the argument - there is only one itoo component - I only need to eliminate the parameter and simply "hard code" ItooPlayerService into the ui_DumpItooProperties procedure, correct?
-Randal
1 Like
Well... that was only part of the problem. I was also attempting to pass a label component, which (of course) failed for the same reason. Once I got that corrected it works just fine. Thanks for the help!
BTW, I did not find a way to remove an argument from a procedure without causing all its calls to have arguments removed throughout the app. Since there were several argments and several call sites, I just renamed the arguments and ignored them.
Any advice as to how to easily remove arguments from a procedure so as to cause minimum disruption at the call sites?
-Randal
1 Like
I asked this question on the general discussion forum:
Evidently there is not presently a better way...
I went ahead and submitted a feature request
-Randal
1 Like
MelonNotification • Various styled notifications + Itoo