Add values from a form

[datkid001]

How do you update a table using unbond fields in a form? I have several combo boxes that, once the user selects the desired value, passed to a table. Also is the event 'on double click' available for combo boxes and does it make sense to use that event.

Thanks

 

[Pat Hartman]

Working with bound forms is more complex than you realize. Access does a great deal for us behind the scenes when we use bound forms and all that functionality must be recreated manually by you when you use an unbound form. Notice I switched from "we" to "you". I recommend that you use bound forms, they are a real strength of Access. At some point in the future when you learn how to program, you can attempt an unbound form but there is no advantage to using unbound forms, only disadvantages.

If you feel the need to write code, switch to VB or C++.

 

[tanski811]

Using bound fields

How do you keep the mouse wheel button from scrolling to the next record if you use bounded fields vs. unbound fields.

 

[WayneRyan]

The Mouse Wheel Scroll problem is pretty common. I've never felt the need
to disable that capability, but apparently many people do. These threads
from the Search Facility here should help:

http://www.access-programmers.co.uk/forums/search.php?searchid=435630

As for unbound forms, I agree with Pat, they should be avoided at all costs.
Access (and JET) do an amazing amount of our work for us, that's the primary
strength of Access; rapid development of database applications.

If you pursue apps with unbound forms, you will:

1) Become much more proficient writing VBA code, rewriting all of Access's
record display & update logic.

2) Become very aware of how/when data is updated. Hopefully you won't
lose any as you learn how to develop the forms.

3) Become very aware of database performance. Especially if your form's
data sources are based on ADO Recordsets. And especially if your app runs
over a network.

Overall, I'd stay with bound forms, and seriously investigate some of the
threads above. An unbound form seems like a tremendous amount of your
labor ... just for a stupid mouse wheel.

I have no idea of the type of constraint that it would take for me to opt for
an unbound form.

Just some thoughts,
Wayne

 

[tanski811]

Jet46 Mouse Wheel Disabler

I used the code that Jet46 wrote for disabling the mouse wheel which works pretty well:

Private Enum wsTrigger
MyWheel = 1
NotTheWheel = 2
End Enum

Private mWheel As Boolean
Private ValidationTrigger As wsTrigger

Private Function WheelSpin() As Integer
WheelSpin = mWheel
Select Case ValidationTrigger
Case NotTheWheel
mWheel = False
End Select
End Function

Private Sub Form_MouseWheel(ByVal Page As Boolean, ByVal Count As Long)
On Error GoTo Sub_Err
mWheel = True
ValidationTrigger = MyWheel
Me.NoMouseWheel.SetFocus
Me.NoMouseWheel.Text = " "
Sub_Exit:
ValidationTrigger = NotTheWheel
Exit Sub
Sub_Err:
Resume Sub_Exit
End Sub


Now I don't have to use an unbound form. Thanks for your patience and suggestions.

 

[WayneRyan]

t,

Glad to hear it. That sure looks like a lot less code.

Wayne

 

[Sergeant]

The Mouse Wheel Scroll problem is pretty common. I've never felt the need to disable that capability...

Me neither. I haven't been doing this all that long, but I try to work by philosophy...
"Don't give the user any records that you don't want them to look at." So far, I have been successful with this approach.