Did the Release/Clear in the script and in FW_Exit.prg to make sure. Still no change. I think that the problem centers around the msdos class reaching into Kernal32.dll for most of its mojo. I'm going to rewrite the class to interface directly with ASpell for its input and output. I'll post it here if/when I get it working.
Sent by FoxWeb Support on 01/25/2008 02:11:27 PM:
My guess is that the program file that needs to be re-compiled contains definitions for an object that is resident in an active channel. In order to re-compile such files, you will either need to re-start all your channels, or make sure that you release all objects AND classes defined in them. Some users add RELEASE ObjectVariable and CLEAR CLASS ClassName commands in fw_exit.prg for this purpose.
You may also need to issue a RELEASE PROCEDURE FileName command for each program that you SET PROCEDURE to.
Sent by Jim on 01/25/2008 01:51:15 PM:
Ok, this one has me stumped.
I have a script that, when compliled by foxweb/foxpro, works just fine. When I make a change that requires a recompile, the channel becomes busy, the normally invisible instance of Foxpro becomes visible and complains of "too few arguments" (but is otherwise blank - no lines of code to look at). In time, the script times out and foxweb shuts down the otherwise stalled foxpro instance and re-launches it. It doesn't seem to matter how insignificant a change I make, including just adding a comment. The pattern of behavior is the same. This error also doesn't get recorded in the foxweb error table. It's not really a show-stopper since the runtime server only will have the compiled modules anyway, but it's still strange.
The script also performs just fine in foxpro no matter what changes I make.
The particulars: I am using a custom class (found here: http://www.news2news.com/vfp/?example=477&function=9) to create a dos session. I do this to overcome the limitations of the RUN command. (And for the curious, I'm dropping to a dos prompt to feed server-side data to ASpell which - aside from this quirky error - is far and away faster than the typical MS Word Object spelling check approach.)
Does it have to do with the fact that before the script is compiled, the 'msdos' class is unknown? Just guessing at this point.