faster scrolling records

[chewy]

I made my own record selecting buttons but you have to select each record one at a time and I dont want scroll bars. Is there a way to made the buttons faster when you hold it down?

 

[Newman]

I don't think so... But one thing that could be done, is a combobox that searches for a selected record. Let say that you make a combobox with the customers name. The user looks through the list and choose the one he needs. When he clicks on the one he chose, the form shows the record chosen.
It can be done pretty easily with the combobox wizard.
If that option is good for you, I could give you a hand to do it if needed.

 

[jjturner]

Pardon the lack of illustration (fading-out fast tonight):

I would think that if you have a Timer function placed in your MouseDown Event for the Navigation buttons, then once the Mouse button is held down for the desired length of time you could begin looping through the Move... command, interspersing the DoEvents command to let the code 'catch its breath' before racing through to the next record.

There must be some other posts dealing with this, as I've always thought that this type of turbo-Navigation from the default Navigation controls shouldn't be too difficult to duplicate.

(If no one posts up the explicit solution, I'll try and cook it up and post this w/e)

HTH,
John

 

[chewy]

i vaguely understand what you mean, but wouldnt know how to implement

 

[chewy]

I have this but this just skipps records even if you let go of the button

Private Sub cmdNext_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)

X = 0

While X < 10
DoCmd.GoToRecord , , acNext
X = X + 1
Wend
End Sub

not quite what I want though

 

[chewy]

jturner,

I was wondering if you were able to get that example? I really cant figure what to do

 

[jjturner]

chewy,

This one turned out to be much more involved than I thought. As you discovered, setting a loop in MouseDown will never trigger a cutoff since it can't test for MouseUp.

I'm thinking this could be circumvented through the use of API calls, but that would be throwing myself into uncharted waters.

I'll post back if and when I manage to find the solution.

Regards,
John

 

[jjturner]

chewy,

Check out this thread

As you'll see, the example uses a reference to the Microsoft Forms 2.0 ActiveX controls to let you use Spin Buttons on your form. As the example demonstrates, this works like a charm.

Regards,
John

 

[chewy]

thats what I am looking for but am not able to figure out how to apply it to my DB. Anyone care to help?

 

[jjturner]

1) Check to see if Microsoft Forms 2.0 is listed in your References (you have to check under Tools menu when you're in a Code Module)

2) If not, then you'll have to find the associated .dll file (FM20.dll) in your Windows directory and Register it by going into ActiveX Controls in your Tools menu. You'll find the path in the dialog box when you select 'Microsoft Forms 2.0' in the ActiveX list.

3) Once Microsoft Forms 2.0 Spin Buttons gets added as a Reference in your db, you can use Spin Button controls in your forms.

HTH,
John

 

[chewy]

im sorry...I had it in the db already but could not make heads or tails of how to implement

 

[jjturner]

DOH!

After taking a closer look at the Spin Button solution, turns out that was a red herring (even though the result does work effectively).

The trick in the example is to use Unbound controls and open a Clone of the form's Recordset, assigning values of each subsequent record in the 'Clone' to the Unbound controls for each firing of the Spin Button 'Update' event.

I'm still looking into a better solution by using API calls. Will keep you updated.

Regards,
John

 

[Mile-O]

I found this on another site.


TurboScroll

 

[chewy]

link doesnt work

 

[Mile-O]

Whoops, forgot you need to be registered with that site.

Another Access Place

 

[chewy]

i couldn figure how to do that. But I went a different approach i works but not exactly the way I want it to.

Private Sub cmdNext_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)
DoCmd.GoToRecord , , acNext
End Sub

I use the mouse move...so as long as I am over the button it scrolls just like the real access record selections

I just had a brainstorm and tried to make a function to call this but couldnt get it to work


Private Function MouseMove() As String

Private Sub cmdNext_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)

DoCmd.GoToRecord , , acPrevious

End Function

Then I call on the next click evernt

Private Sub cmdNext_Click()
Dim mousemovedata As Variant
On Error GoTo Err_cmdNext_Click

mousemovedata = MouseMove()
'DoCmd.GoToRecord , , acNext

Exit_cmdNext_Click:
Exit Sub

Err_cmdNext_Click:
MsgBox Err.Description
Resume Exit_cmdNext_Click

End Sub


any ideas on how to refine this...it could be very benificial to a lot of people

 

[jjturner]

chewy,

One thing to understand (as we've all obviously confronted but not publicly acknowledged) is that Command Buttons native to a Bound form must 'reset'/'release' themselves upon moving off a particular record.

That means that by invoking the Click event and displaying a 'pressed-down' Command Button, Access can't move off the record until it gets visually 'released' back to its un-Clicked normal default state.

This is most obvious when you set the GoToRecord loop (infinite) in the Command Button's MouseDown event - it maniacally fluctuates between its 'de-pressed' state and its 'released/normal' state.

Realizing our limitation, we can deduce that when Mr. Gates and company developed Access, their built-in next/previous Navigation buttons were programmed to operate independently of the form's 'formatting' routines that run each time the Current record changes (i.e. - carrying over values in unbound controls to the Next record, and conversely loading the appropriate field values into bound controls for the relevant record).

An analogy to the built-in Nav buttons would be the {PageDown} and {PageUp} keys. Since holding down either of these keys doesn't visually impact a form's native Command Buttons, it doesn't interfere with the behind-the-scenes 'formatting' routines that Access carries out during Navigation, hence 'AutoRepeat' or 'record-cycling' is allowed for them.

The only 'true' solution that I can conceive of requires the use of API and is 2-fold:

1. Render the properties of a standard Command Button so that its 'Pressed' state is not evaluated or initialized by Access when moving off a record
2. Evaluate the state of the Left Mouse button (Up or Down) when triggered by a Click within the Command Button's boundaries[/list=1]I would offer the disclaimer that I've only just begun to get my feet wet in setting up API Declarations - total greenhorn as far as that goes.
   
   Again, I'll keep you posted if I make a breakthrough or someone should lend their expertise with API towards this endeavor. If you're still looking for a 'quick'/'trick' solution, you should revisit the example db's referenced in previous responses to this post - based on what I see from your own attempts, you should be able to grasp what it is they're doing and tailor to your own needs.
   
   Regards,
   John

 

[Oldsoftboss]

Another idea

Is there a way to repeatedly call the 'page up' and 'page down' buttons on the keyboard?
Holding these buttons down does what your after.
Dave

 

[Oldsoftboss]

Please ignore my last piece of dribble
After reading again I realise that John has already covered that
Going to bed now.......

 

[Oldsoftboss]

Hey Chewy, just found this whilst scrounging around. Not a record navigator, but the auto repeat works! Check the references but,
Dave