Tim Holloway wrote:Alas, no. The only OS I've ever seen that made a totally clean path from keyboard and other HID devices into system resources was the late, lamented AmigaOS.
Windows - and even Linux - is much messier and to shove in a keyboard translator as an application would not only not be write-once/run-anywhere, it would almost inevitably require administrative privileges.
Now if you're handy with hardware, you could make a translating dongle and essentially prepend the character input stream, but no, there's no simple way in Java.
M Richardson wrote:Everytime I setup a new machine, I like to have things a certain way, and there are projects I work on where the machine needs to have lots of environment variables filled out.
What I would like is to simply have a configuration file which I can add/remove from.. and just run that on any machine to set it up automatically. I suppose this requires knowledge of the Windows Registry?
Piet Souris wrote:I remember from a Project Euler exercise this implementation (apart from the Map.of, since that wasn't available then)
Junilu Lacar wrote:
M Richardson wrote:
Issue #2 : I understand that a design choice to iterate backwards was used in this case to read Roman numerals. Intuitively, how is this insight gleaned from the problem? The cognition that this problem is best solved by reading it from right to left simply doesn't occur to me, and it is demoralizing. If someone was implementing this from scratch, what is the rationale behind iterating from end to beginning?
These are insights that come to you after analyzing the problem. They may come immediately or only after you've tried other ways of solving the problem. Problem solving is hardly ever a linear process. Sometimes you have to come at the problem from different angles. It's entirely conceivable that the decision to iterate backwards only came after trying to iterate forward became too complicated.
One key is to understand the underlying mechanics of the calculation. If you can work through the calculation manually and list down the various rules you're applying, and then see the patterns in how you're applying those rules, it's easier to translate that understanding into an algorithm. Without a good understanding of how you would do the calculation manually, it's very difficult to come up with instructions for how the computer should do it.
Campbell Ritchie wrote:Please tell us where such code comes from.
Yep! Edited my post to include the source. Also, thank you for elucidating!
Tim Holloway wrote:You should be able to add a validatorMessage attribute to the h:inputSecret tag.
You are using a lot of attributes that aren't defined for h:inputSecret. Note that JSF, like HTML, will silently ignore elements and attributes that it does not understand. Nor will JSF pass them down to the generated HTML.