Re: FoxPro is a frustrating and very user unfriendly
From: Dan Freeman (spam_at_microsoft.com)
Date: 09/10/04
- Next message: toto: "Re: GPS Q."
- Previous message: MAppell917: "Re: FoxPro is a frustrating and very user unfriendly"
- In reply to: Ook: "Re: FoxPro is a frustrating and very user unfriendly"
- Next in thread: Gene Wirchenko: "Re: FoxPro is a frustrating and very user unfriendly"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 10 Sep 2004 16:43:52 -0700
Since I've NEVER used DO FORM xxx TO whatever, I suspect this is anecdotal.
Rather, my "OK" (or whatever) button on modal dialogs hides the form which
allows execution to continue. The next code that executes fishes whatever
property I need directly out of the form and then releases it.
Dan
Ook wrote:
> Your mention of modal forms jarred a memory loose. There is a
> definite link between forms that return a value (IE modal forms) and
> c0000005. Simply running a form that returns a value, but not
> actually accepting the value can cause VFP to bork:
>
> DO FORM XYZ
>
> instead of
>
> DO FROM XYZ TO lnValue
>
> In VFP6, this is a real good way to c0000005. Unfortunately, it's not
> consistent, and although I've seen it a lot I could never reliably
> duplicate it.
>
>
> "MAppell917" <mappell917@aol.com> wrote in message
> news:20040910173037.19486.00000481@mb-m22.aol.com...
>> Ook - I could only speculate on the following ideas as to why some
>> get c0000005 more than others...
>>
>> 1. When I compile my program for the final exe, I remove all the
>> methods prg code from the forms and classes. It also has the
>> advantage of making the exe a lot smaller.
>>
>> 2. I always set my CreateObject variables to "" and then release
>> them at the end of the procedure.
>>
>> 3. I use very few public variables (maybe 4 or 5 in the entire app).
>>
>> 4. I never use inheritance more than 2-3 levels deep (mainly
>> because I have just never needed to).
>>
>> 5. I use encapsulation as much as possible and use as few modal
>> forms as possible.
>>
>> 6. I display the detailed error information including the
>> procedure/class name and line number for quick and easy debugging if
>> errors ever do occur.
>>
>> There are probably other things I do as well but I'm not sure if one
>> or several of the above minimize the C000005 errors. In fact, I
>> think it has been months since ANY of my clients have mentioned this
>> error (this could also be due to further migration to XP but it's
>> very infrequent even with my Win 98 clients).
>>
>> Regards,
>>
>>
>>
>>> I've been on this list for many years, and I've been sharing
>>> experiences with others here for a long long time. And one thing
>>> I've learned is that some people get them a lot while others don't
>>> get them at all. I wish I knew why. I've experienced specific
>>> method code corruption issues in VFP6 quite a bit, and I've met
>>> several others that have seen it also. Yet many others have never
>>> had it happen. Why?
>>>
>>> I can't answer that question, but I can definitively say that VFP6
>>> gave me a lot of c0000005 no matter what machine I worked on, while
>>> VFP8 almost never does.
>>
>>
>> Mike
- Next message: toto: "Re: GPS Q."
- Previous message: MAppell917: "Re: FoxPro is a frustrating and very user unfriendly"
- In reply to: Ook: "Re: FoxPro is a frustrating and very user unfriendly"
- Next in thread: Gene Wirchenko: "Re: FoxPro is a frustrating and very user unfriendly"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
