Custom Menu Cut, Copy & Paste

Posted on 2006-11-02
Last Modified: 2008-03-03
Hello, Experts

I am trying to make an application that uses a custom menu bar for most actions, rather than my typical collection of buttons.  Most things are going well, but I am getting hung up on Cut, Copy and Paste.  I have thought through the problem down various paths and cannot find one I am happy with.  I am hoping to get some feedback.

I have a main form that is always open and it has various text boxes and a few subforms in continuous mode.  The problem is that standard Cut/Copy/Paste works great for text boxes and simple subforms, but doesn't work correctly if the user selects an entire record in a subform that links to other tables in a 1-to-many relationship.  All the information could be deleted by the Cut using cascading delete, but it will not be properly saved by the Cut or Copy or Pasted correcly.

But if I replace the standard Cut, Copy, Paste then I have to somehow handle disabling them in various situtations --like no text selection, focus is on a command button, etc.  This seems time consuming and error prone.

Ideally, I could simply replace Cut, etc. with "Cut Entire Record", etc. when an entire record is selected and show standard Cut, etc. when it is not.  I could track the record selector being clicked with the subform's OnMouseDown event, but I see no way to easily track when the focus leaves the record selector.

My final idea is to hide the record selector and any way for the user to select an entire record and make a fake one myself.  Then I would never have o worry about standard Cut morphing into incorrect full record Cut.  This could work but I always find these little tweaks turn into hair pullers once I get into them.

So that's where I am...1. Drop standard C/C/P and lose auto disabling,  2. Disable standard C/C/P when record is selected, 3. Drop record selectors and fake my own.

If you made it this far, thanks!  Any thoughts...?

Kindest Regards,
Question by:gsatir
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
LVL 54

Expert Comment

ID: 17865904
Hi Greg,

In a similar situation (related records) I used a temp table solution.
When the user starts adding/updating he gets a copy of the information and is working on the copied rows in temp tables. This will allow the addition and deletion of related records and when the user presses [Save] the original rows are deleted and the new rows are added.
When the user presses the [Cancel] you do just nothing :-)

Getting the idea ?


Author Comment

ID: 17887264
I can see how using a temp table would  be a good idea.  I tried to store the copied information in a listbox, but if it gets changed (or "deleted" by the cut) then the listbox information changes as well.  Since it will never be that much information  cut and pasted, is there a simple way to, say, open a recordset where you know it won't change regardless of what happens to the underlying records.  Kind of the opposite of what we usually want in a DB :-)

BTW, I went with #2 above and it seems to be working.

LVL 54

Accepted Solution

nico5038 earned 375 total points
ID: 17891561
For not changing the real information the temptable is the only way I know to allow users to manipulate data without effecting the underlaying data.
It will also stay "stable" as long as you don't recreate the temp table.

For a record oriented cut/copy/paste you could use also a temp table with just one record.
For the cut/copy issue:
currentdb.execute ("insert into tblTemp (select * from tblSource where key=" & me.subform.form.key & ")")
currentdb.execute ("delete * from tblSource where key=" & me.subform.form.key)
now the row is in the temp table and you can add it with:
currentdb.execute ("insert into tblTarget (select * from tblSource where key=" & me.subform.form.key & ")")
Thus the same row can be copied to multiple tables when needed.
Just take care that the target table doesn't have an autonumber key, else all fields except the key field should be used in the insert instead of the "*".


Author Comment

ID: 17902975
> For not changing the real information the temptable is the only way I know to allow users to manipulate data without
> effecting the underlaying data.

This sounds like a different issue than I am facing...I want a way to create an internal "clipboard" that can be used to cut/copy and paste records.  So the clipboard will never be editted, but for a copy the original might be editted and for a cut it is deleted.  Is there a way to open a recordset that says "once this recordset is populated, do not change it based on other changes made later."  So I could open a recordset on a cut/copy and then delete or allow edits to the original data and still have my clipboard intact.

LVL 54

Expert Comment

ID: 17904452
The temptable approach will give you that "clipboard"as the row in the table will remain the same and can be inserted many times.
The cut action will require you to store the current record in the table and delete the original record. All needed is to empty the temp table before a cut or copy record is added so only one record will reside.
When your application can be used by multiple users, you'll need to add a unique ID (being the username you can get from the Environ( "username") function) so there will be no mixup. Using a temp table will even keep the last record fixed over multiple Access sessions.

Your requirement "once this recordset is populated, do not change it based on other changes made later."  should be controlled by the application as we can't protect direct updates in tables by the uuser, unless you're using an .mde for the user.


Featured Post

Revamp Your Training Process

Drastically shorten your training time with WalkMe's advanced online training solution that Guides your trainees to action.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Access custom database properties are useful for storing miscellaneous bits of information in a format that persists through database closing and reopening.  This article shows how to create and use them.
Did you know that more than 4 billion data records have been recorded as lost or stolen since 2013? It was a staggering number brought to our attention during last week’s ManageEngine webinar, where attendees received a comprehensive look at the ma…
Using Microsoft Access, learn some simple rules for how to construct tables in a relational database. Split up all multi-value fields into single values: Split up fields that belong to other things into separate tables: Make sure that all record…
In Microsoft Access, learn how to use Dlookup and other domain aggregate functions and one method of specifying a string value within a string. Specify the first argument, which is the expression to be returned: Specify the second argument, which …

734 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question