my num lock keeps shutting itself off by itself can i stop this

The value was 2.

This is most annoying because when the num lock switches itself off and you type on it, the cursor jumps to another spot in your document.

Hi Celia, the registry fix provided in this thread is not intended to address the numlock key spontaneously toggling states. It is only intended to fix a situation where the numlock key is disabled at startup.

The problem you describe stems from a bug in Microsoft Office that Microsoft has been unable to fix and unwilling to provide a work around (for ten years *cough*). It may be triggered when running a macro enabled workbook, Access front end, or any other Office product/file. Frankly it's very hard to track down.

The easiest solution is to install a third party utility called NumLocker.

http://www.softpedia.com/get/System/System-Miscellaneous/NumLocker.shtml

Again, to anyone reading, there are two separate problems described in this thread.

1. The initial keyboard state; numlock is disabled at startup.
2. Numlock spontaneously toggles itself during normal use.

The former is corrected with the registry fix described at the front of the article (set InitialKeyboardIndicators = 2). The latter is corrected by identifying which macro-enabled Office file, VB front end, or other related application is triggering the state change, or by installing the handy NumLocker utility.

Folks, there are two unrelated issues here... 

Issue #1: The Num Lock key is disabled when you log into Windows.

This is an issue with the keyboard default state defined within the Registry.

1. Open Regedit.exe
2. Navigate to HKEY_USERS.DEFAULT\Control Panel\Keyboard
3. Modify InitialKeyboardIndicators and change this to 2 or 214783650. (The default value will be 0 or 214783648).

Issue #2: The Num Lock key disables in the middle of your session.

This is a known bug within the .NET framework that toggles the NumLock state when executing multiple SendKey statements. It is likely that some software you are running is triggering the issue without your awareness. In our case we had a VB front-end to an Access database that was triggering the bug during a text fill procedure on a listbox control. Unless you have code-level access to the program in question you will need to download a service that continuously obtains the state of the Num Lock key and enables it if it is ever disabled. 

1. Download the NumLocker Windows service. You can find it on SoftPedia or any number of other share sites.
2. Configure the NumLocker service to always maintain the Num Lock state.  Until Microsoft addresses the issue (also read as 'never') with .NET then you will need to use a service like this.

As an update, I now believe the issue is chiefly related to "SendKeys" macros as events in Microsoft Access fires them. I am trying to come up with programming alternatives to SendKeys which is so intuitive and usefull to novices like me, but apparantly is regarded by many as "unreiable", which implies random variability which I find hard to square with determinstic computers, but what do I know? Not much or I wouldn't be on this forum.

This has also been causing me issues for over a year....and I've finally found a fix. I've been developing in Access since v. 1.0 in the early 90's...so I had a lot of legacy code that was translated to new versions as they became available. I was still using the 'A_NORMAL' and 'A_PREVIEW' (and other) command line switches and they compiled in Access 2010 without error. While trying (yet again) to solve the numlock problem, I updated the command line switches throughout my code to the current acNormal, acPreview (and others) and the numlock issue was gone.

I had also experienced issues with the sendkeys functions (in particular sendkeys "PGUP") and when I had eliminated the use of those, it had solved some of my numlock problems, but not all. Once I updated the command line switches, this solved them all.

I hope this helps someone.

Cheers,

Jeff