Robs Programming Junk

While trying to use a foxpro COM object in .NET for a project I'm working on I ran into this little problem.



VFP: User interface not allowed at this time



Intresting enough it makes sense. The .DLL by law cannot have interfaces to it. VFP 6 at least doesnt suppress this when it compiles a DLL. I don't know about future versions such as 9 installed on my machine, but our production code is stuck in 6.0 for the moment.



The easiest work around for this was to compile it as a COM EXE server. This allows for the wait windows to show up in the upper right of the machine on the desktop window.



Which is a very intresting point. I'm quite surprised that the same EXE that you compile for any other foxpro application can also act as a com server. Simply exposing the class via OLE PUBLIC specification seems to be more than enough to use any EXE as a COM server and allow another application to use that server.



While I can use the work around, I don't really agree with it. VFP should have supressed the calls to the WAIT WINDOW in the DLL Compile and compeltely ignored that output. I can see if I was making a MESSAGEBOX call, but with a wait window it should have just been surpressed. Ultimately I'd remove the wait windows and make it a true DLL but I'd have to bust open too much legacy code.



On the other side of things, one additional note about this project. When using a COM object made in foxpro from within .NET, make sure youre cleaning up your objects. As anyone who's used foxpro for any great amount of time knows, it makes for lazy programmers. V ariables are often not cleaned up . Foxpro doesnt care and thus you can get some unpredictable results as part of you com object use.



I suggest that you use the .NET System.Runtime.InteropServices and call the Marshall.ReleaseComObject() at the end of each call to you com object. You can avoid this by writing really good foxpro code, but few people do that.