VB6 -- is there a limit on the number of events that can be queued up?

Consider a complex form in VB6 that has LOTS and LOTS of buttons, dropdowns, etc, some of them kicking off data access calls, and therefore requiring some time (500 ms?) to complete.

It would be possible for the user to kick one of the data-intense processes, then click a bunch more things in that form while the data process caught up.

What would happen?

Is there a limit to the number of those events (not just clicks, but events caused by internal stuff too) which can be kept queued up?

And if the user exceeded this limit ... what would happen?

Would this cause the program to crash without a visible error message?

Thanks for any insight ...
LVL 32
Daniel WilsonAsked:
Who is Participating?
peetmConnect With a Mentor Commented:
I believe RaiseEvent is synchronous - so I think we're only talking about events on the UI, and timers, dde, ... here, i.e., queued Windows' Messages, which are translated to VB events?

I don't believe there's a way to query the OS about this, and so you'd have to empirically derive the necessary value ... I should think this will get you somewhere close ...

Private Declare Function PostMessage Lib "user32.dll" Alias "PostMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
Private Const WM_MOUSEMOVE As Long = &H200

Private Sub Command1_Click()

    Dim l As Long

    Do While PostMessage(Me.hwnd, WM_MOUSEMOVE, 0, 0)
        l = l + 1

    Debug.Print l

End Sub

I'll let you run that to see the output - which I found to be surprisingly large!

Daniel WilsonAuthor Commented:
hmm ... 10,000.

Even with multiple grids and data sources ... I don't think we're hitting that figure.

BrianVSoftConnect With a Mentor Commented:
That situation is normal to most business forms..
Normally windows doesn't allow any new "Click" to run until the previous process has finished.
If you have long processes, it is normal to allow "User Cancel" options which require the inclusion of the infamous DoEvents statement..
DoEvents will allow the user to Click start other processes..
In any case, It is normal to simply control these processes via a public variable Eg Processing as Boolean
Sub Button99_Click
 If Processing then Beep : Exit Sub
 LabelBusy.Visible = True
 Processing = True
 LabelBusy.Visible = False
 Processing = False
End Sub
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

It's also possibly the case [as this is undocumented as far as I know] that the 'queue space' is a fixed size, i.e., you'll queue less messages that carry with them heavy data structures - one of the reasons that this is usually 'done' via carrying a fixed-sized pointer.
aikimarkConnect With a Mentor Commented:
With this description, I think you are facing a choice between restructuring and managing user expectations.  The later is much simpler...when the user clicks on a control that is associated with a (potentially) long running process, then do the following in that control:

Private Sub cmdGetData()
  Me.MousePointer = vbHourglass
  Me.Enabled = False
  'do the button click work here
  Me.Enabled = True
  Me.MousePointer = vbDefault
End Sub

Open in new window

Daniel WilsonAuthor Commented:
OK, I think I got this solved by disabling some buttons during long-running operations.  Thanks, everyone!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.