The first half of that sentence is certainly true, but my recollection disagrees with the second half. I’m not sure we had anything but desktop applications back when we introduced DoEvents.
The problem it solved was that people wanted to run synchronous, modal, long-duration tasks without locking up the UI. The ShowModal method let you open a dialog box as a synchronous call, so that you wouldn’t continue to the next line until the user had closed the window, and people wanted to be able to do the same thing with progress windows. That is, they wanted to call a method which would do something or other, and if that method happened to take a long time, they wanted it to be able to open a modal progress dialog with a cancel button. In order for that to work, you have to keep on processing events while the method is busy doing its thing, and to do that you either have to tear the whole method apart and rebuild it with threads and timers, or you have to do what ShowModal does internally and check for events somewhere in the body of your loop. So (if you’ll forgive a little magical handwaving) we exposed the internal method ShowModal had been using, named it “DoEvents”, and thus it became possible to pop up a modal progress bar whenever you needed one.
The key word is MODAL. DoEvents lets you implement synchronous, modal operations with a live user interface. That’s it, that’s all it’s for. Modal interfaces are seriously out of fashion, which is fine by me, so there isn’t much need for DoEvents these days, but if you happen to be building a modal progress window with a live preview, or something of that nature, DoEvents is there to save the day.
Otherwise, you probably ought to use threads instead.
It’s worth noting that DoEvents brings into play re-entrancy issues if you’re calling it from an event handler (which is the typical case). For example, if you call DoEvents inside of a Socket’s DataAvailable event, you risk infinite recursion and a StackOverflowException. Its use in the IDE has been the source of many bugs over the years and I know Norman’s spent time hunting them down and tearing them out.
If we ever get multicore threading with the main thread on one core and tasks running on other cores, it would be extremely surprising if it was possible to access the UI from a task running on another core.
Not necessarily. All depends on what you are doing in those methods, or even how you are calling them.
Here is an intriguing idea I have been toying with. Typically, a common way of raising an AccessingUiException would be because one tried to addRows to a listbox from within a thread. Using a control as data storage is not recommended, but so convenient.
Now, create a class with no super, so no off limit RectControl in it. Call it ListPox, ListBBox or whatever close.
Add an array within it with the same number of rows and columns as a Listbox. Write the class method to mimic what a listbox does for you.
Add for instance the Addrow(paramarray as string) to the class.
Now you got an object that has all the bearings of a ListBox, but from it’s non control nature, it is inherently compatible with a thread.
Add a property ListBBox1 to the window or a module
In the Open event, initialize your pseudo listbox :
Oops. The last line of the code is another experiment, where I store the object into a dictionary, unrelated to this thread. Of course, Edit as always refuses to work when needed. Akin to tossing a slice of bread spread with butter that never falls on the clean side… Sorry.