Hi Everybody,
I’ve been working on a new version (more on what’s new in another post very soon), but in the process ran across something last night which may be a clue to the problems (like error 52) that some of you were seeing recently.
While in development mode (working with uncompiled versions in VB6), I found that in auto runs, sometimes one or both of two forms would be left open, when they should have quickly closed. These forms were the FOUS setup and usage form, and the RAOB data form. I couldn’t figure out why they didn’t close, because my code explicitly told them to! In fact, this is not a ‘bug’ in the usual sense of a logical error in my coding, but rather it’s a weird consequence of the way VB and or Windows is handling, or threading, the commands.
I tried various approaches to fix this. I found that if I didn’t import FOUS, the RAOB form closed OK. I could put more instructions in (VB’s DoEvents command), and get both forms to close, but then the program would stall on the advection form. Fed up with this, I compiled it anyway, and ran the compiled version, and everything worked perfectly! In other words, there really was nothing ‘wrong’ with my code after all. It’s just that the computer/operating system couldn’t handle it as long as it was working within the VB environment.
I suddenly remembered that a couple of you who sent screen shots of error situations had either the FOUS or RAOB forms visible in the screen shot (at least if I remember correctly - or it may have been the Import form in some cases). I’m thinking that on certain computers, with certain configurations or versions of Windows, and with certain other programs running simultaneously, a threading problem might be occurring like what I saw from within the VB environment.
The interesting thing is that such a problem might allow one run to complete, but then trugger an error on the second one (with forms remaining open). While that could be solved by using SS as an external booter, it still means it’s possible the FOUS and/or RAOB data might not really be getting used completely, and the forecast might not be quite as good.
OK, after all that technical stuff, here’s my question/request:
If you’ve ever had the above mentioned errors (or even if you haven’t), watch down on the task bar to see what forms are open as the forecast runs. In fact you can check when it settles down and stops on the Ouput form or returns to the Data Entry form. Only these two should be remaining open for any significant length of time. You might also compare a manually triggered auto run (‘Run Immediately’) with a manual run. As far as I know, there are never such problems with manual runs, and on most computers there are no problems in auto run either, but I might be onto something here that affects at least a few users.
Thanks! 
Tom