Nullpointerexception

[Bigtex01]

I am getting the following error when trying to execute right-click commands for pieces in my module:

An untrapped error has occured.
NullPointerException
Please send report to…

To demonstrate this error, I made a test module which reproduced the error on my machine.

New module->
Defined a board using a colored square of the default size.

Went to game piece prototype definitions. Right clicked and selected Add Definition.
Under Name, I called it Emotional piece. The only traits I selected were Delete and Dynamic Property.
Under Dynamic Property, Name, I typed Emotion and set default value to Happy.

Under Key Commands, I made two commands. The first menu command I named Sad, deleted the keyboard shortcut, set type to Set value directly, and set New value to Sad.
The second menu command I named Happy, deleted the keyboard shortcut, set type to Set value directly, and set New value to Happy.

Under Game Piece Palette, I selected Add single piece. Under Basic Piece, I loaded a 2k gif picture from the internet of a happy face and named it Piece 1. I then added Prototype and in the Prototype dialog box, I typed in the name Emotional piece.

I then saved the module and ran it. I can drag the piece from the palette to the board. When I right click on it, I see Delete, Sad, and Happy as my three choices. Delete works ok. Happy and Sad, if I choose them from the right click menu, give me the Nullpointerexception.

When I first did this, even Delete gave me the Nullpointerexception. I deleted Java, reinstalled the latest beta 6u10, and restarted my computer. After that, Delete worked ok. But the other right click commands still give me the error.

I made the test module above as simple as I could to reproduce my error and (for better or worse) it did.

Is it VASSAL? Java? Did I miss something in the program above?

My error log is as follows:

– OS Windows XP
– Java version 1.6.0_10-beta
– VASSAL version 3.0.17
– Unnamed module version 0.0
java.lang.NullPointerException
at VASSAL.counters.KeyBuffer.keyCommand(KeyBuffer.java:108)
at VASSAL.counters.KeyCommand.actionPerformed(KeyCommand.java:103)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

[IrishBouzouki]

hopefully the Vassal team will get your happy button working but meantime…

can you post the simplified module that produces the error as an attachment on this thread?

In addition to possibly helping them, I am curious about this because I have occassionally got the same exception - although I thought I had accounted for why at the time (iirc, and I might not, had to do with making a variable name change in one place that did not carry through elsewhere in the module - but there are many other ways to generate a null reference exception).

[Bigtex01]

Ok, here’s the module.

I have a sinking feeling that it’s something wrong with my machine. Or it could be a Java problem (updating Java fixed one of the problems but not the others). I wonder if this module will produce the same error on someone else’s machine. I just don’t have another working machine right now to test it on.

[uckelman]

Thus spake “Bigtex01”:

Ok, here’s the module.

I have a sinking feeling that it’s something wrong with my machine. Or it cou
ld be a Java problem (updating Java fixed one of the problems but not the oth
ers). I wonder if this module will produce the same error on someone else’s m
achine. I just don’t have another working machine right now to test it on.

The problem is that you’ve added a Key Command but not specified a key,
and VASSAL isn’t expecting this field to be empty.

What the solution is, I’m not sure. Brent or Rodney would be able to
comment on that.

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Bigtex01]

@uckelman

The problem is that you’ve added a Key Command but not specified a key,
and VASSAL isn’t expecting this field to be empty.

What the solution is, I’m not sure. Brent or Rodney would be able to
comment on that.

You’re right, that’s it. Putting key commands into the boxes I deleted them from in the first place solves the problem. Deleting the key commands recreates it.

Is that something that can be changed in a future version of VASSAL–the ability to have a dynamic property set by a right-click but not by a key command (by leaving that box blank)?

The two reasons I can think of to do this are aesthetics–the right-click menu “looks nicer” without a keyboard shortcut displayed next to the command that I’m never going to use (which, I suppose, is not very compelling), and it also avoids the problem of a keyboard shortcut inadvertently changing a dynamic property on a piece that was accidentally selected instead of the intended piece (for example, if you didn’t realize that the incorrect piece was selected prior to executing the key command, or if a property trigger did the same thing).

[Tim_M]

Agreed about aesthetics.
I think this is already a RFE for all commands.
sourceforge.net/tracker/index.ph … roup_id=90
612&atid=594234

Hopefully will get implemented sometime but probably wont be 3.1

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

The original RFE says:

VASSAL uses key strokes as signals to send message between components,
e.g. triggers, global key commands. Instead of having to come up with new
CTRL-ALT-SHIFT key combinations, editors should be able to give a name such
as !triggerDamage. Behind the scenes, the VASSAL editor will convert this
into a KeyStroke that cannot be entered accidentally by a player during
game time.

Having a completely blank KeyCommand is not possible, but this RFE is. I have added it to my to-do list for 3.2.

The way to do this is to map the ‘Named Key Commands’ to Key Sequences that will/can never be used. Eg. the first Name Key Command can be mapped to alt-shift-ctrl-meta-altgraph-A, the second to alt-shift-ctrl-meta-altgraph-B. Vassal can hide this detail, the module developer will just know it as ‘!triggerDamage’, the users won’t see it at all.

Definitely doable.

Rgds,
Brent.

*********** REPLY SEPARATOR ***********

On 20/07/2008 at 6:34 PM Tim McCaron wrote:

Agreed about aesthetics.
I think this is already a RFE for all commands.
sourceforge.net/tracker/index.ph … roup_id=90
612&atid=594234

Hopefully will get implemented sometime but probably wont be 3.1

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “Brent Easton”:

The original RFE says:

VASSAL uses key strokes as signals to send message between components,
e.g. triggers, global key commands. Instead of having to come up with new
CTRL-ALT-SHIFT key combinations, editors should be able to give a name such
as !triggerDamage. Behind the scenes, the VASSAL editor will convert this
into a KeyStroke that cannot be entered accidentally by a player during
game time.

Having a completely blank KeyCommand is not possible, but this RFE is. I have
added it to my to-do list for 3.2.

The way to do this is to map the ‘Named Key Commands’ to Key Sequences that w
ill/can never be used. Eg. the first Name Key Command can be mapped to alt-sh
ift-ctrl-meta-altgraph-A, the second to alt-shift-ctrl-meta-altgraph-B. Vassa
l can hide this detail, the module developer will just know it as ‘!triggerDa
mage’, the users won’t see it at all.

Definitely doable.

Setting an improbable key command when what’s really wanted is no key
command strikes me as a really nasty hack that we should avoid if we
can. Isn’t there some other way we can approach this?

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Tim_M]

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

Joel,

Setting an improbable key command when what’s really wanted is no key
command strikes me as a really nasty hack that we should avoid if we
can. Isn’t there some other way we can approach this?

I would like to hear your specific reasons against this proposal as it relates to RFE 1704269.

I was looking at the larger picture and trying to achieve as much as possible with our limited resources…we don’t seem to be going anywhere at the moment.

Personally, I thought my ‘nasty hack’ was actually an incredibly clever way to introduce ‘Named Key Commands’ across all counter traits as per RFE 1604269 with a remarkably small amount of programming to perhaps 3 classes. About the same amount of work, in fact, it would take to allow KeyCommands to have no keystroke. The ‘Command with no KeyStroke’ is a trivial case of this RFE.

The alternatives, in my view, involve major re-organisation of the KeyCommand handling code with coding changes to virtually every trait and the breaking of all custom code modules. Perhaps you have the spare time to handle this? This is based on my 3 years experience writing a dozen or so traits from scratch, plus fixing multiple bugs in the KeyCommand processing.

Regards,
Brent.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “Tim McCaron”:

Thought about this. Seems like there is really 2 issues.

The first would involve what Brent describes where a key command would be
assigned that no user could ever accidently press and invoke. Such a key
command would be used for internal mechanics such as variable passing or
links from one piece to another.

The second would be the aesthetic display of key commands themselves in menu
selections. Maybe these could probably remain and need key commands and an
option in the preferences could be added to toggle the display of the actual
key commands on / off with on being default like now.

On:

Move CTRL M
Fire CTRL F
Delete CTRL D etc…

Off:

Move
Fire
Delete

I’ve not looked at the code myself, but: Couldn’t we solve both problems
by fixing the code to accept a null?

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “Brent Easton”:

I would like to hear your specific reasons against this proposal as it relate
s to RFE 1704269.

I was looking at the larger picture and trying to achieve as much as possible
with our limited resources…we don’t seem to be going anywhere at the mome
nt.

I have a rather large commit coming, I hope by the end of the week. I
have 87 files left to check for the error handling work, down from
more than 500 two weeks ago.

Would it help if I merged your and Michael’s outstanding commits? (I.e.,
am I holding you up, or can I wait to do that until I’m done?)

Personally, I thought my ‘nasty hack’ was actually an incredibly clever way t
o introduce ‘Named Key Commands’ across all counter traits as per RFE 1604269
with a remarkably small amount of programming to perhaps 3 classes. About th
e same amount of work, in fact, it would take to allow KeyCommands to have no
keystroke. The ‘Command with no KeyStroke’ is a trivial case of this RFE.

The alternatives, in my view, involve major re-organisation of the KeyCommand
handling code with coding changes to virtually every trait and the breaking
of all custom code modules. Perhaps you have the spare time to handle this? T
his is based on my 3 years experience writing a dozen or so traits from scrat
ch, plus fixing multiple bugs in the KeyCommand processing.

Let me be clear about what I am and am not objecting to: I’m not objecting
to this approach, I think this approach is fine. I’m objecting to one
particular detail, namely assigning obfuscated key codes instead of assigning
a null or a key code which is not possible to type.

It looks to me like the immediate problem that in KeyBuffer.keyCommand(),
we call KeyStroke.equals() on a KeyStroke which might be null. If we
know that the right-hand side of the expression is never null, we could
just move the KeyStroke to the right-hand side instead and that would
solve the immediate problem, though I suspect that we’ll end up in trouble
later in keyCommand() from doing that.

I looked at the source for java.awt.AWTKeyStroke and javax.swing.KeyStroke
and I don’t see anything there which stops us from creating KeyStrokes
which have key codes which don’t exist on any keyboard. There are at least
two ways we could do this: One would be to use a modifier which isn’t
defined in java.awt.event.InputEvent. InputEvent.FIRST_HIGH_BIT is the
lowest-order bit for which there’s not already a modifier (it happens to
be 2^14) so we could create KeyStrokes like this:

KeyStroke.getKeyStroke(char, InputEvent.FIRST_HIGH_BIT);

which would guarantee that it’s not generated from a real key. Another way
we could do this is to assign keys from the Unicode range U+E000 to U+F8FF,
which is the “Private Use Area”, because they’re not standard parts of any
font and you can’t (easily) type those:

KeyStroke.getKeyStroke(‘\uE000’);

In either case, we could keep track of the least unassigned key in the
range we’re using so as to avoid collisions when assigning new keys. Using
another new modifiers gives us 65535 keys per modifier set, and 31 bits of
modifiers to work with (given that we always have to keep one of the high
modifer bits on), so that’s 2^47 distinct “keyless” KeyCommands we could
define. The Unicode method gives us 6400 keys and 32 bits of modifiers,
so that’s slightly under 2^45 distinct KeyCommands. No one will ever come
close to using all that space…

I prefer the first solution becuase it makes a collision with real
keystrokes impossible (there’s a small chance of collision with the second
suggestion).

Brent, do either of these sound feasible to you?

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “Michael Kiefte”:

You’re not holding me up. I’ve been taking a break from VASSAL development
pending the release of beta3. I think I have three things that I have to
fix in the importer, but they won’t take long. Do we have an rough ETA for
beta3?

• M.

I hope to be done with the error handling stuff by the end of the week.
There are two bugs I promised to fix, but I think I might already have
fixed one of them as a consequence of what I’m doing now. I’d like to
let the dust settle for a day or two after the next round of merges,
so maybe we’ll have beta3 sometime next week, unless something happens
which disorders my schedule greatly.

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[rk1]

Fixing the NullPointer should be possible without implementing this RFE, but I sure would like that RFE to see the light of day. I don’t want to introduce a new specialized event hierarchy, so I like any solution that generates real AWT KeyEvents and sends them through the existing event handlers.

rk

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

I’ve not looked at the code myself, but: Couldn’t we solve both problems
by fixing the code to accept a null?

No, because the KeyStroke is the message that is passed from the MenuDisplayer to the selected GamePieces.

Sure, we can stop the NPE happening with line fix, but when you select an option on a right-click menu, the associated KeyStroke is sent to the GamePiece. If there is no KeyStroke, then no action happens.

A KeyStoke must be associated with every KeyCommand, so solving the Null KeyStroke problem requires quite a bit more than just testing for null.

As part of RFE 1604269, we can build in some special handling so that a special Named KeyStroke (say ‘!Null’) will be mapped to a KeyStroke guaranteed not to be used by any other KeyCommand.

Regards,
Brent.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

Would it help if I merged your and Michael’s outstanding commits? (I.e.,
am I holding you up, or can I wait to do that until I’m done?)

Sorry Joel, I was having a tired grumpy reaction to being called a nasty hacker I know how busy you have been and you are working on a large system-wide update.

I only have a couple of bug fixes outstanding for 3.1

swampwallaby-work@3769
swampwallaby-work@3737

No hurry on these. I was going to take a break from Vassal until 3.1 settled in, but I couldn’t help myself and have a large pile of RFE’s coded for 3.2:

RFE [ 1604275 ] Move Level up/down within Layer
RFE [ 1637066 ] namespaces for properties
RFE [ 2005463 ] Add Description field to Multi-Action button and Toolbar Menu
RFE [ 2005474 ] Allow Dynamic Property Select Value list to be dynamic
RFE [ 1913850 ] mp3 support

Plus a working implementation of BeanShell scripting, about 50% done. I don’t want to hold 3.1 up, all of these can be held back to 3.2

It looks to me like the immediate problem that in KeyBuffer.keyCommand(),
we call KeyStroke.equals() on a KeyStroke which might be null. If we
know that the right-hand side of the expression is never null, we could
just move the KeyStroke to the right-hand side instead and that would
solve the immediate problem, though I suspect that we’ll end up in trouble
later in keyCommand() from doing that.

As mentioned in my earlier email, this cannot work. No KeyStroke = no action.

I looked at the source for java.awt.AWTKeyStroke and javax.swing.KeyStroke
and I don’t see anything there which stops us from creating KeyStrokes
which have key codes which don’t exist on any keyboard. There are at least
two ways we could do this:

Excellent Joel, this info is exactly what I was looking for. We need a sequence
of KeyStroke that we can assign and use internally that will not clash with
anything that could possible be generated.

Both methods you suggest look good.

Does InputEvent.FIRST_HIGH_BIT have restricted visibility? It does not appear in the API for either Java 5 or 6.

Where can you view the JRE source?

The hardest part I see is coming up with a neat interface for entering the Name Key Commands. The HotKey configurer allows input of a single character which is converted to the mapped equivalent. We need a way to be able flip out of this and enter a named key command (Perhaps call them ‘Virtual Keys’?) instead. An inelegant way would be to include a ‘Virtual?’ checkbox that displays a new field to enter the Virtual Key name.

Regards,
Brent.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “Brent Easton”:

Sorry Joel, I was having a tired grumpy reaction to being called a nasty hack
er I know how busy you have been and you are working on a large system-wid
e update.

It’s ok, I’m feeling a bit overwhelmed right now myself.

I only have a couple of bug fixes outstanding for 3.1

swampwallaby-work@3769
swampwallaby-work@3737

No hurry on these. I was going to take a break from Vassal until 3.1 settled
in, but I couldn’t help myself and have a large pile of RFE’s coded for 3.2:

RFE [ 1604275 ] Move Level up/down within Layer
RFE [ 1637066 ] namespaces for properties
RFE [ 2005463 ] Add Description field to Multi-Action button and Toolbar Me
nu
RFE [ 2005474 ] Allow Dynamic Property Select Value list to be dynamic
RFE [ 1913850 ] mp3 support

Plus a working implementation of BeanShell scripting, about 50% done. I don’t
want to hold 3.1 up, all of these can be held back to 3.2

I’ll do all of the merging at once when I’m ready then, since I’m not
blocking you.

I looked at the source for java.awt.AWTKeyStroke and javax.swing.KeyStroke
and I don’t see anything there which stops us from creating KeyStrokes
which have key codes which don’t exist on any keyboard. There are at least
two ways we could do this:

Excellent Joel, this info is exactly what I was looking for. We need a sequen
ce
of KeyStroke that we can assign and use internally that will not clash with
anything that could possible be generated.

Both methods you suggest look good.

Does InputEvent.FIRST_HIGH_BIT have restricted visibility? It does not appear
in the API for either Java 5 or 6.

InputEvent.FIRST_HIGH_BIT is package-private, unfortunately, though I
think it’s pretty unlikely that it’s going to change in value anytime
soon. We could deduce it’s value anyway by taking the bitwise OR of
all of the listed modifiers and adding 1 to that. Or, we could just
decide to use the high bit, since it’s pretty unlikely that Sun is
going to decide to add another 17 modifiers.

I’ve noticed a problem with this: AWTKeyStroke.getCachedStroke() is
always called whenever a KeyStroke is created, and it squashes all
unknown modifiers. Unfortunately, this method and AWTKeyStroke.modifiers
are private, and getModifiers() is final, so that makes it impossible
to work around by subclassing.

I think this means we can’t do it this way—we need to use the Unicode
Private Use Area instead. (I know we can create KeyStrokes in the range
[U+E000,U+F8FF] without any problems.)

Where can you view the JRE source?

On my Fedora 9 systems, the JRE 1.6 source is in a package called
java-1.6.0-openjdk-src. Prior to that, I was using an archive of the
source which I downloaded from java.sun.com, but I can’t find it on
the site right now. If you can’t find it yourself, ask me and I’ll zip
mine up for you.

I’ve found having the JRE source handy when the javadoc underspecifies
what a method does, or you want to see how some Swing widget acually
works.

The hardest part I see is coming up with a neat interface for entering the Na
me Key Commands. The HotKey configurer allows input of a single character whi
ch is converted to the mapped equivalent. We need a way to be able flip out o
f this and enter a named key command (Perhaps call them ‘Virtual Keys’?) inst
ead. An inelegant way would be to include a ‘Virtual?’ checkbox that displays
a new field to enter the Virtual Key name.

For untypeable Key Commands, what the configurer needs to store is just
an identifier, so as to distinguish one Key Command from another, right?
Could we just let the user type anything he wants there (e.g., a name
which is meaninful to the user) and then keep a Map<String,Character>
which maps those names to chars between \uE000 and \uF8FF?

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

I’ve noticed a problem with this: AWTKeyStroke.getCachedStroke() is
always called whenever a KeyStroke is created, and it squashes all
unknown modifiers. Unfortunately, this method and AWTKeyStroke.modifiers
are private, and getModifiers() is final, so that makes it impossible
to work around by subclassing.

Yes, I spent a while working on a scheme that subclassed KeyStroke before I realised it was impossible due to the lack of public constructors.

I think this means we can’t do it this way—we need to use the Unicode
Private Use Area instead. (I know we can create KeyStrokes in the range
[U+E000,U+F8FF] without any problems.)

That is actually easier.

Where can you view the JRE source?

On my Fedora 9 systems, the JRE 1.6 source is in a package called
java-1.6.0-openjdk-src. Prior to that, I was using an archive of the
source which I downloaded from java.sun.com, but I can’t find it on
the site right now. If you can’t find it yourself, ask me and I’ll zip
mine up for you.

I’ve got a Fedora 9 Vbox running now, I’ll find it there.

For untypeable Key Commands, what the configurer needs to store is just
an identifier, so as to distinguish one Key Command from another, right?
Could we just let the user type anything he wants there (e.g., a name
which is meaninful to the user) and then keep a Map<String,Character>
which maps those names to chars between \uE000 and \uF8FF?

Yes, that’s the basic scheme I have in mind, but the current Configurer does fancy processing on a single type character. Just need to combine the two into one in a neat way.

Brent.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “Brent Easton”:

I’ve got a Fedora 9 Vbox running now, I’ll find it there.

It’s in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/src.zip on
my system.

Yes, that’s the basic scheme I have in mind, but the current Configurer does
fancy processing on a single type character. Just need to combine the two int
o one in a neat way.

What if you had it interpret a single character (plus modifiers) as a
hotkey, and anything longer as the name of an untypeable Key Command?
So, if I type ‘f’ then I have ‘f’ as a hotkey, but if I type ‘foo’
then ‘foo’ gets mapped to \uE000 (if it’s unused).

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

What if you had it interpret a single character (plus modifiers) as a
hotkey, and anything longer as the name of an untypeable Key Command?
So, if I type ‘f’ then I have ‘f’ as a hotkey, but if I type ‘foo’
then ‘foo’ gets mapped to \uE000 (if it’s unused).

Ah, but how do I tell you didn’t type ‘f’, decided you didn’t like it and changed it to ‘o’, then hit ‘o’ again just to make sure?

To get started, I have a basic, if inelegant, but working version where there is a Keystroke input box (like now), a ‘Virtual?’ checkbox and a new field to input a Virtual Key name. The Visibility of the Keystroke box and the Name box are toggled as appropriate by the Checkbox. We can swap in a fancier system at any time.

B.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)