Great to see more and more actionscripts being made.. truely displays the power of MXM.. power the users can control.

Alphabet Soup is a an actionscript im working on to allow dynamic text editing of actionscript text elements. For the most part it is working great, just need more tweaking.

to use it. you will just have to define the values/strings/colors you want and use a callfile to include it in your script, it will pass back the editied information to your script so you can save the value to xml, manipulate some it more or whatever your plans are for the users input.

Working it without arrays to some sort of character object makes the script a little longer than i could have been.. but that isnt the problem.

the problem is.. what do we do to make callfile for support scripts foolproof? users might place the scripts in different areas on their hard drive... so how could this be fixed? maybe pull the path of the current script (not declaring it..or setting it manually, but pull the path that it is currently located in) and set that as the default path for the scripts it calls?


any ideas?

QUOTE (koldfuzion @ Nov 3 2003, 03:12 PM)

Great to see more and more actionscripts being made.. truely displays the power of MXM.. power the users can control. Alphabet Soup is a an actionscript im working on to allow dynamic text editing of actionscript text elements. For the most part it is working great, just need more tweaking. to use it. you will just have to define the values/strings/colors you want and use a callfile to include it in your script, it will pass back the editied information to your script so you can save the value to xml, manipulate some it more or whatever your plans are for the users input. Working it without arrays to some sort of character object makes the script a little longer than i could have been.. but that isnt the problem. the problem is.. what do we do to make callfile for support scripts foolproof? users might place the scripts in different areas on their hard drive... so how could this be fixed? maybe pull the path of the current script (not declaring it..or setting it manually, but pull the path that it is currently located in) and set that as the default path for the scripts it calls? any ideas?

Well, callscripts can be included in the MXM.xml (in the <scripts> node), but there should be an automated way to do it as well.

I'm thinking of a few different ways of doing it, and I would like to settle on one that allows "Pulg-n-play" so users merely drop in their scripts. My thought was a "magic" directory, where the file would be gobbled up into an XML file that would actually have the script file. After updating the XML, it would delete the original, or move it into another directory.

QUOTE

Well, callscripts can be included in the MXM.xml (in the <scripts> node), but there should be an automated way to do it as well.

true, but editing xml for most users keps them from using it, and to make the script available to other scripters would reuire the users all the users to do the same thing.

QUOTE

I'm thinking of a few different ways of doing it, and I would like to settle on one that allows "Pulg-n-play" so users merely drop in their scripts. My thought was a "magic" directory, where the file would be gobbled up into an XML file that would actually have the script file. After updating the XML, it would delete the original, or move it into another directory.

sounds great, but maybe just loading a pointer to the file and not loading the whole file itself into the xml would be a better approach? then users can update the xas files and nothing else would be required for mxm to do. otherwise, you have to go through the whole add-script routine everytime a users wanted to update a script because a new version came out. The script name, filepath and version could be put into the xml, then scripters could even check for a particular script version before allowing an "old and broken" script to run.

also, just loading the pointer, path, version might be a better approach for when http-downloading of scripts is enabled. (again, script version could be checked to see if a newer version exists)

the magix directory is needed though.. i use "mxmscripts, mxmskins and mxmvideos" off the app path.. but i dont know how others may be doing it.

im about to finish this script up.. so I though I would post the info block of the script here to give a little insight as to how it will work.

Yes, it was necessary to map the buttons actions in order to let the "scripter" define where to go after the edit without having to modify the script.

in order to switch case, you might actually have to hit the button twice.. depending on the case of the last letter the cursor was over.

QUOTE

;######################################## ;#  Name: Alphabet Soup ;#  Author:koldfuzion ;#  Date: 11-6-2003 ;#  Filename: alphabetsoup.xas ;#  Version: 1.0 ;#  Purpose: A text input script uses the following values ;#           to define input, message and button options.  ;# -Editable text can only be 23 characters long ;# -A Default value should be given so the user has an idea of what they are editing. ;#  -Cursor is defined as brackets. []  its unsightly but allows the editable text to appear anywhere on screen ;#  without having to worry about the "cursor" being off.. or having to be set to specific coordinates. ;#   ;# -asoupLocation ="c:\mxmscripts\alphabetsoup.xas"   defines the path so multiple calls can be made ;#                                             during the main script executions (only needs to be set once) ;# ;#           -THE FOLLOWING VARS ARE TO BE USED TO DEFINE BUTTON ACTIONS TO LABELS (GOTO) ;#           -Thumb DN, UP, LEFT, RIGHT are not assignable, used by the script for editing. ;#            asoupQUIT                 -PREDEFINED LABEL ;#            asoupACCEPTED        -PREDEFINED LABEL ;#            asoupCASECHANGE   -PREDEFINED LABEL ;#            asoupA - SET asoupA _asoupACCEPTED ;#            asoupB ;#     asoupX    - SET asoupA _asoupCASECHANGE ;#            asoupY ;#     asoupWHITE ;#            asoupBLACK      - SET asoupA _asoupQUIT ;#     asoupTRGRT ;#            asoupTHUMBLF ;#     asoupTRGLT ;#     asoupTHUMBRT ;#             asoupBACK ;#     asoupSTART ;#    ;#     -Message BEFORE editable text ;# asoupMSGPRE  - SET asoupMSGPRE "Fill in the blank.   Big " ;# ;# -EDITABLE INPUT IS DEFINED BY    ;#     asoupIN         - SET asoupIN "mother"  -can be predifined text, system variable or another variable value. ;# ;#     -Message AFTER editable text ;# asoupMSGPOST   - SET asoupMSGPOST " trucker"     ;#    ;# ;#  -the before, after and input text are combined to a single sentence, all special tags,  $eol$, can be used as normal. ;#      the displayed message in this case would be ;# - "Fill in the blank.   Big [m]other trucker"   = mother would be editable. ;# ;#     -RETURNED VALUE for write out to xml or to set variable is ;#     %_asoupBOWL%   - would return "mother" if canceled or accepted.  or whatever value the user changes it to. ;######################################################

This is a sample usage:

QUOTE

SET asoupLocation c:mxmscriptsalphabetsoup.xas   ; location of alphabetsoup script SET asoupIN "$NAME$"  ;default value to provide (will return same value if canceled by user) SET asoupMSGPRE "LEFT-RIGHT thumbpad to move cursor$eol$UP-DOWN thumbpad to change values$eol$Press X to Change Case$eol$Press A to Accept$eol$$eol$" SET asoupMSGPOST "   <<- Edit your Name." SET asoupBLACK asoupQUIT      ;asoupQuit  - CANCEL INPUT AND RETAIN DEFAULT VALUE SET asoupA soupACCEPTED  ;asoupACCEPTED  - to accept value of input SET asoupX asoupCASECHANGE        ;asoupCASECHANGE - to change case of letter.  Callfile %asoupLocation% :TELLNAME   BeginDraw UseCurrent     MessageBox "Your new name is %_asoupBOWL%"   EndDraw   Input     If %_GP_A% == "1" GOTO QUIT GOTO ACCEPTED :QUIT QUIT

ok BJ, I think i ran into a problem that will most likely need to be dealt with internally.

the script works fine.. but if i was to read in a value like "c:\mxmskins" there is no way for me to escape the \ to allow the path to be edited.

I know i can use SET thisvar "c:\\mxmskins" to actually set it.. but i'm refering to a value that is already set.

I havent checked what would happen if I did an xml read and the skinpath value was "c:\mxmskins" but i am assuming it would return "c:mxmskins" with no way to escape the \ for editing.

Any ideas?

QUOTE (koldfuzion @ Nov 8 2003, 12:44 PM)

ok BJ, I think i ran into a problem that will most likely need to be dealt with internally. the script works fine.. but if i was to read in a value like "c:mxmskins" there is no way for me to escape the to allow the path to be edited. I know i can use SET thisvar "c:\mxmskins" to actually set it.. but i'm refering to a value that is already set. I havent checked what would happen if I did an xml read and the skinpath value was "c:mxmskins" but i am assuming it would return "c:mxmskins" with no way to escape the for editing. Any ideas?

The double-slashing only matters in arguments in the actual actionscript. The "escaping" (where the backslash is removed) happens when the argument is scanned from the text of the actionscript, once it's in the environment variable storage, there should be no problem throwing it around.

i uploaded Alphabet Soup to AXS.

Its an rar with two files in it = test.xas and alphebetsoup.xas

use test.xas to see what you would need to use in your scripts, the alphabetsoup.xas should remain unedited. (dont load alphabetsoup.xas into your menu, load test.xas if you want to check it out)

DBZRacer... I added a DELETE label to make character deletions easier..get new version, I have it assigned to the B button in the test script.

AlphabetSoup 1,0

DBZRacer and I will be putting this to use in NewUser.xas script.. so new users will finally be able to edit anything and everything when building thier MXM.XML


EDIT : ok cool.. I havent had time to check if that would be a problem or not... and just assumed. Thanks for the clarification BJ.

I know this is too late.

But I have an idea for unlimited text storage.

Use a temporary xml.

Then you can use it like an array.

e.g.

XMLSetValue TESTXML !.Char:%index%

Same with Getvalue.

QUOTE

;# -Editable text can only be 23 characters long

is this a system limitation or was this arbitrarily chosen? if this is a system limitation, can we put it in the ::Actionscript Reference thread?

it was chosen. mostly due to prevent excessively sized messagebox screens. more than 23 characters (when wide characters like C and W are chosen) will push the messagebox over the sides of the screen and that is with a whole line dedicated to the editable text.

extending past the sides cant be prevented if the script is written like:
Please edit your name > $soupbowl$ <

instead of :
Please edit your name$eol$%SoupBowl%