Re: ListBoxes and Out of Stack Space

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Pop ...

Reason for your problem: The default property for a listbox is the Text
property. Your inadvertent omission of the listindex property in the
assignment resulted in the code attempting to set the current focus to an
item named -1. Whenever the focus on a listbox changes, a click event is
generated, and, because your code was already in the click event, the
problem line executed again resulted in an item change being sent, where the
click event was generated again and so on ad nauseum until your crash.
Because each attempt to assign -1 to the list resulted in a new click being
generated, the End Sub portion of the procedure never completed leading to
the recursive behaviour you didn't anticipate:

<Enter Click - code/user causes click>
code assigns to default property causing click
code re-enters click event
code assigns to default property causing click
code re-enters click event
code assigns to default property causing click
code re-enters click event
code assigns to default property causing
click
code re-enters click event
... and so on to <out of stack space>


If you have to put code in a list click event, and the possibility may arise
that the code in the event (or code executed in another procedure that
changes the list) causing the click event to fire again, the normal way to
handle this is to wrap your list (or combo box) click code in some sort of
wrapper that will prevent errant re-execution, something along the lines of
(air code)

dim bBusy as Boolean

sub list1_click
if not bBusy then
bBusy = True
<other code that may trip the click event>
bBusy = False
end if
end sub

an alternative is to set (and clear) the variable flag somewhere else and if
set, just bail from the code:

dim bBusy as Boolean

sub list1_click
if bBusy then exit sub
<other code that may trip the click event>
end sub


--


Randy Birch
MS MVP, Visual Basic
http://vbnet.mvps.org/

Please respond to the newsgroups so all can benefit.


"Pop`" <nodoby@xxxxxxxxxxxxxxxxxxx> wrote in message
news:Zk3wi.6596$Ns6.2908@xxxxxxxxxxx
Larry Serflaten wrote:
"Pop`" <nodoby@xxxxxxxxxxxxxxxxxxx> wrote

This isn't earthshaking, and I wouldn't advise anyone to go out of
their way if your only purpose is to answer me; I'm currently placed
this in my "huh" list <g>.

Try that again, only when you see the error message, hit the Debug
button,
then from the VB menues, select View > CallStack. That will list the
procedures currently on 'the stack'. Its a good bet you do have some
recursive action going on. Highlight one of the repeating items in
the CallStack and hit Show to see what line is causing the
recursion....

LFS

Huh!! You're right; I'd have sworn it came up with nothing, but this time
it's holding a gazillion and a half repeating calls, all to the errant
listbox!

OH - MY - GOD! I see it: .ListIndex is MISSING!
Now it works (so far!).
It's been missing for three revs and is in the 4th one back! HOW in HELL
that happened is beyond me! I didn't come close to even touching that area
of code in the previous three revisions! Those were all cosmetic changes to
the screen presentations.
I DID rearrange some of the positions of the Subs though, using MZTools;
maybe it happened there. Any known issues with MZTools?

Interestingly enough, it WAS reporting the Private Sub as the problem line,
but now it's pointed to the next line.
Oh well, another piece of "rivet-ware" fixed at least.
----------------------
' FIXING OUT OF STACK SPACE ERROR
Private Sub lstPillsPerDay_click()
lstPillsPerDay = -1 <==== indicated problem line.
End Sub
----------------------
Thanks, sorry it was cockpit error! Gads!!

Pop`



.

Quantcast