Changes:
1. Delete useless lowercase for ScriptEventNames to reduce code complexity and improve performance.
2. Create EventName CStr strings only once per program launch instead of once per call.
3. Send mouse coordinates and mouse buttons object only to mouse events, instead of all events that don't provide custom data.
Abstract:
GUI ScriptEvents such as the famous onTick event are converted to lowercase format, resulting in a number of case inconsistencies in various JS and C++ code and XML markup.
For example `mouseleftdoubleclickitem` in `replaymenu` but and `MouseLeftDoubleClickItem` elsewhere.
These inconsistencies had triggered bugs (as some parts needed to apply lowercasing to become consistent), then TODO comments, and more bugfixes adding comments explaining that this all makes sense and that there is nothing to see there.
Additionally the needless lowercasing performs string copies that would not be necessary and would save some performance.
Originally the lowercasing was introduced as a feature, but it appears to have been a flawed concept.
Pathology:
**Jul 8 2004**
* rP665 Philip introduces Xeromyces XMB with the lowercasing advertized as a feature, intended to make it more fail safe by ignoring spelling mistakes:
```
* Case-sensitive (but converts all element/attribute names in
the XML file to lowercase, so you only have to be careful in
the code)
```
**Jul 11 2004**
* rP706 first bugfix, by Phiip:
```
- object->RegisterScriptHandler(action, code, this);
+ object->RegisterScriptHandler(action.LowerCase(), code, this);
```
**Jul 22 2005**
* rP2511 second bugfix, by gee:
```
// TODO only works if lower-case, shouldn't it be made case sensitive instead?
```
**Mar 3 2006**
* rP3586 third bugfix, by janwas:
```
void CGUI::SendEventToAll(const CStr& EventName)
{
// janwas 2006-03-03: spoke with Ykkrosh about EventName case.
// when registering, case is converted to lower - this avoids surprise
// if someone were to get the case wrong and then not notice their
// handler is never called. however, until now, the other end
// (sending events here) wasn't converting to lower case,
// leading to a similar problem.
// now fixed; case is irrelevant since all are converted to lower.
```
I didn't find this conversation mentioned.
**Mar 11 2006**:
* From `2006-03-11-QuakeNet-#wfg-Meeting-0126.log`:
```
16:43 <Matei> OK, well I don't really have anything to discuss; the only thing that comes to mind is the Xeromyces issue (we should make it case-sensitive at some point)
16:46 <Ykkrosh> I can't think of why it's case insensitive at the moment, except possibly so programmers can assume the names are all lowercase and don't have to check in the XML file to see what case it actually uses. But that doesn't seem like a great advantage, since you have to check how things are spelt anyway, and any errors would be immediately obvious.
16:47 <Ykkrosh> and so if you have a reason to want to preserve the case, I'd agree with changing it to do that
16:48 <Ykkrosh> and I think it should be reasonably straightforward - it'll just need all the Xeromyces-using code to start using the same case as the XML files
16:48 <Ykkrosh> so, er, all we need is to actually do the work :-P
```
**Jun 23 2006**
* matei created #127 to remove the lowercase feature
**Jun 24 2006**
* From `2006-06-24-QuakeNet-#wfg-Meeting-0139.log`
```
17:38 <Matei> I remembered one thing, which is to make Xeromyces not convert elements to lower-case by default, which would be nice as we finalize the entity properties and do more entity coding; I put up a ticket on http://trac.0ad.homeip.net/ticket/127 so we don't forget
```
**Aug 01 2006**
* matei removes the lowercase from Xeromyces but not the GUI lowercase code
* r4185 XML / JavaScript changes for new case-aware XMB format
* r4186 Modified Xeromyces to no longer automatically convert element and attribute names to lowercase
**Sep 07 2006**
* matei closes #127 as fixed
So it seems everyone who came into contact with the lowercase code explicitly stated that they didn't see the point for having the lowercase format or added more lowercasing code merely to account for a bug arising from the lowercasing being applied inconsistently.
**2. const EventNames:**
Unless the code optimizers are smart enough, the CStr string names are created once per event call.
At least the onTick call is done once per frame, so it should be optimized.
By making these strings static const members, we enforce that they are not recreated, without having to check what some of the compilers do.
Secondly having the EventNames stored as named objects allows refering to these names in multiple places of the code in a way that triggers compile errors if there is a spelling mistake.
A planned future user of these string constants is an error message that is to be triggered in case someone does a spelling mistake in JS or XML for an EventName.
That error is currently absent, it would be useful for authors to see dead code due to a typo (something I ran into at least once and only found by accident).
And that error might precisely cover the use case of the lowercasing feature from rP665.
But this should be done independently to avoid mixing two discussions about two different implementations.
**3. MouseEvent**
* For many events that don't pass a custom JS object there is a JS object with mouse coordinates and mouse buttons created. But if it isn't an event relating to the mouse directly, it is a useless surprise that costs performance, rather than a useful argument.
(In the future one might consider obtaining this object only via a JS Interface function or GUI Object property access call, rather than passing it in advance regardless of it being used or not.)