Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Load method bomb warning
Message
 
À
30/01/2002 16:41:59
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Divers
Thread ID:
00613066
Message ID:
00613115
Vues:
12
Glen;

This is good advice. When VFP 3.0 beta was released we had to figure out what code goes where. One of my friends described it this way, "Visual FoxPro gives the promise of great power with one line of code. This will replace entire procedures in previous versions of FoxPro. Our job is to figure where that one line of code goes"! :)

To determine what to do, where code should go and so on, we put wait windows with messages "Guess where I am"? and similar things in a number of places. It was not long until we understood the sequence of events and how to use them to our advantage. I do not know of a reference to this but it would be nice to have one.

Another thing we found out is how to make a reference call to refresh an object. ThisForm.Refresh() used a lot of resources and with 100 Mhz state of the art machines was almost a show stopper for some forms. Better to know about the effect of such calls.

Again thank you for your input. We need a way to exchange this type of information so people will know how and what to do when creating a VFP application. Too many of us take things for granted. Having come from the ranks of electronic engineering, I like things to be well indexed, to the point and dead on. Reading six 1500 page books will render (with luck) six paragraphs of useful information. Give a programmer a brief list of what to do and what not to do and you can save him/her days of effort!

Tom


>I meant to put this into the thread awhile back. It's a WARNING. We were accustomed to puting a lot of code into the Load method because in Fox2x this is what you did. All of our screens have been converted into VFP and we continued with the habit sometimes of using the Load to run some things.
>
> This lead to a couple of big disasters! One instance was a simple Keyboard clearing routine. Under certain extreme circumstances we'd get a disasterous failure (1999 I think) and the failure can't be trapped. It took a while to determine where the failure generated from. Move the code into the Init method and the problem disappears.
>
> In another form we were starting some DBI components from the Load method and sometimes, not always, this generated GPF's. Sometimes we had to reboot the compter. Once again, we move the code to the Init method and everything is fine.
>
> In summary, get in the habit of using the Init method and leave the Load alone. Our failures were in VFP 6, but I assume VFP 7 has the same problem.
>
> - Glen -
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform