Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
View - tableupdate philosophy problems.
Message
De
28/11/2000 20:18:08
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00444385
Message ID:
00446526
Vues:
11
>>>>>The only way I have been able to deal with this is to not do a Requery in EditMode. VERY confusing.
>>>>
>>>>Not really. What would you have the view do? Throw away the changes? AFAIC, the way that it works is preferable- you should either have to explicitly commit (TABLEUPDATE()) or explicitly revert (TABLEREVERT()) before overwriting a dirty buffer.
>>>>
>>>>Your user interface layer should have the smarts to check for a dirty buffer before doing any action that would overwrite the changes, and possibly ask the user if she wants to save or cancel...
>>>
>>>I guess I am not putting this correctly. I am just updating the display when I do the Requery. To show the new line (add) or to remove the deleted line on the grid display. The user cannot get out of editmode without pressing the Save or Revert buttons. I would not dream of suggesting that dirty buffers be thown away.
>>
>>Sorry if I'm being dense. If you're just updating the display, why are you doing a TABLEUPDATE() instead of just a Grid.Refresh()?
>
>Because view is parametrised, parameter changed, so only way to refresh data in grid - refresh view data, that could be done only by requery.
>
>Of course, there are many other ways of how you can organize such interface. GetNextModified function allows you quickly check if view contains any buffered changes pending for update. So, I beleive, you can orginize you interface by following way (sample only):
>You have combobox to change view's parameter value (some filter condition) and grid that allow users to change data, delete or add records. I said that when user changes something, you notice that if needed and disable certain items on form. However, you can organize this by another way. When user changes filter condition (view's parameter), you use GetNextModified function to check if view contains changes. If yes, show user prompt messagebox: "Data were changed, this operation requires to save them. Continue?". However, if you have a lot of controls that may cause view requery when it contains change, Edit Mode approach is better for coding - you don't need to place such prompt messageboxes for each button/combobox/other control that requires view requery.
>
>HTH.

I did use the EditMode approach. It works fine but leaves the user responsible for deleting line records added by mistake (no revert capability) and recovering lines deleted by mistake. Any suggestions allong these lines?

Thanks
Terry
It is impossible to make programs idiot proof. Idiots are too cleaver.

MCP( Tcp/Ip )
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform