Cart    Contact Us    Tutorials    Downloads    About Us    News

MDE to MDB Conversion Service
(plus ACCDE to ACCDB Conversion)

- convert compiled Access files back to their original formats including VBA code

Database Repair Service

- a trusted service for repairing corrupt Microsoft Access files

vbWatchdog   [Code Library]

- global error handling library for VBA & VB6 projects

vbMAPI   [Code Library]

- Outlook/MAPI library for VBA, .NET and C# projects

Code Protector   [Software]

- strengthens protection against reverse engineering of MDE/ACCDE files


A new method for disabling the Mouse Scroll Wheel in Access forms

        83 votes: *****      84,390 views      91 comments
by Wayne Phillips, 12 August 2009    (Access 97+)
- without needing a DLL and without VBA subclassing

Download Demonstration MDB (Access 2000+) (Zipped)
Download Demonstration MDB (Access 97) (Zipped)

 UPDATE v1.3: 29/08/2009 -- Improved VBA loader code - now supports VBA5 and VBA6.
 UPDATE v1.4: 01/09/2009 -- Scroll wheel now disabled by default, for convenience.
 UPDATE v1.5: 04/12/2009 -- now the Init and Scroll object methods are case insensitive (fixes potential "Object does not support..." errors)

This solution is being provided for free and you can use this solution in your applications freely provided you leave the copyright notices in place in the source code.

- The problem
- The old solutions
- The new solution
- Instructions for use
- How this works -- Warning, quite technical!

The problem

In Access versions prior to v2007, when you use the mouse scroll wheel on a form, Access will always cycle through the current records in your forms dataset. This is quite an annoyance when you might not want this behaviour, and Microsoft never offered a simple solution to turn this feature off (until v2007).

The old solutions

There have been several solutions to this over the years, including;

  1. A DLL based solution (such as MouseWheelOnOff by Stephen Lebans)
  2. A VBA subclassing solution (as described here)

There are other solutions such as forcing the currently displayed record to always be in edit mode, but we won't discuss them here - they have their own drawbacks too.

Each of these current solutions have drawbacks to them

For #1, you need to distribute a DLL alongside your product.

For #2, as discussed in the Microsoft KB article, the VBA subclassing solution is not advisable due to problems that can occur if the VBE window is open. Also, your forms will take a performance hit since every window message goes through the relatively inefficient VBA subsystem.

The new solution

My solution is to use the subclassing method as described in the VBA article above, but rather than use a VBA subroutine as the callback procedure, I use a native machine code compiled procedure (read the technical stuff below if you want to understand how this is achieved). The result is extremely efficient and best of all: there is no DLL to re-distribute - the whole functionality is implemented in a single VBA module.

This solution is being provided for free and you can use this solution in your applications freely provided you leave the copyright notices in place in the source code.

Instructions for use

  1. Import the code module basMouseHook into your database application from the demonstration database: Access 2000 version - Access 97 version.

  2. From within your forms OnOpen event, add this simple code:

    Private Sub Form_Open(Cancel As Integer)
         Static MouseHook As Object
         Set MouseHook = NewMouseHook(Me)
    End Sub

To show your appreciation, and to enable us to spend more time writing solutions like this, please consider donating a small amount through PayPal:

And that's all you need to know to make use of this new technique. Hopefully some of you will find this new method useful - if you do, feel free to leave your comments at the end of the article.

If you want further details on how the basMouseHook VBA module works... read on.

How this works -- Warning, quite technical!

VBA allows us, with the help of the RtlMoveMemory API call, to cast any numeric value into a VBA variable. So for instance, we can cast a Long integer into an Object variable, if we so wish. Ordinarily by doing this you will cause an instant crash since VBA expects the Object variable to contain a pointer to a valid in-memory COM object, and so will attempt to call the QueryInterface / AddRef / Release methods of the COM IUnknown interface when attempting to do anything at all with the variable.

However, if we setup an area of memory that replicates the layout, interfaces and machine code that VBA expects to find in an Object variable and then cast a pointer to that in-memory object into an Object variable, then VBA will treat our Object as any ordinary COM object.

This approach has several issues that have to be addressed:

  1. We need a way of setting up that area of memory correctly, including all the normal things that COM objects need - i.e. the actual native machine code, VTables and their pointers for all of the interfaces we support, and associated data sections.
  2. Adjusting absolute memory addresses at runtime.
  3. Native machine code written in-memory like this has no way of interacting with the Operating System by default since it has no "handles" to any DLL libraries - it is just pure x86 machine code. So at first we have no method to call any APIs ... so we're quite limited in what we can offer. Fortunately this can be solved.

To solve #1 and #2

The approach I use is to have a "loader" or "shell code" which is written in pure assembly using only x86 opcodes that fall into the ASCII character set (so that we can reliably contain this machine code within a String variable in VBA). The loader code will be instantiated by VBA on it's first call to IUnknown::QueryInterface on our object.

The loader code is responsible for setting up the area of memory for our COM-compatible object and for adjusting the absolute memory/pointer offsets before finally calling IUnknown::QueryInterface. The machine code that our object uses is encoded with a Base64-style encoding, which is also decoded by our loader on the first call to IUnknown:QueryInterface - this allows us full freedom to use all x86 opcodes once the loader has done its job.

To solve #3

The solution I use is to pass a handle to the kernel32 library and a pointer to the GetProcAddress API function from VBA to our COM object via a Init() method call. Once our COM object has the kernel32 handle and can call the GetProcAddress function, it can then call any other API functions at its discretion.

So there you go - a little insider info into how this technique all works. No doubt some people will call this approach a "hack", but to me this is just a "new technique" - the end result is a perfectly valid COM-compatible object created in memory dynamically from VBA code.


Regards,

Wayne Phillips
http://www.everythingaccess.com


<< Back to tutorials index





Rate this article:   Your rating: Poor Your rating: Not so good Your rating: Average Your rating: Good Your rating: Excellent

Have your say - comment on this article.

What did you think of 'A new method for disabling the Mouse Scroll Wheel in Access forms'?


1.

Alan Cossey says...

12 August 2009

 
Lovely bit of work and perfect timing for me too to produce it now as it will save me from having to distribute a dll with some work.

2.

AcoustiMan says...

13 August 2009

 
Hi Wayne,
impressive example of software engineering! I was seachin a long time for a working solution. I'm gonna try your solution right away.
Thank you very much! Keep up the great work.
Regards,
Julien

3.

Bruce Jonson says...

13 August 2009

 
Awesome work! I have always used Stephan's DLL solution but this will be a great replacement.

Thanks for this great piece of code

4.

Wayne Phillips says...

14 August 2009

 
Thanks everyone! I'm glad it's of use to you!

Check back soon for some other products using this new in-memory native-code Objects technique.

5.

Dan Waters says...

22 August 2009

 
Excellent!

My Customers and I thank you!!

Dan

6.

Jaafar tribak says...

24 August 2009

 
Great technique !

I have adapted the code to work for excel worksheets and worked beautifully.

Can you apply this technique to other events such as Mouse Clicks, Keystrokes etc ... ?

Regards.

7.

Wayne Phillips says...

24 August 2009

 
Thanks for the info Jaafar - great to know it works in Excel too.

With regard to the second part of your comment -- in particular, what were you looking to achieve? Pretty much anything is possible with this technique, although I'm not as familiar with Excel as I am with Access, so I am unsure as to what limitations you might be trying to overcome.

Regards,
Wayne

8.

Jaafar tribak says...

25 August 2009

 
Thanks for responding Wayne.

I am not as familiar with Access as with Excel but I guess subclassing the 2 applications should be similar.

As you may know subclassing office applications directly in VBA without resorting to a DLL can be problematique (potential crashing). The technique you have used here seems to overcome this issue by using machine code.

My question is : Can one use this same technique to intercept other window messages directed to access or excel other than the WM_MOUSEWHEEL msg ? that would be really amazing .

Again. Thank you

9.

Wayne Phillips says...

25 August 2009

 
Hi Jaafar,

Indeed, it is technically possible to intercept any of the windows messages using the same technique with very little to change to the code at my end.

So, what specific limitation in Excel do you want to apply this technique for? For example, we can intercept mouse clicks and key strokes messages using this technique, but it would be of limited use in Access since we have form events for those messages anyway -- so I'd like to know what limitation in Excel you would like to use this technique on, then perhaps I can provide a solution for you.

Kind regards,
Wayne

10.

Jaafar tribak says...

26 August 2009

 
Thanks Wayne.

As you may know there is no event associated with scrolling excel worksheets. I have managed to intercept the scrolling msg via subclassing before but as i mentioned in my previous post, this is potentially dangerous at best and under some OS like Win XP SP3 the whole application frezes(works on SP2 though).

So my goal is to have some code that will safely prevent scrolling the active worksheet past Row(50) for example. Obviously using this new thecnique.

I guess the core of the code you provided that disables the Mousewheel is hardcoded in the "NativeCode" string. Would adapting this approach to meet other needs mean having to learn machine code ? and If so, where can i learn it ?

Regards.

11.

Wayne Phillips says...

26 August 2009

 
Hi Jafaar,

Unfortunately it's not as simple as just learning machine code, since there are many more hurdles that you need to overcome (as discussed in the article) before you eventually get down to the NativeCode string used by this technique.

If you can provide me with an Excel spreadsheet (to myname@everythingaccess.com) that demonstrates what you'd like the NativeCode to do (i.e. an Excel file containing your VBA subclassing code), then I'll see what I can do for you.

Regards,
Wayne

12.

Kurt says...

28 August 2009

 
Wayne,

thanks for this great tool, superb.

Kurt

13.

Alyssia says...

28 August 2009

 
Great tool! Thanks for sharing

14.

Dennis Thomas says...

28 August 2009

 
Our company still uses Access 97; does this code work with that version as well? I am currently using Stephan's DLL where you must place the Mouse Hook DLL in the affected directory. Not successful for all users on our shared server drive.

If you have your version working in Access 97 I would appreciate gaining access to it.

Thanks

15.

Wayne Phillips says...

28 August 2009

 
Dennis,

I've just updated the article to include a link to an Access 97 .MDB file as well. I had to adjust the routines slightly in order to work around the way that VBA5 doesn't allow one to coerse COM interfaces to an Object variable, yet VBA6 does. The updated routine now works in both VBA5 and VBA6, so I've also changed the Access 2000 version to match.

Do please let me know how you get on with it.

Regards,
Wayne

16.

Dennis Thomas says...

28 August 2009

 
Thank you very much for the Access 97 code. It works very well.

17.

beth says...

31 August 2009

 
Thank you for the code! How can I make the "disabled scroll" the default?

18.

Wayne Phillips says...

01 September 2009

 
Hi Beth,

Please follow the instructions in the article section titled "Instructions for use", which shows you how to do that.

Regards,
Wayne

19.

Neil Sargent says...

01 September 2009

 
Wow, what a fantastic fix to a long standing problem!

I believe that many people will want to simply disable the mouse wheel and will not need switch scolling on and off.

Therefore, I recommend that the scrolling is disabled by default in the NewMouseHook procedure with the final line

NewMouseHook.Scroll = False

It is then possible to disable the mouse wheel for a form with the following single insertion of code in the Form_Open() or Form_Load() events:

Static MouseHook As Object
Set MouseHook = NewMouseHook(Me)


20.

Wayne Phillips says...

01 September 2009

 
Hi Neil,

Thanks - excellent suggestions.

I've now updated the VBA module so that the Scroll property is now False by default, as you suggested. I've also updated the article to make use of the Static local variable rather than the module level variable -- another great suggestion.

Again -- many thanks for your input!

21.

Dave H says...

16 September 2009

 
Finally, a great solution with no DLL hell!

My prior solution was the MouseWheel.dll. It worked great on a single form. Issues arose when users navigated from a detail form (single record) to as list form, then on to another detail form. The DLL prevented the mouse from scrolling records, but also locked up all mouse events on the first detail form when you navigated back. Too many object calls on the stack making the mouse event processing freeze.

Your solution works as intended. Thanks!

22.

Ken says...

29 September 2009

 
This is really nice. I'd love more info on how you came about creating the string of native code though. Did you write code in assembly or did you convert it from something else. I'm aware that you can convert the .net MSIL code to native machine code but I just have vague ideas.

23.

Wayne Phillips says...

29 September 2009

 
Hi Ken,

To give a little more info;

The native code string is actually generated from a custom compiler that I wrote - it's essentially a mix of assembly and C++, but generates an assembled code block that is completely self contained.

Just in case you're thinking that I'm a bit mad going to the expense of writing a compiler just for this mouse hook routine... indeed that was certainly not the primary reason ;-)... there's something much larger, and much more useful that I'm working on!

(... to be continued...)

24.

Alicia H says...

29 September 2009

 
It works beautifully. Thanks for this simple solution.

25.

Wayne Phillips says...

30 September 2009

 
You're welcome, Alicia. Thanks for your feedback :)

26.

--=Franky=-- says...

06 October 2009

 
thx a lot for it.
I understand nothing about the Code but it works well :-)

27.

Leah says...

06 October 2009

 
Worked like a charm! THANK YOU! Tried to use the other methods, but this one worked the best and it is much, much easier to use!

28.

Dawie Poolman says...

07 October 2009

 
Hi Wayne
This is a phenomenal piece of work. It can potentially solve a long standing issue in Excel with embedded list boxes that crashes Excel when you try and scroll in them. See the Forum below (one of many out there)
http://www.xtremevbtalk.com/archive/index.php/t-226433.html

Please share with if you believe that would be possible? Just need a handle on the listbox first?
Regards
Dawie

29.

Wayne Phillips says...

07 October 2009

 
Leah & Franky… thanks for your kind words. You're welcome.

Dawie, can you provide a simple Excel file demonstrating the issue? (e-mail <MyFirstName>@everythingaccess.com) It certainly sounds as if it is something that could be solvable in the same manner, so If I think it will help, I'll certainly try.

30.

Wayne Phillips says...

08 October 2009

 
Dewie,

Please find the solution to the Excel ListBox crash issue, using the same technique to the Excel file you sent me, here:

http://www.everythingaccess.com/downloads/ExcelListBoxMouseHookExample.zip

HTH,
Wayne

31.

Dawie Poolman says...

08 October 2009

 
Wayne
Your incorporation of this solution to Excel's listbox scroll crash issue is THE neatest solution that I have seen in a long time. You should let Bill Gates know about how you are fixing his bugs :-)

Awesome, brilliant, innovative, old school hacking solution.
Hats off and respect!

32.

Wayne Phillips says...

08 October 2009

 
You're welcome, Dewie, and thanks :)

33.

anthony mosco says...

16 October 2009

 
This is the best solution to this problem that I have found in the last year. Implemented another version and was fine until an upgrade was performed on my XP, and the old method was producing odd breakpoints that were not set.

This is so much easier and your work on this is greatly appreciated, as I had to change the call to 10 different complex forms, and had one small piece to replace code in several places!

34.

Wayne Phillips says...

19 October 2009

 
I keep getting asked "what is it that you're working on" with regards to my earlier teasers... so here's a snippet to whet your appetite:

Think "flexible data grid control" and you aren't far wrong.

Using the native assembly technique shown in this article ultimately means that you get a new control without needing any third party DLL.

Key Features;

Supports tree views and list views natively.
Supports live grouping and sorting.
Supports HTML cells (including hyperlinks)
Supports in-built cell controls such as buttons, check boxes, combo boxes.
Supports many different data sources (including SQL/Recordset, optimized internal lists/trees, "on-demand" using VBA callback, and more)
Supports unlimited conditional formatting throughout using a built-in expression compiler for optimal performance.
Supports complex expressions in conditional formatting and for cell sources.
Supports conditional formatting for all available cell properties (not just simple Bold/Underline options like Access).
Supports auto-fit cell widths and/or item heights.
Supports variable item heights.
Supports images / pictures with a variety of transparency options (even for bitmaps).
Supports several gradient options for background fills (for cells and master control).
Supports changing the opacity of fills, allowing for a modern "bleed-through" effect.
Supports rounded corners for items and groups.
Supports the concept of bindings and expressions for all conditional formatting options. For example you can easily bind the background fill color to a field in your datasource, if you wanted to.
Supports conditional formatting inheritence (conditional formatting can be set on each display column and can inherit from a "master" defaults class)
Supports drag 'n' drop.
Supports multi-select.

Sounds interesting? If you would like to be a part of the beta team, please e-mail me now. Beta is starting very soon!

beta@everythingaccess.com

I can only offer a limited number of people to participate in the beta, so please let me know ASAP if you are interested.

Wayne Phillips

35.

Ingo says...

20 October 2009

 
Perfect - it is simple and works!
Thanks a lot - you helped me :-)
Regards

36.

Steve says...

02 November 2009

 
WOW WOW HOLY COW WOW!!!

Sorry for the excitement but after spending months developing a new form for data entry that help calculate the time needed to process a job, it all came to a crashing halt when the test users hit the scroll wheel. It cycled thru records that did not exist and royally messed thing up.

I tried the "Old" solution but it just crashes my application.

Wayne this solution has saved me from having to rewrite my application. Thanks a million and what a great simple fix to a terrible problem.

Steve

37.

Mark says...

12 November 2009

 
This solution makes so much crazy work-arounds obsolete :)
Simply great!

Thanks,
Mark

38.

Enia Rrolyu says...

17 November 2009

 
i found microsoft script for disabling mouse wheel so annoying. everytime i need to update vba code behind the form, i would have to close and re-open otherwise it would hang. so annoying!

thanks so much wayne for this. big help!!

39.

Jonny Moir says...

18 November 2009

 
Nice concept and I like where you're going with it. With a bunch of work this could lead to controls creating their own reference support rather dynamically. Imagine that instead of having bulky linked DLLs with potentially useless sections, a skilled programmer could design their own slim COM-compatible support for their own controls dynamically. But I'm dreaming now...

Anywho, congrats on this. This beats the hell out of my solution which was to store the MouseHook.DLL in a common share and point the module to look for it in that location so as not to have to distribute extra files.

40.

Wayne Phillips says...

19 November 2009

 
Thanks to all for the kind comments.

Jonny:

Indeed, custom controls that require no extra references, is where I'm heading with this technique. Firstly it will be controls designed by me, but then later I might just release the compiler too... so maybe your dream might just come true ;)

All: please keep the beta request e-mails coming in (see post #34 above). Beta testing starting very soon.

41.

Matt Hawke says...

16 December 2009

 
Worked flawlessly with Access 2003 - I just dropped in the module and made the call as specified above. A brilliant, no-nonsense workaround for a terribly frustrating issue.

Thanks Wayne for making your work available for all to use!

42.

Sadaf says...

30 December 2009

 
Perfect...

Thank you

43.

Ralf Lepelmann says...

11 January 2010

 
Greetings from Germany

It works great!!! I'm enthusiastic! Thank you ...

44.

Michael says...

12 January 2010

 
F A N T A S T I C.
I have been using Lebans solution for a while but found it didn't work perfectly. Your solution appears to do the trick.

Thank you

45.

Kate says...

10 February 2010

 
Thank you so much! Very simple to implement, really appreciated by a beginner!

46.

Greg says...

11 February 2010

 
This is a great solution to the problem. In today's world rarely can I actually find something that works!

Thank you very much.

47.

solyluna says...

25 February 2010

 
Thank you so much!! Great!

48.

Jacron says...

05 March 2010

 
Beautiful. Just _beautiful_. Simple, easy to use, works across computers with no hassle. Very well done to you, sir.

49.

alan honorio says...

11 March 2010

 
many thanks for this, it really works great!!!

50.

Tomolena says...

10 April 2010

 
Magnificent bit of work Wayne. Stumbled upon your solution at utteraccess.com. I too have been using Mr. Lebans' solution for years. Worked perfectly for me, but always having to include the required DLL file with my apps is a bit cumbersome. You've provided the Access community with something that's neat, reliable, and very useful. Thankyou for sharing and CONGRADULATIONS on this.

51.

Wayne says...

10 April 2010

 
Thanks for your kind words, Tomolena. :)

52.

Tom van Stiphout says...

08 May 2010

 
Very interesting technique. When I started reading I figured you would have gotten the in-memory object using a debugger - if you know where to look you can find them, and then convert to string. That would have given me some hope I could adopt your technique to my issue, which is to subclass a window and process WM_PAINT. Since your compiler is private I will resort to the Lebans technique.
Hats of for a great and creative solution. You're going places.

53.

Wayne says...

08 May 2010

 
Thanks for your kind words, Tom.

Let me know if the Lebans solution doesn't work out for you -- perhaps I can implement something for you...

Cheers,

Wayne

54.

Oli says...

26 May 2010

 
Thank you so much for this solution that took me not even a minute to implement into my database. I found it via Google after a while of search.

55.

Paul says...

02 June 2010

 
Thanks, works perfectly!

56.

Peter says...

22 June 2010

 
Thanks so much for this code. I don't understand the details of how it works, but the thing is - IT WORKS, and oh so easy to use. Very clever!

57.

Ken Goonan says...

23 July 2010

 
Wayne,

A nice piece of work. I am glad I found it.

58.

0 says...

30 July 2010

 
Thanks, that Code work well.
genau das was ich brauche.

59.

Steve says...

06 August 2010

 
Brilliant works for me.

60.

Michael says...

08 September 2010

 
Thank you Wayne

I tried the other solutions before I got to your... waste of time. Some of them stopped the mouse working on tabed subforms. Others locked up access whenever the code window was opened... what a mess.

But your solution is perfect. Thanks again, it is in my gems locker.

Mike

61.

Darren says...

13 September 2010

 
Thankful you exist and that you came up with such a great solution. I'm creating a small database that holds medical information related to congestive heart failure patients. The scroll featured save this project because we can't have any errors in patient record data entry

62.

Lilli says...

27 September 2010

 
Thank you!!!!
I owe you.

Und nun in Deutsch... :-)
Eine ganz tolle Lösung für die Probleme, die Microsoft uns macht.

63.

Joe r says...

03 October 2010

 
Hi wayne,

i have no words to thank you enough for beeing so kind and share this solution with the public.
I lost 1 customer (and probebly more) due to the problem with the mosue scrolling through records

Congratulations for a fantastic job!
GD bless you


64.

adams says...

11 October 2010

 
it is simple and easy to do. I try to use it in my database

65.

Davide Dona' says...

11 October 2010

 
From Italy, Thank you very much Wayne!
A simple solution to an annoying problem.
Ciao
Davide

66.

Wayne says...

03 November 2010

 
Those interested in the native code techniques used in this article, should also check out our other products that make further use of the technique:


67.

Alex says...

04 November 2010

 
This is just best solution ever!
Thank you very much for your scripts.

my problem were that i embeded web browser within the ms-access form, and while i dont want form to jump over the records i still want user to scroll web pages inside the form - and this works flawesly
thank you again!

68.

jake says...

21 December 2010

 
awesome, thanks

69.

Jenny says...

28 December 2010

 
From New Zealand. This is magic!! It has been bugging me when users making project notes disappear from the screen while scrolling the mouse that highlights everything. Thank you so much Wayne. You are truly a genius.

70.

mcalex says...

10 January 2011

 
Good stuff Wayne!

As one of the few who do want to switch scrolling on and off, how do you enable this?

I tried Set Mousehook = Nothing to re-enable scrolling, but no joy.

71.

mcalex says...

10 January 2011

 
cancel my last message. Worked after shut-down; re-start. Thanx

72.

Willie says...

12 March 2011

 
do you know if it works in Citrix?

Thanks for all of your work

works great

73.

Sam says...

21 March 2011

 
Thanks a lot for sharing this solution. Worked like charm.

74.

Robert says...

25 March 2011

 
Thank you VERY much for this wonderful (and easy-to-use) solution! This has been a big problem for me over the years and with your solution I was able to deploy this fix within minutes. It works great and will prevent users from accidentally scrolling out of records without them being passed through my validation scripts. I will continue to look to your for valuable resources and gladly donate to your efforts.

75.

Wayne says...

25 March 2011

 
Many thanks for your feedback and donation, Robert :)

76.

Jay says...

17 April 2011

 
Wayne, thank you SO much for this solution! I generally don't donate for freeware but yours is so valuable to me that I did. Thanks again.

77.

Wayne says...

17 April 2011

 
You're welcome! Thank you very much, Jay :)

78.

Juergen says...

15 May 2011

 
Greetings from Germany,
hervoragende Arbeit!
Means, awesome work, thanks so lot!

79.

Scott says...

19 May 2011

 
Wayne, as so many people have already said, you're a genius and a saint for helping so many people out with your approach. Thank you so much for sharing it.

Is there any way possible I can obtain your compiler to generate my own native code? If not, can you point me to another one somewhere that will do this?

Highest Regards!
Scott

80.

Wayne says...

19 May 2011

 
Hi Scott,

Thank you for your kind words.

The NativeCode technique was designed by myself over a long period (several years of developing and tweaking), and is used in some of my commercial software products, giving me an advantage over the competition. In short; to generate the NativeCode is an extremely complex process and no ‘off-the-shelf’ compiler is going to be sufficient.

I have considered licensing the technology in one form or another, but I’m undecided on whether to go down this route just yet. I would of course be interested to hear from anyone that would be interested in licensing the technology, as I can then start to get an idea of whether it would be something worth doing.

Thanks!

Wayne

81.

Marlon says...

20 May 2011

 
Hey! A great module, but after upgrading my OS to 64 bit it does not work any more.
I already changed the function declarations setting the attribute "PtrSafe", but when calling the sub "CastToObject", it says incompatible types.
I think this is because of the different types of return the function VarPtr has in 64bit OS (LongPtr) in comparison to 32bit OS (Long).
Do you have a solution?
When I change the data type of the second attribute in CastToObject from Long to LongPtr, Access crashed... :(
Best regards and anyways thanks for a great piece of work!

82.

Wayne says...

20 May 2011

 
Hi Marlon,

The NativeCode in this particular module is 32-bit only. This shouldn't be a major problem since the 64-bit version of VBA only ships with Access 2010 x64, which shouldn't require this code anyway since Access 2007 and newer does not scroll through records with the mousewheel by default. So, you could simply avoid calling the routine altogether on the 64-bit edition of VBA by using conditional compilation.

If needed, I could certainly update the NativeCode to include both the 32-bit and 64-bit binaries (like I did for Accessing detailed file information provided by the Operating System), but I can't think of a good reason to do so as it shouldn't be needed for the purpose this was intended for.

Cheers,
Wayne

83.

Gaffi says...

22 August 2011

 
Excellent work. Your expertise should be highly lauded! I've used the previous examples in the past, and this is a nice, smooth process that is much simpler to implement.

84.

Zaki says...

25 November 2011

 
Thanks a lot Wayne for sharing this part of your greet work with us.

When looking the native code and its work, I have no doubt with your experience as a programmers.

Let me express our gratitude in Bahasa too: Terima kasih banyak untuk kodenya bro!

85.

Alex Dybenko says...

07 December 2012

 
Hi Wayne,
I save reference to MouseHook object in a collection, instead of private var, it works ok, but in windows 8 x64 it cause Access crash when i remove object from collection. Do you know how to avoid this? Your sample works ok, but i want to avoid adding private var to each forms.
Thanks
Alex

86.

Wayne says...

07 December 2012

 
Hi Alex,

I'd avoid adding the variable to a global collection because you need the variable to be released properly so that it un-hooks itself from the window. If it doesn't un-hook correctly, then you risk crashes.

A module scoped variable is required (or a static variable inside the Form_Open procedure itself).

-Wayne

87.

Mark Bovee says...

01 February 2013

 
After trying some .dll files that didn't work like they should I tried your code. It works perfectly out of the box! Many thanks for this!

88.

David Landy says...

24 February 2013

 
Awesome! The best solution so far, by far. :-)

I'm wondering... would you be interested in looking into the possibility of extending this solution to subclass Access forms more generically?

I'd particularly like to be able to send and receive custom windows messages in Access (to respond to various events) and I'm stuck with sending KeyUp or KeyDown events, which isn't exactly ideal.

I've tried subclassing using the Win32 API but everything I've tried so far has been temperamental and crashed and burned when I tried to debug in the IDE...

Really hoping you can help!

89.

Matheus says...

21 May 2013

 
Thank you so much bro! So many complexes solutions and just with a copy and paste you solved the problems of many people. Thank you!

90.

ali says...

11 June 2013

 
many thanks. Well done. Works

91.

M.Red says...

02 October 2013

 
Absolutely brilliant fix can you drop an email updating what you are currently working on.
Regards Malcolm

Have your say...

Name
E-mail (e-mail address will be kept private)
Comments
Verify Code
Verification Code
Please note: It may take 30 seconds after clicking submit - please be patient to avoid duplicate submissions.   All comments must be approved before being displayed on this web page.  This process may take up to 24 hours.


Site tools