PDA

View Full Version : Solved: Populating a user form, editing the data, then saving it back to the spreadsheet



christoday
01-29-2007, 03:24 PM
Lack of MS Access has prompted me to create a userform to act as a user interface for a spreadsheet. I have several text boxes and have created two search boxes and have tested that they populate the user form's text boxes with data from the corresponding cells.

What I need: After population, the user needs to be able to edit this data, then save it back to the original row, or, alternatively, delete the original row and insert the data as a row in it's place.

I've searched the forum, have found some very useful nuggets but I can't find a solution for this one.

I've attached my file for info.

Any help very much appeciated.

Bob Phillips
01-29-2007, 04:06 PM
I tried to use it, typed something in, and it just shutdown on me.

mdmackillop
01-29-2007, 05:05 PM
Declare rngfind as a global variable, then code such as
Private Sub txtType_AfterUpdate()
Cells(rngfind.Row, 2) = txtType.Text
End Sub
should update your spreadsheet.

Like XLD, I'm finding the same thing. For some reason, this code is running
Private Sub cmdOK_Click()
I've tried changing the Tab values relating to the button, but no success.

Charlize
01-30-2007, 03:17 AM
Try this somewhat amended form. You still need to check the dates. One tip : use a variable declared as date to store values of date to sheet. So first from textbox to variable and back to sheet.

When you enter a new value there will be added a line. If you alter a line (record) that was searched for, the line will be updated.

Charlize

christoday
01-30-2007, 12:30 PM
Thanks very much for this excellent advice. Thanks, Charlize, for coding your help onto my form- it works excellently. I'll amend the code further to take on board your dates advice. The problem metioned in the first two posts was due to the "Default" property of the CmdOK buton being set to "true" and was avoided by setting it to "false" instead.

Thanks for solving!

mdmackillop
01-30-2007, 01:20 PM
The problem metioned in the first two posts was due to the "Default" property of the CmdOK buton being set to "true" and was avoided by setting it to "false" instead.
Thanks for the info.