Hi,
I have a class, used to handle my state machine software. The class has, amongst others, these two methods
RunStateMachine is also in the class
Module and StateCode are setup when the class is initialised in activity_create, i.e.
pMainScreenButtonManager.Initialize( Me, "MainScreenButtonManagerCode")
Me is saved in class variable Module, the sub name (MainScreenButtonManagerCode) is saved in the class variable StateCode
Several instances of the class are created, mostly in activity_create and all with different subs named in the initialize call.
i.e.
pTopLevelManager.Initialize( Me, "TopLevelCode")
The classes send "messages" to each other using AddToEventAndDataQueue.
i.e. in pTopLevelManager a "message" is sent to the button manager.
pMainScreenButtonManager.AddToEventAndDataQueue(SHOW_START_BUTTON,Null)
The idea being that the button manager code will run when the top level manage sub returns. Several "messages" may be sent in one call of the originating sub. Usually the originating sub (such as top level manager) was its self run from a "RunStateMachine" sub call after it received a button click "message"
This works some of the time in Rapid Debugger and all of the time in Legacy Debugger.
In Rapid Debugger the CallSubDelayed will usually fail at a certain point in the program run (having worked when used earlier). In the Legacy Debugger it works every time.
Fail means the CallSubDelayed code line executes, there is nothing in filtered or unfiltered logs to suggest a problem, but the RunStateMachine sub is not executed.
Occasionally but not consistently a break point before the "AddTo.." call will result in the delayed call working but then on the next run (without any program changes) it will fail again.
Should i be concerned about my code or is it likely to be some sort of rapid debugger issue?
Steve
I have a class, used to handle my state machine software. The class has, amongst others, these two methods
B4X:
Public Sub AddToEventAndDataQueue(event As Int, data As Object)
Dim newMsg As eventAndData
newMsg.Initialize
newMsg.event = event
newMsg.data = data
eventAndDataQueue.Add(newMsg) ' my work queue (a list)
CallSubDelayed(Me, "RunStateMachine")
End SubRunStateMachine is also in the class
B4X:
Sub RunStateMachine
Do While eventAndDataQueue.Size > 0
Dim newMsg As eventAndData = eventAndDataQueue.Get(0)
eventAndDataQueue.RemoveAt(0)
CallSub3(Module, StateCode, newMsg.event, newMsg.data)
Loop
End SubModule and StateCode are setup when the class is initialised in activity_create, i.e.
pMainScreenButtonManager.Initialize( Me, "MainScreenButtonManagerCode")
Me is saved in class variable Module, the sub name (MainScreenButtonManagerCode) is saved in the class variable StateCode
Several instances of the class are created, mostly in activity_create and all with different subs named in the initialize call.
i.e.
pTopLevelManager.Initialize( Me, "TopLevelCode")
The classes send "messages" to each other using AddToEventAndDataQueue.
i.e. in pTopLevelManager a "message" is sent to the button manager.
pMainScreenButtonManager.AddToEventAndDataQueue(SHOW_START_BUTTON,Null)
The idea being that the button manager code will run when the top level manage sub returns. Several "messages" may be sent in one call of the originating sub. Usually the originating sub (such as top level manager) was its self run from a "RunStateMachine" sub call after it received a button click "message"
This works some of the time in Rapid Debugger and all of the time in Legacy Debugger.
In Rapid Debugger the CallSubDelayed will usually fail at a certain point in the program run (having worked when used earlier). In the Legacy Debugger it works every time.
Fail means the CallSubDelayed code line executes, there is nothing in filtered or unfiltered logs to suggest a problem, but the RunStateMachine sub is not executed.
Occasionally but not consistently a break point before the "AddTo.." call will result in the delayed call working but then on the next run (without any program changes) it will fail again.
Should i be concerned about my code or is it likely to be some sort of rapid debugger issue?
Steve