>Thanks Beth.
>
>Honestly, I don't see how wizstyle could be involved (given the filename issue) but... jic... do you see the same thing if you use a form that does *not* have any such dependency? Is it possible for you to test this?

Not really, because a lot of stuff in that form depend on prgs that call it that were called by other modal forms. It is UGLY!

>
>IOW, if it's possible for you to move that button code to a "plain" form, outside your app, and find out if it is really the report or some completely unrelated factor, that would be very helpful.
>
>If that is not something you can do, I would like to see this, please e-mail me and we'll try to figure something out.
>
>My only other possible avenue of testing this (as a suggestion) would be to change the default name, change nothing else, and see if it continues to fail ** WHEN THE USER KEEPS THE DEFAULT NAME ** and continues to work ** WHEN THE USER CHANGES THE DEFAULT NAME to a different value **. If that happens, it's something in your code branch. I noticed a couple of things, like an early RETURN in that branch, and tracing through this very carefully might turn up something.

The work around that was found, but not liked, but works, is to change the default name for the file.
*Yeah, on that early RETURN, that is the way the coding was done back in vfp3 by the company that accually built this app, QueryMaker, we bought the code and have done some changes but no one wants to re-write the whole thing, or has the time.*

>
>After you change the default name, if it does not fail when the user keeps the default name, does it now fail when the user changes the default name to your original default? If that happens, I *really* want to see it <g>.

Not sure about this, will have to check. < g >

>
>>L<