Prev: Project 2007 after entering actual work saveas xml takes hours
Next: Evil coercion
From: Mojo on 22 Jun 2010 15:15
Hi All

I have a vb6 app that links to an Access DB.

The basic premise of my app is that the user enters info into a MSFlexigrid
of cells and this info is automatically updated in the db. The rundown is
as follows:

a) user right-clicks on a cell.

b) popup menu of options appears above that cell.

c) user left-clicks on the desired option.

d) app puts selection into cell and updates the relevant field in the access
db using standard in-line SQL calls.

If user wishes to change the selection then they just repeat the above
procedure. The popup menu also includes the option to remove an entered
value so the user can select a 'blank' if they wish to remove the entry
completey.

The above process works fine and users can quickly fill in the 100 odd cells
that they need to fill in.

However, this sometimes falls down when they start to change values in a
column and then realise they should have been chanfing the third (forth,
fifth) column :0)

I need an undo (great if I could have a redo as well) feature give them a
safety net.

Could anybody advise me on how I'd go about this bearing in mind how I
currently update/store the info?

Many thanks in advance for any info/advice you can give.




From: Helmut Meukel on 22 Jun 2010 17:16
Hmm,

two different approaches come to mind:
1) before showing the Data in the Flexgrid, copy the data into
a temp table. That's where you get the original values from
in case of an undo. One obvious problem: if you create
and delete this temp table each time, this bloats the mdb
and you have to compact it regularily. Better to have an
"original value" table and overwrite its records at each
session start. Another drawback: it's on disk or even on
a network drive, thus slower than 2).
2) Store each record (= row) into a second unbound, invisible
grid or better - because less memory consumption - into
an array of UDTs, to have the unchanged values in case of
an undo.
You could reduce the necessary memory usage by storing
only the row data of rows the user tries to change, and in
case of an undo store first the changed rows values into
a second array for a possible redo.
Personally I wouldn't use a bound grid. I would populate
the grid by code, thus the recordset still holds the original
values for any undo. I would update the changed records
when the user is done. But that's my personal preference,
I pay for the flexibility with more code to write.

Helmut.

"Mojo" <please(a)dont.spam.com> schrieb im Newsbeitrag
news:%23gPUP9jELHA.588(a)TK2MSFTNGP06.phx.gbl...
>
> Hi All
>
> I have a vb6 app that links to an Access DB.
>
> The basic premise of my app is that the user enters info into a MSFlexigrid
> of cells and this info is automatically updated in the db. The rundown is
> as follows:
>
> a) user right-clicks on a cell.
>
> b) popup menu of options appears above that cell.
>
> c) user left-clicks on the desired option.
>
> d) app puts selection into cell and updates the relevant field in the access
> db using standard in-line SQL calls.
>
> If user wishes to change the selection then they just repeat the above
> procedure. The popup menu also includes the option to remove an entered
> value so the user can select a 'blank' if they wish to remove the entry
> completey.
>
> The above process works fine and users can quickly fill in the 100 odd cells
> that they need to fill in.
>
> However, this sometimes falls down when they start to change values in a
> column and then realise they should have been chanfing the third (forth,
> fifth) column :0)
>
> I need an undo (great if I could have a redo as well) feature give them a
> safety net.
>
> Could anybody advise me on how I'd go about this bearing in mind how I
> currently update/store the info?
>
> Many thanks in advance for any info/advice you can give.
>


From: Larry Serflaten on 22 Jun 2010 19:36

"Mojo" <please(a)dont.spam.com> wrote

> a) user right-clicks on a cell.
>
> b) popup menu of options appears above that cell.
>
> c) user left-clicks on the desired option.
>
> d) app puts selection into cell and updates the relevant field in the access
> db using standard in-line SQL calls.
<...>

> I need an undo (great if I could have a redo as well) feature give them a
> safety net.
>
> Could anybody advise me on how I'd go about this bearing in mind how I
> currently update/store the info?
>
> Many thanks in advance for any info/advice you can give.

Every time you popup your menu, add the current value to a collection
keyed on the cell ID. Have an UnDo in the popup menu (possibly
UnDo Cell and UnDo Column) enabled any time there are values in the
UnDo collection for the current cell (or current column).

If you want a ReDo then only when they select UnDo, move the contents
of the current cell's (or current column's) UnDo value to a ReDo collection
also keyed on the cell ID. Enable the ReDo menu item when there are values
in the ReDo collection for the current cell (or column).

Clear the collections at the start of a new page.

For column action, you'll have to programmically create cell IDs to apply
to the UnDo/ReDo collections.

LFS


From: ralph on 22 Jun 2010 22:56
On Tue, 22 Jun 2010 23:16:52 +0200, "Helmut Meukel"
<Helmut_Meukel(a)NoProvider.de> wrote:

>Hmm,
>
>two different approaches come to mind:
>1) before showing the Data in the Flexgrid, copy the data into
> a temp table. That's where you get the original values from
> in case of an undo. One obvious problem: if you create
> and delete this temp table each time, this bloats the mdb
> and you have to compact it regularily. Better to have an
> "original value" table and overwrite its records at each
> session start. Another drawback: it's on disk or even on
> a network drive, thus slower than 2).
>2) Store each record (= row) into a second unbound, invisible
> grid or better - because less memory consumption - into
> an array of UDTs, to have the unchanged values in case of
> an undo.
> You could reduce the necessary memory usage by storing
> only the row data of rows the user tries to change, and in
> case of an undo store first the changed rows values into
> a second array for a possible redo.
>Personally I wouldn't use a bound grid. I would populate
>the grid by code, thus the recordset still holds the original
>values for any undo. I would update the changed records
>when the user is done. But that's my personal preference,
>I pay for the flexibility with more code to write.
>

If using either of these methods you can easily preserve a client
bound grid model through a "data aware" class. In this case a
DataSource provider. (Lookup details in the MSDN Help for "data aware
classes".)

Think of it as an intermediate class under your complete control to
handle special data management. In this case any behind-the-scenes
temporary storage.

You might consider using a discontinued Recordset rather than
re-inventing your own store.

Another more exotic solution is to adopt an audit model for critical
sections of the database. But this is likely over-kill in this case as
it would increase the complexity of the design and dramatically
increase the size of a MDB file.

hth
-ralph
From: Larry Serflaten on 23 Jun 2010 09:03

"ralph" <nt_consulting64(a)yahoo.net> wrote

> You might consider using a discontinued Recordset rather than
> re-inventing your own store.

Do I detect a freudian slip here?

<g>
LFS


 |  Next  |  Last
Pages: 1 2
Prev: Project 2007 after entering actual work saveas xml takes hours
Next: Evil coercion