Thank you for your reply. Actually I've used CallSubDelayed and, as you say, I use "wait for" and "sleep":
private Sub filldata
mqttmod.mqtt.Close
Do While mqttmod.mqtt.IsInitialized
Sleep(100)
Loop
mqttmod.initmqtt
wait for mqtt_connected
Sleep(10)
wait for (readregs(Array As String("W18", "Ua1", "Ua2"))) complete (res As Object)
gatelen = q90("Ua1") + 256*q90("Ua2")
...
wait for (readregs(Array As String("M220", "UU3", "W28"))) complete (res As Object)
...
wait for (readregs(Array As String("M220", "UU3", "W28"))) complete (res As Object)
Log("****************** Finished fill.")
updfinished = True ' global flag
End Sub
Sub Activity_Create(FirstTime As Boolean)
Activity.LoadLayout("ginfo")
updfinished = False ' global flag'
... ' rest of code without sleep or wait
CallSubDelayed(Me, "filldata")
End Sub
Sub Activity_Resume
mqttmod.infotimer.Initialize("infotimer", 1000)
mqttmod.infotimer.Enabled=True
End Sub
but, as seen in the log of previous post, Activity_Resume is called before Activity_Create is finished. As Erel says, this is expected and, for my limited knowledge, I even understand why: behind the scenes there is a routine that invokes Activity_Create and Activity_Resume one after the other. The flux of code cannot be stopped: as soon as a "sleep" or "wait for" is invoked, the stack of called routines is rolled up to the routine behind the scenes.
I must start a timer only after the various data has been prepared, the timer interferes with the loading of data. I could start it from the Filldata routine, where the order of execution is guaranteed, but that routine is called only when the activity is created, not after a pause/resume sequence. Moreover, Activity_Resume is called just once, if one misses that opportunity of doing something, there are no ways to do something when the activity resumes. If the order of the events was respected it was easy.
It is not clear to me what happens to a running timer when the activity is paused. Is the timer paused too? And when the activity resumes, is the timer enabled again? If both answers are yes, then my problem is solved - I don't need Activity_Resume. In my tries I've got lost, sometimes the timer was stopped, some other times it was not, so I used a global flag that prevents the Timer_Tick handler to do its duties.
Regarding the orientation of the screen, the problem is when a user rotates the device - he can do it at will, in the middle of an activity, and the App should correctly manage this. That's all. It is not so important, but I started the project in this way and I am too far to change things, I suppose.
I think that the fact that "sleep" and "wait for" are equivalent to a return is sometimes a good thing, but sometimes is a pain. A way to "really block" the code, sometimes, could simplify. This is only an opinion from a programmer (me) coming from other languages, and without a full comprehension... I must study and experiment.