Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Caller form to search form to data entry and back
Message
De
08/02/2016 16:05:23
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2003
Database:
MS SQL Server
Divers
Thread ID:
01631070
Message ID:
01631073
Vues:
74
>Assuming I understand this right - it does sound like something I've done in the past - and it was a real pain to get it to work - but it turned out really nice.
>What I did was:
>1. First I used remote views for everything - and created a classlib with a timer in it.
>2. Anytime a view is requerried, I kept track of the parameter(s) that were used to requerry the views. I did this by keeping an array in that class that kept all the view names, variables, and values for those variables used to refresh the view.
>3. ThenI put this class on each of my forms. Now if the user is NOT in 'edit mode' - I would run the timer gizmo every x seconds (or minutes, depending upon their requirement) - and it would auto-reuqery all the views and refresh the form. If all the data was the same - then no big deal , leave everything alone.
>4. Now if the form had gone into 'edit mode' - and now you want to save - then it's necessary to check for conflicts - which my gizmo did also - and then would popup a screen showing the differences and would allow the user to pick which update (s) they wanted to keep.
>
>I spent a HUGE amount of time on this back in around 2001 or 2002 - and it really came out quite nice - one of the things I'm more proud of actually. I really should it in the downloads section sometime but the code was pretty hard to follow and I didn't want to be answering a zillion questions about it so I never did.

Something like... and wow, this is heavy artillery, in comparison with my scenario. You were checking for edits potentially done by others. This is, well, one thing that this should do, i.e. check for changes in the lookup table and refresh that one view (i.e. the lookup alone) and leave everything else as it was (for which he can't find a way, it's refresh all or nothing or he can't find the switch).

This is simpler but more specific. Assume form A (order entry) needs a customer, launches search form (B, customer search). While in form B, the user finds that some customer record editing must be done (address change perhaps) or the customer simply isn't there. So either form B can edit, or it launches C to edit the customer record. Saves, returns to B, which is requeried and now shows the newly changed record (by this user, and potentially by others). Returns the PK to A, which still has a cursor (or rowset or whatever they have) which now has old data - one record in it may be missing or old. I fox, we'd just requery that one cursor and display a few fields from the latest and greatest record from it. He has a problem even finding a description of such a scenario.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform