Recursive in SpriteProc??

[Donone]

I have the following, and could do with some help please. The questions are in the pseudo code, which is in a class.

private func SpProc(Sprite$, Msg$, wParam$, lParam$)
case (Msg$)
WM_TIMER:
if(.....)
self.Stop;
This goes to proc stop because there are things to do.
else
How do I invoke WM_END in here, without blowing the stack?
Must I have a dummy procedure to go to when there is nothing to do?
end;

WM_STOPPED:
Call(self$,self.OnStop$,hWnd$,LPos(SpPath$),wParam $,lParam$);

WM_END:
Call(self$,self.OnEnd$,hWnd$,LPos(SpPath$),wParam$ ,lParam$);
end;
Return(True);
end;
//==============================
private proc stop
... ...
SpProc(Sp$,WM_STOPPED,Spr.x$,Spr.y$);
end;

[kornalius]

WM_TIMER:
if (...)
self.Stop;
else
Call(self$, self.OnEnd$, hWnd$, ...);
end;

WM_STOPPED:
...

The other method:

self.EndIt;

This should blow up the stack.

private proc EndIt
SpProc(sp$, WM_END, Spr.x$, Spr.y$);
end;

[Donone]

I think I misunderstand.
Are you saying that I don't need WM_STOPPED or WM_END, I just call the self.on***$ from wherever needed?
If so, I don't need #defines *** WM_USER + 10???
Sorry please excuse my thickness, I'm obviously missing the point, but am desperate to get this sorted.

[Edit] I note also the use of Call not objCall ???
I'm becoming confused. The first you mention above blows the stack. The second cycles between end and stop continuously.

[kornalius]

I meant "this SHOULDN'T blow up the stack", not the other way around.

The reason why you call WM_STOPPED is because the user can have it's own OnStop procedure.

If you don't want to use events, you don't have to. In OnStop procedure simply call the user's procedure in OnStop$ using ObjCall() that will suffice.

[Donone]

I understand the reversal misunderstanding of blowing the stack.
Thank you for coming back on this otherwise I would have a lost wekend.
I understand the purpose of the procedures and had it working with Stop.
However, I then got confused by some comments and examples, which when I tried them, they worked also.
I managed the same effect without using WM_STOPPED (which I have sent you)are reading your comments.

My problem came when I tried two events and they cycled between each other.
I don't know what was going on.

[kornalius]

If you want to explaing the recursive call problem to me in a single post ;) , I'd be happy to help you.

[Donone]

Impossible
The code with problems appears elsewhere.
I think this thread is dead. Move to my others.

For anybody else's benefit the recursion occurs when the SpriteProc WM_TIMER code calls the WM_STOPPED code which is still in Spriteproc and the message is sent out of SpriteProc and then back in to go to WM_STOPPED, which when finished will eventually go back to continue the code in WM_TIMER, therefore SpriteProc has recursively called itself, in effect.