Re: Stack over flow?

Mike Williams wrote:
On 15 Apr, 04:08, "Steve Gerrard" <mynameh...@xxxxxxxxxxx> wrote:

I had always assumed that the event which your code triggered (the
Change event in this case) would go in a queue waiting to be actioned
and that the queue would not be actioned until after the code block
finished executing, unless you put a DoEvents in there to deliberately
cause the event to execute immediately. Now after testing it I can see
that for events triggered by your VB code the event gets executed
immediately anyway, so the DoEvents is not necessary, unlike events
triggered by the system (a resize or whatever triggered by the user)
which do behave in the manner I described and which do end up waiting
in the queue until the code block finishes. I'm glad you posted that,
Steve.

In fact I have often used an event specifically to delay the execution
of some code, in the mistaken belief that something I did would go in
a queue until my current code block finished executing. For example
I've just written a program for my daughter which required a fairly
lengthy code block to be executed in response to a WM_DISPLAYCHANGE
message which I was trapping in a subclassed WindowProc function. I
have always figured that in any subclassed routine it is better to
"get out of there" as quickly as possible (just my old fashioned way,
I suppose?) and I figured that if I simply changed the Text property
of a TextBox Text in the subclass routine then my code in the subclass
routine would finish (the WindowProc routine would finish executing)
and the code in the TextBox's Change event would not begin executing
until after that point in time. Now it appears that this is not the
case, and the Change event code gets executed immediately, while I am
still in the subclass routine, so I might as well have just called the
"lengthy code block" directly, without bothering with all that Change
event stuff! You learn something new every day! Thanks a lot, Steve.

So, it looks like I'll have to do it some other way, perhaps by
setting up a "one shot" Timer or something, or perhaps using some kind
of system message that performs the task. Must get my thinking cap on!

Curiouser and curiouser, as Alice would have said! I would be very
interested to hear your thoughts regarding this "get out of there
quickly" thing that is in my head regarding code in subclassed system
events, such as Window messages and key and mouse events, especially
low level events. Is it actually necessary to "get out of there
quickly", or am I just being a bit old fashioned?


HI Mike,

I had roughly the same notion about events being triggered, until I worked for a
while with classes that raised events, and discovered that an event occurring
within VB are essentially like a direct call, as you have described. Although it
must go through a little more lookup code to find out if there are any event
handlers listening, it does not continue your own code until the event has been
handled - or ignored - first.

To get the queued effect, I think you have to use windows messaging. If you had
sent a SetText type of message to the text box, instead of setting the text
directly, then a message would have gone into the message queue, the rest of
your subclass routine would complete, and then, at its leisure, Windows would
process the next message and trigger the text box change event. But if you
change the text directly, it becomes a direct call (I almost want to say modal),
going through the VB runtime and executing the change event before your next
line of code executes.

I don't really know if getting out of your WindowProc in a hurry is all that
critical. Most of what happens in VB, as you know, is triggered by events, most
of which trace back to a message getting processed. A button click event, for
instance, starts out with a windows mouse message getting processed, which
decides to trigger the event handler. All of your button click code is running
in a call from the master window proc that responded to that mouse message. It
is actually pretty difficult to get code to run that hasn't been initiated by a
window proc somewhere up the call chain.

Still, there is something about subclassing that suggests that the less you do
the better, and the sooner you can return to normal VB runtime operations, the
better. I don't have enough experience with it to say if there is a cost to
having a long routine run from your own window proc. Maybe you are "working
without a net" while you are in there, and a VB error will crash your app? I'm
not sure.

Have fun sorting it out.



.

Loading