Help: java.lang.IllegalArgumentException: Value too long

[owangolama]

getting this when trying to save a long Macro.

working in Global so i can do my Macros when my GM is not around.

i seem to have hit a character limit. somewhere over 8,050 or so.

i saw one discussion about this back in 2009, but it wasn't resolved and haven't seen anything more recent.

if i could dump things to sub-routines i could work around it, but that seems fraught with hassle.

any suggestions?

much thanks in advance for any help.

[wolph42]

Irc global macro's are stored in the registry (windows) so that might be the issue. I've got some veeeery long macros but never had this issue. So I would suggest using a lib:token instead and then reference to it from your global macros.

[owangolama]

another player in my game has strongly suggested staying in Global so that i can work on things when nobody else is online.

is it possible to create my own campaign, make some token macros, and then move them to another token in another campaign at a later point? sorry... still very new at all this.

thx again in advance.

[wolph42]

You can create a lib:token anywhere, save it and drag and drop it onto any map (in another campaign). And as long as you remain owner of that token in an online campaign you can edit whether someone is online or not (if you have access to that campaign obviously).

[owangolama]

ok. thanks!

[Lee]

I might have asked this before, but I've always been curious as to why Globals were saved to the registry instead of the data folder like all the other data implementations MT uses. It seems so platform specific, which is so unlike MapTool.

[jfrazierjr]

I might have asked this before, but I've always been curious as to why Globals were saved to the registry instead of the data folder like all the other data implementations MT uses. It seems so platform specific, which is so unlike MapTool.

Because that's what the Java Preferences API does on Windows and MapTool uses the Preferences API because it was handy and already built in(ie, why reinvent the wheel). The options are:

• Deal with moronic windows limitations
• Get a better OS that does not do stupid stuff
• Beg Oracle to rethink their API approach to the Preferences API(but I highly suspect that MS was the driving force behind the original design and they just never figured anyone would need some gigantic values stored in the registry)
• build your code properly to reduce complexity and have repeatable code re-use as much as possible(you should be doing this anyway)
• MapTool change to NOT use the Preferences API in 1.4/2.0, and build something itself(not sure I really like this approach either as it just feels dirty to build something that already exists just to accommodate a very very small set of use cases).

[Lee]

Consider me enlightened

[jfrazierjr]

Well...we could switch over to Apache Configurations framework. It takes a bit more work on the developer front end... But is a lot more configurable..I have used it exactly once in a very small "tool" project I wrote and that was like seven years ago.....

[Azhrei]

Yeah, using the registry is stupid. At least it wasn't our choice.

The code tries to write the macro to the registry, then read it back and compare it against the original to verify that the whole thing was written. (Because Windows, in its infinite wisdom, decided not to return an error when the value exceeds some arbitrary limit. We found that one out the hard way.)

It sounds like the OP has a solution via wolph, so I think this is resolved. At least the code now checks whereas it didn't previously...