Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ General ➜ Shift+Keypad

Shift+Keypad

It is now over 60 days since the last post. This thread is closed.     Refresh page


Posted by David Berthiaume   (202 posts)  Bio
Date Fri 04 Jan 2008 07:46 AM (UTC)
Message
Right then. I need to write a script that will allow me to use shift and the keypad.

Right now I have my keypad setup to various headings(All following headings are in degrees).

Examples:
8= heading 0
9= heading 60
6= heading 90
3= heading 120
2= heading 180
1= heading 240
4= heading 270
7= heading 300


What I want to do is add in mid headings...

Examples:
Shift+9= heading 30
Shift+3= heading 150
Shift+1= heading 210
Shift+7= heading 330
Top

Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #1 on Fri 04 Jan 2008 06:28 PM (UTC)
Message
http://www.gammon.com.au/scripts/function.php?name=Accelerator

Accelerator( "Shift+Numpad9", "heading 30" )


Just a simple script example (using Lua, as normal for me). The link above shows how to use the Accelerator function, as well as all valid keys to which you can bind commands.

It is much easier to fight for one's ideals than to live up to them.
Top

Posted by David Berthiaume   (202 posts)  Bio
Date Reply #2 on Sun 06 Jan 2008 11:53 PM (UTC)
Message
Yeah, Shift+numpad9 doesn't work
Top

Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #3 on Mon 07 Jan 2008 05:47 AM (UTC)
Message
A bit of experimenting shows that Shift+Numpad9 works, providing NumLock is off. However the numeric keypad (built into MUSHclient) is designed to work with NumLock on, so you might have to make accelerators for all the num pad keys if you want to use the Accelerator way of doing it.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #4 on Thu 10 Jan 2008 09:15 PM (UTC)
Message
Hrm... odd issue. Is that also related to the fact that accelerators can't tell tell the difference between the right arrow and the six on the number pad when NumLock is off? I would really like to see those separated.

It is much easier to fight for one's ideals than to live up to them.
Top

Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #5 on Fri 11 Jan 2008 02:08 AM (UTC)
Message
Its probably another of those "MFC issues", or something. You got the same problems in DOS in the day, where the "standard" methods of accessing keypress information for some languages couldn't tell the difference between numpad and arrow keys *despite* the keycodes being different. Basically, what happens is that the standard detection system returns like 022, for one of the keys, no matter which one is actually pressed, but an alternate detection method would net you 07f-022, or something like that. I don't remember the specifics, just that standard key detection didn't return the actual key, just what it **looked like** to the OS. If you used the more advanced version, you could detect keys with sufficient precision to actually *know* if someone used left-shift-right-arrow or right-alt-numpad4. I.e., you could even tell *which* side of the keyboard a key like shift, alt, menu, etc. was pressed on.

Standard keypress detection *always* muddles this, no matter what language you use. And while I suspect this isn't MFC doing it this time, it *is* something you can only get around by bypassing the normal methods provided to detect which key was pressed.
Top

Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #6 on Fri 11 Jan 2008 02:34 AM (UTC)
Message
I've seen plenty of I/O libraries out there that deal with this issue just fine. I've even dealt with a few libraries which give the option of trapping which alt or ctrl key the user has pressed. Granted, none of these systems were designed with DOS/Windows in mind. They have been *nix and Mac oriented, with some of them being ported over to Windows.

And yes, you are completely correct in that odd limitation of key trapping. I had to make a workaround with some old Pascal program I made in high school which would identify the exact key pressed. It involved a LOT more digging around in code books to find out how to get both sets of characters passed when those "extra" keys were put in. If you notice, the only keys where this actually is an issue are all off on the right hand side with the upgrade from IBM's old 84 key to the "enhanced 101" keyset that came out roughly... a long time ago (my sense of time is horrid). Since the new keys duplicated functionality already in other keys, there was just a wonky flag tossed out to warn the program if it cared. I really wish I still had a nice 101 keyboard to use. Ah well, at least I've completely disabled my Windows keys :)

It is much easier to fight for one's ideals than to live up to them.
Top

Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #7 on Fri 11 Jan 2008 04:14 AM (UTC)
Message
It's not my fault, if I can say that without sounding whiny. :)

Let me show you - under the Input menu -> Key Name is a dialog box which has a "hotkey" control, which is a standard Windows control.

Now if you press Ctrl+NumPad9 (with NumLock on), the box shows Ctrl+Numpad9, which means you can use it as an accelerator.

However if you press Shift+NumPad9 (with NumLock on), the box first shows "Shift +" as you press Shift, and then "Num 9" as you also hit NumPad9. However it doesn't recognise the combination (Shift+Numpad9) as a valid key combination. That is why you can't use that as an accelerator.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #8 on Fri 11 Jan 2008 10:46 PM (UTC)
Message
Well, no one suggested it was your fault, really. How where you to know that the library supplied for doing that was foo-bar... Oh, wait, is in an MS library? lol

Its quite ridiculous in this day and age though there isn't either a flag to tell the standard libraries to behave rationally, or some clear alternate that works right. One side effect of this kind of stupid design is that keyboards with like dozens of extra buttons *could* be used in an application to control specific tasks, but can't be, not because they are not mappable, but because either a) the only way to map them that is provided is via driver, or b) the keypress libraries don't fracking return the codes correctly, so ignore anything coming from a non-standard key (which includes just about anything beyond the 101-key keyboard). Makes you want to bang your head against the wall in frustration when trying to figure out how to use some new, "every button, including one for the kitchen sink", keyboard, and not wanting to have to rely on some horrible driver, which probably won't let you map them to anything but 2-3 useless functions.

Had a mouse like that too. 5 buttons, two side, one under the mouse wheel, plus the two standard. None of the "mappings" for any of them supported something as basic as double click, and the stuff it did provide was so completely useless to anyone (save for a small number of people that maybe wanted to have one click copy/paste, or something dumb like that), that the mouse was effectively *less* useful than the old Logitech Mouseman I tried to replace with it. The optical, instead of ball, based position detection **didn't** make up for the worthless nature of the software to set its buttons. Not by *any* stretch of the imagination. :p
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #9 on Fri 11 Jan 2008 10:58 PM (UTC)
Message
Quote:
Its quite ridiculous in this day and age though there isn't either a flag to tell the standard libraries to behave rationally

I have an idea: you can go rewrite the standard libraries to behave rationally, and then we can all celebrate forevermore! :-)

Quote:
and not wanting to have to rely on some horrible driver

You want to talk to hardware with advanced but more importantly new functionality, but without having to rely on its driver? That sounds a lot like wanting to have your cake and eat it too...

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #10 on Sun 13 Jan 2008 12:15 AM (UTC)
Message
Quote:
You want to talk to hardware with advanced but more importantly new functionality, but without having to rely on its driver?


Given how often drivers *fail* to work properly under Windows, while most stuff works fine under Linux, where, well, there are drivers, but they are drivers that talk to the hardware via the bios, in most cases, not trying to talk to that hardware while ignoring what the bios is saying/doing, hell yes. Seriously. If you want an example, here was the configuration on my dads machine:

IDE---IDE Slave(older model 52x CDRom)---IDE Master(new Sony DVDRW)

This refused to work. It refused to work this way too:

IDE---IDE cable select(older model 52x CDRom)---IDE cable select(new Sony DVDRW)

It didn't work with a *new* drive replacing the Sony either, in any rational configuration. What did finally work was:

IDE---IDE Master(older model 52x CDRom)---IDE Slave(new Sony DVDRW)

Why not? Because fracking Windows insisted on trying to talk to it using its CDROM drivers, and kept screwing up something in its internal configuration, which resulting in the DVD drive thinking it was a CDROM, but never allowing you to view files, play CDs or DVDs, or do *anything*. Oddly, it would let you open a disk and "see" file folders, but no files would show up in the contents.

It would boot, installed Windows via that drive, run linux, work under linux without a problem, but Windows frelled the whole thing royally the moment it started talking via the driver.

But, OK, lets be fair. If you are using a USB keyboard, you really don't have much choice, you have to use its driver. But, this problem still exists with PS/2 keyboards, which use the system BIOS to work, or should, except that the fun people at Microsoft figured that **everything** should be fed via one of their drivers. You could make a bios that did nothing but boot load their OS, and had "no" settings, and Windows wouldn't care, because Windows does almost *nothing* via bios, except the bare minimum needed to boot strap the kernal, since it has no choice at that point. This can be a really good thing, if you have driver writers as good as the Linux Kernel people. But, we are talking about Microsoft here. The people that intentionally invent ways to mangle protocols, to make them harder for other people to use, refuse to follow any sort of single specification for anything, and persist bugs from clear back in the era of Lotus 123, not because its "necessary" any more to have that bug, but just in case the forget to fix some bit of code some place, which might break unexpectedly *if* they actually fixed the original problems.

Sorry, rant done. But I think the point is valid. Relying on drivers, in cases where its just totally redundant, or unnecessary, just adds another thing that can malfunction, break, not work as expected, or just plain *not work* at all in some obscure cases. ;)

That said, this seems to be one of those stupid unsolvable problems under Windows. An attempt to google about it have numbers of posts that talk about certain programs using a shift-keypad-+ combo, and a few Linux type ones where some glitches similar to this appear, but almost nothing specific to Windows, which means either its a) not possible to do (sigh...), or the solution is so damned obvious to people that have solve it that no one bothers to post anything about it (I hate this kind of BS when it happens). I will keep nosing around to see if I can find something that can get around it, as I can find the time to.
Top

Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #11 on Sun 13 Jan 2008 12:41 AM (UTC)
Message
Hmm. Ok, this "may" be how people are getting around it:

Quote:
Virtual key codes. These codes report which keyboard key has been pressed, rather than any character generated by one or more keys being pressed. For example, pressing the Shift key will cause a KEY_PRESSED event with a VK_SHIFT keyCode, while pressing the 'a' key will result in a VK_A keyCode. After the 'a' key is released, a KEY_RELEASED event will be fired with VK_A, followed by a KEY_TYPED event with a keyChar value of 'A'. Key combinations which do not result in characters, such as action keys like F1, will not generate KEY_TYPED events. Note: not all keyboards or systems are capable of generating all virtual key codes.


Presumably, this would mean that detecting shift-numpad4, for example, would generate:

key_pressed = vk_shift
key_pressed = vk_numpad4
key_released = vk_numpad4
key_typed = 4 or left arrow, depending on the state of numlock.

The "standard" method of getting the key only returns the final result in key_typed. This is a guess mind you, so I can't be sure, and it obviously means coding that is more complex than the normal accelerators to have it work.
Top

Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #12 on Sun 13 Jan 2008 05:16 PM (UTC)
Message
Quote:
Given how often drivers *fail* to work properly under Windows, while most stuff works fine under Linux

Kind of amusing how often this complaint comes up. You would think the people getting paid for making the drivers would have some sort of advantage in the 'making things work' category. To be honest, it goes both ways. Windows drivers tend to be much better for new technologies simply because the companies come out with drivers for Windows when they release the hardware. For good companies, this works very well. For companies that don't put forth effort into making sure things work, well... I'll be polite and not say anything. The reason why Linux drivers work well once someone develops them is because they are usually created by someone who is very knowledgeable and has bought a piece of hardware with the intent to use it. This person is not satisfied until he/she can use this item that hard earned money was spent on. Granted, this causes a large delay in any emerging technology, but once it works, it works! This does make me want to shoot whoever designed ALSA though, since it took until the last Google Summer of Code to get it working reasonably well (the folks at WINE were annoyed at the poor sound quality and realized it was only half their fault).

Granted, this line is getting fuzzy now. My nVidia card is controlled by Linux drivers which nVidia has officially made themselves. Unfortunately, since it is distributed in a proprietary format, there is a huge argument about whether or not this can be distributed with Linux installation discs, or even hosted at all on official servers. Yay, Open Source fundamentalists...

It is much easier to fight for one's ideals than to live up to them.
Top

Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #13 on Sun 13 Jan 2008 06:50 PM (UTC)
Message
Well, strictly speaking, you are mostly right. The problem with, "Companies have an incentive to make it work.", is that they usually, due to how most deals run, only have an incentive to make it work with special features for "Windows". That causes them to run into a few major problems. 1. Even the best of their drivers, for video cards, for example, don't *always* perform as they should, unless you talk direct to the hardware, and that ironically often disabled much of their features, which use Windows only libraries and communications. Some, like ATI, where so **horrible** at making their drivers "just work", that, for their HDTV capture card for example, I gave up one using their software that came with it, because I went through like 10 versions, in which every time they fixed one bug that prevented component A from working, it would break B, C or D. I now use Beyond TV for it, but even the hardware has minor issues, which the drivers don't/can't fix, that make it work a bit less than optimal some times.

As a rule, and another example, one would think that once you perfect X, and every new video card you make has that feature, you wouldn't have to keep patching the new drivers, to try to figure out why X, and Y *and* Z won't work on the super 9920, when it works fine on the 9901, or something, yet that is *precisely* what happens, all the time. And on some, like the one I have, the hardware itself simply can't support some of its own features correctly, or when used with others, because the hardware itself only has internal pipe lines for "one or the other", but not both, and because its using DirectX, instead of OpenGL, even if you have like 4 cores, each running at 2 ghz, or something, the "drivers" don't allow for support of *any* graphics features via software, but force you to try to use hardware. And that isn't even including the whole BS issue of DirectX 10.

Sure, those are not drivers, but even if you *have* a working driver, the technology might as well be totally useless, since the interface, driver or not, is foo-bar, due to it *requiring* an entirely different proprietary method to talk to the card, to be able to *actually* use any of the features. Worse, the card might not support OpenGL at all (not too common a problem now, but it did happen for a while), or the OpenGL, being a lower priority, will be horribly broken for it (far more common a problem).

And that isn't even to mention the genius decision of MS to, in their new OS, to divorce the sound card even more from internal function, and make it nothing more than a feed system for "software based" sound production. I.e., instead of a *big* driver, which uploads sound production code into the cards firmware (or ram, as more common), or one with a small driver, which talks to a card with *real* production capability, the new trend in MS land will be cards that have ***no*** internal ram, function, other than to just funnel out the sound, after its already calculated by software. Lots of games when you try to run them on Vista are *already* broken because of this, and the hack used to get around it doesn't work 100% right, and is... wait for it... not provided by Microsoft, who created the problem in the first place.

No, the reality is, most companies only driving ambition, for a **long** time has been to make their stuff work, as well as possible, despite the often paranoid attitude of MS about releasing any information about interfaces or code, so that most people will be satisfied with the result, and only the real tech heads, who can tell what just broke in the new hardware, will notice a problem. MS' driving ambition has, on the other hand, been to serve, primarily, big businesses which buy from them multi-million dollar contracts, and only really help the home users *if* it encourages them to use Windows in their businesses. Game makers, manufacturers of hardware that is mostly *only* used for those things, etc., is not their lowest priority, but was, for a long time, very low on their priority lists. It still, imho, is, since most of their concentration in that area has gone to their game console, not to the PC, in recent years. Result - persistent bugs and problems only get fixed if it effects the console, and since the console is using *one* and only *one* type of hardware for its various features, its not too clear how or even if something they change to make that work better, (and it does run Windows too), will break something on a PC, with completely different hardware.

And, 99.9% of all patches from them *are not* related to software patches, game patches or bug fixes on the PC, but only security fixes. Case in point FSX, which came out in like 2004, and which they *only* patched twice, once in like 2005, and once in 2007 (December), neither patch of which fixed certain outstanding and obvious bugs, and one change which actually "broke" texture compatibility for the older FS '98 models, which patch #1 had previously fixed. These are high quality satellite photo textures for land mapping (which made the landscape actually *better* in the old game, when added, than in the new one) and new aircraft, not specifically supplied in FSX natively.

So, even if nVidia, or some other company "fixes" a problem with a driver, half the time MS' own changes just break things again. This is far less likely to happen under Linux, thankfully, but then, unless someone reverse engineers DirectX for it, or some alternate means to get at those things can be developed for Linux, without nVidia and ATI/AMD breaking their own contracts with MS to do it, your still going to have things that won't work, are not supported, and which might *never* work.

All in all, its a major pain in the #$@, especially for someone like me, who doesn't want to *have to* know this stuff, but just wants my bloody games to work properly, not to mention my 3D software, 3D glasses technology, useful for some games, my MP3 players, my music creation software (if my niece needs it for that while visiting), etc. And it, quite simply, doesn't a lot of the time, not the way it should, according to the specifications of the hardware I have and what its "supposed" to be able to do.

Oh, and just to be clear, the driver issue for DVDs is **so common** that there are entire threads posted on help sites dedicated to saying, "Oh, that is easy. Windows probably just detected it wrong. Unplug it, delete the driver, then let it detect it again. It should work then." You would think that something that common would have a patch, right? lol
Top

Posted by Mymyc   (25 posts)  Bio
Date Reply #14 on Thu 26 Mar 2009 01:32 PM (UTC)
Message
Instead of Shift+Keypad - which doesn't work under windows - try Alt+Keypad or Ctrl+Keypad or Alt+Ctrl+Keypad!
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


45,298 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.