everything in two languages. Especially when one doesn't support inner classes
and has non-C syntax just to make life easier for parser writers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4762 542714f4-19e9-0310-aa3c-eee0fc999fb1
Use it in SimpleStreamableObject's toString(), with some new formatting.
Unfortunately, the order of public variables seems random.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4746 542714f4-19e9-0310-aa3c-eee0fc999fb1
because the oldValue variable didn't contain UNSET_OLD_VALUE, but
rather null because it was set that way in the constructor.
Additionally, some of the constructors would only set the old value
if it wasn't null, which is also wrong because an old value can
easily be null.
We could probably just rip apart most of this code, because for
the most part events are not constructed on the client anyway. We might be
able to get away with just making all the event constructors 0 arg, and
then we don't have to worry about UNSET_OLD_VALUE, we just always apply.
But let's try to be more similar to the Java code, and so now I emulate
multiple constructors by checking how many arguments were provided and
not configuring event-specific data if it wasn't actually provided
to the constructor.
Note: none of this would be necessary if we could just declare a constructor:
public function AttributeChangedEvent (
targetOid :int = 0, name :String = null, value :Object = null,
oldValue :Object = UNSET_OLD_VALUE);
But you can't use constants as the default value in a parameter list
(commence being boggled) so we have to use null instead of UNSET_OLD_VALUE
as the default value, and then check the 'arguments' special variable to
see if someone passed in null or whether it came from the default value. Aiya.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4726 542714f4-19e9-0310-aa3c-eee0fc999fb1
which parses a String like " 7pigs" as the value 7.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4723 542714f4-19e9-0310-aa3c-eee0fc999fb1
I'm not sure what I was thinking: we'll never want to auto-recognize
command:// urls in text. In the places where we'll use them we'll
format things ourselves.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4719 542714f4-19e9-0310-aa3c-eee0fc999fb1
Sigh. So not standard.
I suppose I could devise a whole system for registering protocols, and
adding registered protocols to this regexp, but we'll never have another
one of these and this is just easier for now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4709 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Added getLength().
- Took out crazy null-tolerance in equals(). If your line is malformed,
you may get NPE's trying to test equality with another line. Fix your line.
These are line segments anyway. We should maybe rename this
class to LineSegment.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4702 542714f4-19e9-0310-aa3c-eee0fc999fb1
the controller has located the appropriate function.
- If the arg for a command or callback is an array, assume those are
the parameters for the function. If you desire passing a single array
argument, you've got to wrap it in another array, otherwise single
args will be automatically wrapped for you.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4676 542714f4-19e9-0310-aa3c-eee0fc999fb1
them to the appropriate ChatDisplay when we're doing chat in IM-style
individual windows.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4663 542714f4-19e9-0310-aa3c-eee0fc999fb1
except that messages will never leave the server. If generated on a client,
they'll go to the server and be processed like a normal event there
(event handlers will be called) but the event will not leave the server and
be sent to subscribing clients.
Changed the ManagerCaller used by PlaceObjects to use ServerMessageEvents.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4648 542714f4-19e9-0310-aa3c-eee0fc999fb1
until after the INIT stage. I don't think this particularly matters for
parameters, since if the URL is unknown it almost certainly means that we
will not need to do the custom parameter loading anyway, but let's just
make sure.
This also knocks a "known issue" off my list, and opens up the possibility
of remixed items loading content packs from a relative URL.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4646 542714f4-19e9-0310-aa3c-eee0fc999fb1
instead of a command to CommandEvent. Weirdly, a CommandEvent will never
be generated with the callback way of doing things, but now CommandMenu and
CommandButton will both support the callback syntax.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4629 542714f4-19e9-0310-aa3c-eee0fc999fb1
texty-input components that wish to have the chat system leave their focus
alone.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4626 542714f4-19e9-0310-aa3c-eee0fc999fb1
The way this all works is: when you send a primitive to the server, you
must wrap it up yourself, because there's no way for flash to distinguish
between the integer 3 and the floating point value 3.0.
But when it comes from the server, it's all wrapped up in a very specific
type and we can easily unwrap it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4623 542714f4-19e9-0310-aa3c-eee0fc999fb1
generally be avoided, but nobody's going to override this method and
we're always calling a regular method on the server, not a varargs method.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4622 542714f4-19e9-0310-aa3c-eee0fc999fb1
If you pass an array as the varargs argument, it doesn't supply the
varargs like it would in java, instead the whole array becomes the first
argument.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4621 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne