Link to home
Start Free TrialLog in
Avatar of gsatir
gsatir

asked on

Custom Menu Cut, Copy & Paste

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,
Greg
Avatar of nico5038
nico5038
Flag of Netherlands image

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 ?

Nic;o)
Avatar of gsatir
gsatir

ASKER

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.

Greg
ASKER CERTIFIED SOLUTION
Avatar of nico5038
nico5038
Flag of Netherlands image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of gsatir

ASKER

> 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.

Possible?
Greg
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.

Nic;o)