I am not saying it was because of upgrading to Webroot SecureAnywhere Essentials but I never noticed it prior. I read about the wireless keyboard issue but not wired. Just figured I would throw this out as a possibility?
OK - I have tried this with two different external Microsoft Keyboards.
1. I will be using my keyboard and bouncing between keys and keypad. I normally just use the DEL key on the KeyPad for the most part. All of a sudden, I will hit the DEL key and a period comes up as if it changed into NumLock mode. As a matter of fact, all the KeyPad keys work as they should as if I had it in NumLock Mode without the NumLock indicator being lit on keyboard. I tried hitting the NumLock key to get it back to normal but nothing changes - it is as though it is stuck in NumLock mode. I might add - when I do hit NumLock - the indicator will come on and when I hit it again - the NumLock indicator light goes out but it seems to still be in NumLock Mode.
2. I thought it was a tired keyboard so bought a new one (Microsoft Natural to Microsoft Keyboard Pro) and after a while - it does the same exact thing.
3. I changed USB ports with the same result after a little use.
4. I found that rebooting corrects the problem for a while. I also found that by putting my laptop into sleep mode and waking it up - clears the problem for a while.
5. I ran a complete virus scan, etc. - nothing found.
Now, if I just ignore it for an hour or so the Keypad will start working properly - could it be Webroot is hitting the server's and updating? I am at a loss.
Page 2 / 3
I found the solution - I completely removed WebRoot from three systems, cancelled my automatic renewal and moved to another product. It is apparent to me that WebRoot feels (IMHO) that their aren't enough complaints from the community to take this problem seriously. Oh well - great product - but why should I spend my money on a product that hinder's my experience. Best of luck - I am sure they will figure something out someday. Yes, I sound upset - I am!
It comes down to the basic but extremely sad fact that the protection offered by the Identity Shield cannot operate without making an arbitrary choice about the state of the Num Lock function. Windows itself does not provide (or specifically programmatically expose) the needed functionality to do otherwise.
It is in no way a matter of not wanting to take the issue seriously, nor that there are "not enough complaints". It's just not physically possible to "fix" because it's technically not our bug. Trying to fix it is as programmatically impossible as trying to help people with a complaint that Webroot has a file on the computer. Can't run a program without a file. Can't detect the desired state of the Num Lock because Windows refuses to tell us.
Since Windows doesn't say what the Num Lock state is reliably, we have to make an educated guess. The default setting on the vast majority of PCs is for the num lock to be on when the computer is started up, so we default to on. With Laptops, we had a manner by which to detect that it's a laptop and thus trigger it off by default so the function-based number pad wouldn't make it impossible to type things in "iopjklnm,", but even that is not a perfect solution as a tremendous number of laptop keyboards are starting to have segregated number pads these days. Definitely better than having "poll" come out as "9855" though.
In Technical terms:
A program can ask Windows whether the Num Lock is on. It will tell the truth (or tell us at all) about 75% of the time. As such, a program that is a keyboard filter needs to make an arbitrary decision about the num lock state. Since the vast majority use num lock active, that is the decision that was made, except in cases where the computer is very obviously a laptop. Even something that seems simple like detecting an external keypad is not a simple thing programmatically and given how many people use external numeric keypads to enter numbers, forcing it off based on detecting one would make more people upset than happy.
Unfortunately, as I said before, nothing will be perfect. In all cases, you need to make the decision that is best for you and has the least downsides for your specific situation. From our perspective, we would invariably fix it if it were physically possible for it to be fixed. We don't look at things based on how many people are complaining. We do, however, look at things based on the overall best effect. Sadly, in this case "fixing" it for a handful of folks would leave millions of other people unprotected.
The workaround of either turning off the ID shield or setting programs within it from Protect to Allow still exists. Then at that point it's up to the individual to decide whether the ID shield functionality is a critical part of the software as a whole for their use. We have thousands of customers who don't care about the ID Shield portion and disable it but still very happily use the rest of the software because going to something else sucks more than having the ID shield disabled. They just figured that with something else, they'd not have a working ID shield or similar functionality, but they'd also be using a lot more resources, waiting for longer scans, and dealing with companies that don't care about things they -could- fix rather than not being able to fix something that isn't possible to fix. When they realize that they lose the ID Shield functionality regardless of whether they use Webroot with it disabled or somebody else, but they lose a lot more other stuff as well when they use something else, they generally choose to keep Webroot because its imperfections are less imperfect. *Shrug*
So, vpnavy, sad to see you go. A lot of people would say that you threw out the baby with the bathwater, but as I said, it's all about making the decision that is best for you. Since we already know that nothing else works the same way as the ID Shield does, we know you didn't get something else that has a working ID shield feature. I suspect that you have thrown it out because of a misimpression that we don't care, which I assure you is nothing even vaguely close to the case (I'm QA for Web. I don't have enough time in a 40-hour work week to do all my normal work, yet I still take the time to give a thorough explanation here). Even a bit of research on Google confirms in numerous locations that it's impossible to always accurately read the Num Lock state from Windows. If there was any way - by hook, crook, or whacking Windows - that we could change this, we would. As long as it doesn't reduce protection for everybody. But this is just a case where Windows itself provides zero solution.
It is in no way a matter of not wanting to take the issue seriously, nor that there are "not enough complaints". It's just not physically possible to "fix" because it's technically not our bug. Trying to fix it is as programmatically impossible as trying to help people with a complaint that Webroot has a file on the computer. Can't run a program without a file. Can't detect the desired state of the Num Lock because Windows refuses to tell us.
Since Windows doesn't say what the Num Lock state is reliably, we have to make an educated guess. The default setting on the vast majority of PCs is for the num lock to be on when the computer is started up, so we default to on. With Laptops, we had a manner by which to detect that it's a laptop and thus trigger it off by default so the function-based number pad wouldn't make it impossible to type things in "iopjklnm,", but even that is not a perfect solution as a tremendous number of laptop keyboards are starting to have segregated number pads these days. Definitely better than having "poll" come out as "9855" though.
In Technical terms:
A program can ask Windows whether the Num Lock is on. It will tell the truth (or tell us at all) about 75% of the time. As such, a program that is a keyboard filter needs to make an arbitrary decision about the num lock state. Since the vast majority use num lock active, that is the decision that was made, except in cases where the computer is very obviously a laptop. Even something that seems simple like detecting an external keypad is not a simple thing programmatically and given how many people use external numeric keypads to enter numbers, forcing it off based on detecting one would make more people upset than happy.
Unfortunately, as I said before, nothing will be perfect. In all cases, you need to make the decision that is best for you and has the least downsides for your specific situation. From our perspective, we would invariably fix it if it were physically possible for it to be fixed. We don't look at things based on how many people are complaining. We do, however, look at things based on the overall best effect. Sadly, in this case "fixing" it for a handful of folks would leave millions of other people unprotected.
The workaround of either turning off the ID shield or setting programs within it from Protect to Allow still exists. Then at that point it's up to the individual to decide whether the ID shield functionality is a critical part of the software as a whole for their use. We have thousands of customers who don't care about the ID Shield portion and disable it but still very happily use the rest of the software because going to something else sucks more than having the ID shield disabled. They just figured that with something else, they'd not have a working ID shield or similar functionality, but they'd also be using a lot more resources, waiting for longer scans, and dealing with companies that don't care about things they -could- fix rather than not being able to fix something that isn't possible to fix. When they realize that they lose the ID Shield functionality regardless of whether they use Webroot with it disabled or somebody else, but they lose a lot more other stuff as well when they use something else, they generally choose to keep Webroot because its imperfections are less imperfect. *Shrug*
So, vpnavy, sad to see you go. A lot of people would say that you threw out the baby with the bathwater, but as I said, it's all about making the decision that is best for you. Since we already know that nothing else works the same way as the ID Shield does, we know you didn't get something else that has a working ID shield feature. I suspect that you have thrown it out because of a misimpression that we don't care, which I assure you is nothing even vaguely close to the case (I'm QA for Web. I don't have enough time in a 40-hour work week to do all my normal work, yet I still take the time to give a thorough explanation here). Even a bit of research on Google confirms in numerous locations that it's impossible to always accurately read the Num Lock state from Windows. If there was any way - by hook, crook, or whacking Windows - that we could change this, we would. As long as it doesn't reduce protection for everybody. But this is just a case where Windows itself provides zero solution.
Kit, if windows won't tell you, why not put an option for users to tell you. This way I can just check that I prefer the num lock key to be off, and Webroot now knows my preference.
You could even ask that question during the install, and mention that you will default all browsers to this mode for security reasons.
You have a very serious issue here because of the fact when it happens to those of us always run with num locks off, we have no idea what is causing it.
It is not just an issue with Webroot not working right, you have essentially broken our computer on purpose without telling us, and we have no idea what is causing this issue.
I spent hours of wasted time searching Google for someone who had the same problem, never putting in the word Webroot because I had no idea Webroot was the source of the problem, and I never did find the answer.
Finally I started unloading programs one at a time, and after an hour or so of testing, I finally realized when I shut down Webroot my computer works right again.
So you see, this is much more serious than just a bug in Webroot, or something malfunctioning in Webroot, as a company Webroot has made a decision to break our computer, and not tell us they are doing so, thereby causing havoc and many hours wasted.
I hate to say it, but this is like a Trojan. A Trojan can be defined as a program that is supposed to be helpful that we download, only to find out it has actually harmed our computer. This is what Webroot has done.
You could even ask that question during the install, and mention that you will default all browsers to this mode for security reasons.
You have a very serious issue here because of the fact when it happens to those of us always run with num locks off, we have no idea what is causing it.
It is not just an issue with Webroot not working right, you have essentially broken our computer on purpose without telling us, and we have no idea what is causing this issue.
I spent hours of wasted time searching Google for someone who had the same problem, never putting in the word Webroot because I had no idea Webroot was the source of the problem, and I never did find the answer.
Finally I started unloading programs one at a time, and after an hour or so of testing, I finally realized when I shut down Webroot my computer works right again.
So you see, this is much more serious than just a bug in Webroot, or something malfunctioning in Webroot, as a company Webroot has made a decision to break our computer, and not tell us they are doing so, thereby causing havoc and many hours wasted.
I hate to say it, but this is like a Trojan. A Trojan can be defined as a program that is supposed to be helpful that we download, only to find out it has actually harmed our computer. This is what Webroot has done.
Trojans are generally things that intentionally do bad things. I'd consider this more of a rare side effect, kind of like medication. Otherwise Tylenol would be considered a "Trojan Drug" because I happen to have an adverse drug reaction to it and despite the fact that it's supposed to be helpful, if I take it I find out it harms me.
It's one of those tricky situations. The vast majority of people (and by that I mean literally in excess of 99.9%) default to Num Lock being turned on and never turn it off. Many don't even know what Num Lock is. For all of these folks, defaulting to Num Lock being on is a useful and appropriate thing. We exposed an option for people to select for an entire build before we reverted it. Two weeks with that choice and we got over 70 calls from confused people. So it was a fix for perhaps six, for example, and a "break" for 70.
That being said, we did just revise the manner in which the ID shield works and we have a different options set now as well as some additional functionality in other areas. We can definitely take a look at options there again. We can't always say that a given possibility will work and we sometimes have to point things out based on information we have, however we consider the community a very valuable source of ideas as well. Despite the fact that nearly everybody at the company uses the software at home* for personal use, we can't say that any of us have an external keypad that we want to keep Num Lock off on, for example.
We'll see what options we have now with changes to Windows and recent changes to our UI. As something that would be helpful, could you let us know what specific keypad you have? If we are able to look at the details of the hardware and drivers, that may potentially give more options as well.
(* Only nearly everybody because some of us use Linux.)
It's one of those tricky situations. The vast majority of people (and by that I mean literally in excess of 99.9%) default to Num Lock being turned on and never turn it off. Many don't even know what Num Lock is. For all of these folks, defaulting to Num Lock being on is a useful and appropriate thing. We exposed an option for people to select for an entire build before we reverted it. Two weeks with that choice and we got over 70 calls from confused people. So it was a fix for perhaps six, for example, and a "break" for 70.
That being said, we did just revise the manner in which the ID shield works and we have a different options set now as well as some additional functionality in other areas. We can definitely take a look at options there again. We can't always say that a given possibility will work and we sometimes have to point things out based on information we have, however we consider the community a very valuable source of ideas as well. Despite the fact that nearly everybody at the company uses the software at home* for personal use, we can't say that any of us have an external keypad that we want to keep Num Lock off on, for example.
We'll see what options we have now with changes to Windows and recent changes to our UI. As something that would be helpful, could you let us know what specific keypad you have? If we are able to look at the details of the hardware and drivers, that may potentially give more options as well.
(* Only nearly everybody because some of us use Linux.)
Kit - you request (could you let us know what specific keypad you have) really won't help. My own experiences listed two different keyboards with the same result. You own comments listed the reason - so, why you want to know the keyboard is suspect in my opinion...
Now your statement: I suspect that you have thrown it out because of a misimpression that we don't care.
My response: Absolutely not the reason - I just can't live with the NumLock problem. I manage a bunch of websites and use NotePad as the editor. I am on the PC at least 3 to 4 hours a day - I can't afford to be dealing with the NumLock issue every few minutes
===========================
Your statement: A lot of people would say that you threw out the baby with the bathwater.
My response: Same as above - I can't afford to play the game. I am also sure you aren't implying that all other (competitor) protection packages are sub-standard to WebRoot because it catches the NumLock issue?
===========================
In conclusion - it is just not acceptable for my usage requirement. Therefore, I have assumed the risk and banking on the replacement program to cover as much as possible. If WebRoot would have had that option (to ignore the problem) - I would still be using it.. One member suggested giving us the option to disable it - that would be great.
Now your statement: I suspect that you have thrown it out because of a misimpression that we don't care.
My response: Absolutely not the reason - I just can't live with the NumLock problem. I manage a bunch of websites and use NotePad as the editor. I am on the PC at least 3 to 4 hours a day - I can't afford to be dealing with the NumLock issue every few minutes
===========================
Your statement: A lot of people would say that you threw out the baby with the bathwater.
My response: Same as above - I can't afford to play the game. I am also sure you aren't implying that all other (competitor) protection packages are sub-standard to WebRoot because it catches the NumLock issue?
===========================
In conclusion - it is just not acceptable for my usage requirement. Therefore, I have assumed the risk and banking on the replacement program to cover as much as possible. If WebRoot would have had that option (to ignore the problem) - I would still be using it.. One member suggested giving us the option to disable it - that would be great.
oahure, I have good news and better news.
Good News: I have just started a dialogue with our developers and product management regarding your suggestion, and I'll chime in here again when I hear back.
Better News: As it happens, Support has discovered a workaround for switching the default state to OFF instead of ON. While it's not togglable yet, it's a start. It involves a registry edit that Support can perform for you. I'm going to set up a support case for you and handle yours personally. If anyone else would like this fix applied, please open a support case and include the URL of this topic in the body of your message.
(vpnavy, I can work on this for you as well if you'd like?)
Good News: I have just started a dialogue with our developers and product management regarding your suggestion, and I'll chime in here again when I hear back.
Better News: As it happens, Support has discovered a workaround for switching the default state to OFF instead of ON. While it's not togglable yet, it's a start. It involves a registry edit that Support can perform for you. I'm going to set up a support case for you and handle yours personally. If anyone else would like this fix applied, please open a support case and include the URL of this topic in the body of your message.
(vpnavy, I can work on this for you as well if you'd like?)
Kit - you request (could you let us know what specific keypad you have) really won't help. My own experiences listed two different keyboards with the same result. You own comments listed the reason - so, why you want to know the keyboard is suspect in my opinion...
Since the issue is with external third party keypads, knowing the keypad allows us to look at ways to detect it specifically and see if its drivers release Num Lock state information, or if we detect a third party keypad, expose options or change functionality based on that detection. We need to look at things programmatically and look at it based on what a program can see and do.
I just can't live with the NumLock problem. I manage a bunch of websites and use NotePad as the editor. I am on the PC at least 3 to 4 hours a day - I can't afford to be dealing with the NumLock issue every few minutes.
Did you try simply turning off (disabling) the ID Shield or changing the processes under it from Protect to Allow?
The ID shield can be disabled completely, or the processes under it can be set to Allow instead of Protect, which leaves some ID shield functionality but disables the keyboard filter that would normally be active when those processes are open. Since the keyboard filter is what locks the Num Lock to a specific state, disabling that should resolve the issue for you completely.
As both Jim and I pointed out, we are able to revisit this now that certain things in Windows have changed and changes have been made to the infrastructure of various frameworks. Therefore, we are revisiting it and trying to find a solution that may not have been possible when this was originally brought up. Technology is always advancing and Microsoft updates can expose APIs and data that didn't get stored anywhere useful before. We still will never make a change that will negatively impact the security of the majority though, which is why details on the specific situation allows us to tailor a solution that will benefit you without hurting others.
Since the issue is with external third party keypads, knowing the keypad allows us to look at ways to detect it specifically and see if its drivers release Num Lock state information, or if we detect a third party keypad, expose options or change functionality based on that detection. We need to look at things programmatically and look at it based on what a program can see and do.
I just can't live with the NumLock problem. I manage a bunch of websites and use NotePad as the editor. I am on the PC at least 3 to 4 hours a day - I can't afford to be dealing with the NumLock issue every few minutes.
Did you try simply turning off (disabling) the ID Shield or changing the processes under it from Protect to Allow?
The ID shield can be disabled completely, or the processes under it can be set to Allow instead of Protect, which leaves some ID shield functionality but disables the keyboard filter that would normally be active when those processes are open. Since the keyboard filter is what locks the Num Lock to a specific state, disabling that should resolve the issue for you completely.
As both Jim and I pointed out, we are able to revisit this now that certain things in Windows have changed and changes have been made to the infrastructure of various frameworks. Therefore, we are revisiting it and trying to find a solution that may not have been possible when this was originally brought up. Technology is always advancing and Microsoft updates can expose APIs and data that didn't get stored anywhere useful before. We still will never make a change that will negatively impact the security of the majority though, which is why details on the specific situation allows us to tailor a solution that will benefit you without hurting others.
Kit: Did you try simply turning off (disabling) the ID Shield or changing the processes under it from Protect to Allow?
The ID shield can be disabled completely, or the processes under it can be set to Allow instead of Protect, which leaves some ID shield functionality but disables the keyboard filter that would normally be active when those processes are open. Since the keyboard filter is what locks the Num Lock to a specific state, disabling that should resolve the issue for you completely.
I remember going the Protect/Allow - it did nothing.
Kit: Since the issue is with external third party keypads, knowing the keypad allows us to look at ways to detect it specifically and see if its drivers release Num Lock state information, or if we detect a third party keypad, expose options or change functionality based on that detection. We need to look at things programmatically and look at it based on what a program can see and do.
Understood.
The ID shield can be disabled completely, or the processes under it can be set to Allow instead of Protect, which leaves some ID shield functionality but disables the keyboard filter that would normally be active when those processes are open. Since the keyboard filter is what locks the Num Lock to a specific state, disabling that should resolve the issue for you completely.
I remember going the Protect/Allow - it did nothing.
Kit: Since the issue is with external third party keypads, knowing the keypad allows us to look at ways to detect it specifically and see if its drivers release Num Lock state information, or if we detect a third party keypad, expose options or change functionality based on that detection. We need to look at things programmatically and look at it based on what a program can see and do.
Understood.
JimM: Better News: As it happens, Support has discovered a workaround for switching the default state to OFF instead of ON. While it's not togglable yet, it's a start. It involves a registry edit that Support can perform for you. I'm going to set up a support case for you and handle yours personally. If anyone else would like this fix applied, please open a support caseand include the URL of this topic in the body of your message. (vpnavy, I can work on this for you as well if you'd like?)
Super news and thanks for the offer JimM. However, right now - I no longer have WebRoot running so it won't be necessary. Again, thanks for the offer.
Super news and thanks for the offer JimM. However, right now - I no longer have WebRoot running so it won't be necessary. Again, thanks for the offer.
I have the Microsoft 4000 keyboard and no external keypad.
http://www.microsoft.com/hardware/en-us/p/natural-ergonomic-keyboard-4000/B2M-00012
I agree with you, this is not a Trojan. I just pointed out that it has some similar characteristics in that it is a program I downloaded and paid for to help me and in my situation it did some harm.
I am not sure where you got your 99.9% stat, but Wikipedia seems to say the opposite.
They say "Since most modern desktop computers have a full-size keyboard with both a numeric pad and separate arrow keys, Num Lock is rarely used for its original purpose, and ends up confusing the user if it has for some reason been activated without the user being aware of this. This can be more of an issue on most https:///wiki/Laptop_computers, since activating the Num Lock function typically requires use of the https:///wiki/Fn_key and if a user accidentally switches it on they may have no idea how to switch it off. If a full-size keyboard is plugged into a laptop, then the Num Lock function is normally off, and the user would have to activate the Num Lock function to use the numeric keypad for numeric entry."
http://www.microsoft.com/hardware/en-us/p/natural-ergonomic-keyboard-4000/B2M-00012
I agree with you, this is not a Trojan. I just pointed out that it has some similar characteristics in that it is a program I downloaded and paid for to help me and in my situation it did some harm.
I am not sure where you got your 99.9% stat, but Wikipedia seems to say the opposite.
They say "Since most modern desktop computers have a full-size keyboard with both a numeric pad and separate arrow keys, Num Lock is rarely used for its original purpose, and ends up confusing the user if it has for some reason been activated without the user being aware of this. This can be more of an issue on most https:///wiki/Laptop_computers, since activating the Num Lock function typically requires use of the https:///wiki/Fn_key and if a user accidentally switches it on they may have no idea how to switch it off. If a full-size keyboard is plugged into a laptop, then the Num Lock function is normally off, and the user would have to activate the Num Lock function to use the numeric keypad for numeric entry."
Thanks JimM, I will wait to hear from someone to update my registry accordingly. Right now I continue to run Webroot but have the Identity Shield off to avoid the issue.
The Wikipedia article agrees. Laptops without dedicated numeric keypads default to off, desktops default to on.
When using a full sized desktop keyboard, the numeric keypad is used by most people to type numbers, not to press "up, down, left, right, home, end, page up, page down", etc. There are already keys for all the arrows and home/end and such, so why have the numeric keypad do the same thing as those dedicated keys? So Num Lock is on by default and pressing the "9" key on the numeric keypad types a nine instead of going up a page.
That is why we set it to On on desktops and Off if we detect a laptop. There is also supportive evidence in the point that out of millions of users and thousands of people reading these forums, only two have expressed a problem with it. :)
Work with the support ticket to change the default, or disable ID shield, or set to Allow instead of Protect. Many solutions, so you get to choose which one works best for you.
When using a full sized desktop keyboard, the numeric keypad is used by most people to type numbers, not to press "up, down, left, right, home, end, page up, page down", etc. There are already keys for all the arrows and home/end and such, so why have the numeric keypad do the same thing as those dedicated keys? So Num Lock is on by default and pressing the "9" key on the numeric keypad types a nine instead of going up a page.
That is why we set it to On on desktops and Off if we detect a laptop. There is also supportive evidence in the point that out of millions of users and thousands of people reading these forums, only two have expressed a problem with it. :)
Work with the support ticket to change the default, or disable ID shield, or set to Allow instead of Protect. Many solutions, so you get to choose which one works best for you.
http://en.wikipedia.org/wiki/Num_lock
I disagree, Wikipedia says "Num Lock is rarely used for its original purpose, and ends up confusing the user if it has for some reason been activated without the user being aware of this".
To me this is exactly what is happening, Webroot activated it without the user being aware. I beleive this sentence states that it is rarely used, another words, it is normally off. They are then saying when it is turned on for some reason people become confused as their keyboard works differently.
I disagree, Wikipedia says "Num Lock is rarely used for its original purpose, and ends up confusing the user if it has for some reason been activated without the user being aware of this".
To me this is exactly what is happening, Webroot activated it without the user being aware. I beleive this sentence states that it is rarely used, another words, it is normally off. They are then saying when it is turned on for some reason people become confused as their keyboard works differently.
I think we can all agree that some people prefer it on, and some people prefer it off. And other people prefer turning it on and off. There are probably a lot of people in all of those groups, no matter what the percentages are. Oahure has a good feature request (or defect observation, depending on how you look at it), and we've brought this up with product management for review.
In the short term, we've got a workaround available through Support now, within 24 hours of this thread being dredged up from it's 8-month-long slumber (and 24 hours turnaround time with a fix is pretty good I'd say).
So, in the holiday spirit and to celebrate having some success with this issue, I would like to offer everyone this picture of eggnog:
:cattongue:
I'll follow up again when we hear back from product management (or product management may even chime in here as well). Please be mindful the holidays are nearly upon us, so the workaround may need to suffice for a bit.
(Oahure, your support case is awaiting a reply, and Vpnavy, please let me know if you change your mind, and I'll be happy to help.)
In the short term, we've got a workaround available through Support now, within 24 hours of this thread being dredged up from it's 8-month-long slumber (and 24 hours turnaround time with a fix is pretty good I'd say).
So, in the holiday spirit and to celebrate having some success with this issue, I would like to offer everyone this picture of eggnog:
:cattongue:
I'll follow up again when we hear back from product management (or product management may even chime in here as well). Please be mindful the holidays are nearly upon us, so the workaround may need to suffice for a bit.
(Oahure, your support case is awaiting a reply, and Vpnavy, please let me know if you change your mind, and I'll be happy to help.)
Thanks for the eggnog and making some good points!
>Since Windows doesn't say what the Num Lock state is reliably, we have to make an educated guess.
You don't have to make an educated guess. Put a "num lock" checkbox in your software.
Jay
You don't have to make an educated guess. Put a "num lock" checkbox in your software.
Jay
Hi Jay,
We exposed an option for people to select for an entire build before we reverted it. Two weeks with that choice and we got over 70 calls from confused people. So it was a fix for perhaps six, for example, and a "break" for 70.
That being said, we did just revise the manner in which the ID shield works and we have a different options set now as well as some additional functionality in other areas. We can definitely take a look at options there again.
We'll see what options we have now with changes to Windows and recent changes to our UI.
We exposed an option for people to select for an entire build before we reverted it. Two weeks with that choice and we got over 70 calls from confused people. So it was a fix for perhaps six, for example, and a "break" for 70.
That being said, we did just revise the manner in which the ID shield works and we have a different options set now as well as some additional functionality in other areas. We can definitely take a look at options there again.
We'll see what options we have now with changes to Windows and recent changes to our UI.
Hi Kit,
You mentioned you revised the manner in which Identity Shield works.
Does this mean I can enable it again without the Num Lock issue?
You mentioned you revised the manner in which Identity Shield works.
Does this mean I can enable it again without the Num Lock issue?
Kind of. The change to the ID shield is a revision of how it works and where it works: On all web pages, not just secure ones.@ wrote:
Hi Kit,
You mentioned you revised the manner in which Identity Shield works.
Does this mean I can enable it again without the Num Lock issue?
I found out that we just added a non-exposed setting for whether the Num Lock should be On or Off when the ID shield is active. Support can provide a registry entry for that.
The Num Lock being stuck one direction or the other is a problem with Windows' reporting of the Num Lock and third party keyboard driver issues. That may never be fixed by Microsoft or the third party people.
OK, I will wait for support to let me know how to do the registry entry so I can enable ID Shield again, thanks.
>We'll see what options we have now with changes to Windows and recent changes to our UI.
Thanks! Let me know how to set the numlock one way or the other. I don't switch it back and forth. I can patch the registry if necessary.
Jay
Thanks! Let me know how to set the numlock one way or the other. I don't switch it back and forth. I can patch the registry if necessary.
Jay
Just open a support ticket and the direct support team will be able to provide that information.@ wrote:
>We'll see what options we have now with changes to Windows and recent changes to our UI.
Thanks! Let me know how to set the numlock one way or the other. I don't switch it back and forth. I can patch the registry if necessary.
Jay
The registry export is now publicly available! If you are not fond of WSA forcing NumLock to the ON position, this registry export is for you.
It is contained in this zip file. AllowNumLock.reg will cause WSA to cease controlling the NumLock state. Conversely, WSA_ControlNumLock.reg will cause WSA to resume control over the NumLock state.
Here is a short explanation of what to do with the zip file:
1. Download the NumLock.zip file.
2. Double-click NumLock.zip to open it. It contains two .reg files.
3. Copy the file AllowNumLock.reg to a convenient location, such as your Desktop.
4. Double-click AllowNumLock.reg to launch it.
5. If a User Account Control window appears, click Yes.
6. If you receive a Registry Editor warning "Adding information can unintentionally change or delete values…", click Yes.
7. A box indicating that the keys and values have been entered successfully appears. Click OK.
8. You must restart your computer for the change to take effect. After the restart, the number pad should behave as expected.
That worked great, thanks. It is nice to be fully protected again.
Thank you for this fix -- it did the job. Now I have a new problem: My numeric keypad is inop, regardless of the condition of the NumLock key. I don't use the numeric keypad very often, but I'd like to have it when I need it. Can help me get it working again?
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.