Jump to content

Photo

BASIC / XB Translator (TidBit)


218 replies to this topic

#1 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,387 posts
  • Location:Castaic, California

Posted Sun Nov 21, 2010 12:55 PM

When the game contests started up around here again I was thinking of making an entry, but then remembered all the reasons I dislike BASIC and XB (besides how slow they are.) No indentation, no labels, comments that eat up memory, etc. I've wanted to make a new language for our beloved 99/4A for a long time, but alas that is just another project out of many on the list.

However, in lieu of a new language, I figured it would be easy enough to add some of those features via a "translator". You would still code with BASIC, but without line numbers and such, then the translator would trim out spaces and remarks, add the line numbers, and spit out the code to copy and paste into Classic99.

I wrote the guts of it last night with these features:

* No line numbers allowed, they will be assigned

* Labels can consist of A-Z, a-z, 0-9, _, and -. They can be any length, but a maximum line length is 256 characters. Label "definitions" must start a line and end with a single colon. Labels can be referenced any place a line number can be used, currently: THEN, ELSE, [ON]GOTO, [ON]GOSUB, and ON ERROR.

* Comments are stripped from the code. Comments are any line that start with REM or // (C/C++ style single line comment notation). XB also has a "trailing comment" designated by a ! that causes the rest of the line to be ignored. These comments will be stripped as well.

* Leading space is ignored so you can indent as much as you like.

* Long lines can be split by ending a line with .. (two consecutive periods). These lines will be joined into one long line and the XB limit of 140 characters will be checked.

* Starting line numbers and the increment can be set.


Features I was thinking of adding:

* Support multiple source files.


Currently the translator is written in PHP, which makes it conducive to being set up on a webpage. However, that might make development cumbersome, so I was thinking of making it a native Windows app. I'd like to hear opinions either way.



This post will always have the latest code.

CHANGE LOG:

V1.0 November 20, 2010
    * Initial release

V1.1 February 13, 2011
    * Added forced line number override.

    * Fixed label bug.

    * Fixed max line number bug.

    * Change REM statements to be included in output code.

V1.2 February 25, 2011
    * Added the missing RESTORE, BREAK, and UNBREAK commands / statements to the list
      of tokens that support a line number or list of line numbers.

V1.3 Feb 26, 2011
    * Fixed REM and ! comments.

V2.0 March 16, 2015
    * Fixed using RETURN in an error context when used in an IF/THEN/ELSE statement, i.e. IF exp THEN RETURN <label>.

    * Added additional support for the other ON <statement> (BREAK, ERROR, etc.) commands that can accept a line-number list.

    * Added a version number to keep track of updates.

    * Added a readme.txt with instructions on how to use TidBit on the command line or with PHP's built-in web server.

    * Removed requirement to have .. after the XB :: operator

    * Added ENDIF pseudo statement

V2.1 June 25, 2016
    * Removed requirement to have .. after THEN or ELSE statements, or after the
      last expression before an ELSE statement.

    * Prevent the keyword 'PRINT' from being used as a label to avoid possible
      errors due to the BASIC use of the colon with a print statement: 'PRINT: :'

V2.2 September 10, 2016
    * Added more debug statements.

    * Added check to not allow the auto line number from being overwritten by a
      forced line number if the forced line number is less than the current auto
      line number.  This prevents accidental loss of code.

V3.0 September 13, 2016
    * Simplified parser stage.  Being less-smart reduces errors.

    * Added list of reserved words to avoid label confusion.

    * Fixed bugs in expression parsing with embedded strings.

    * Fixed string parsing bug with escaped double quotes.

    * Fixed XB ! comments that were along on a line.

    * Fixed XB :: operator when following PRINT or DISPLAY AT with colon options.

Attached Files


Edited by matthew180, Tue Sep 13, 2016 9:48 PM.


#2 InfernalKeith OFFLINE  

InfernalKeith

    Dragonstomper

  • 673 posts
  • Location:Toledo, OH

Posted Sun Nov 21, 2010 1:21 PM

I'm trying to understand what this is. You'd code in a modified, less cumbersome and line-number-driven form of BASIC -- kind of a more refined take on it -- and then this would sorta "assemble" it back into a BASIC listing the 99/4A could deal with?

#3 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,258 posts
  • Location:Cookeville, TN

Posted Sun Nov 21, 2010 1:43 PM

I think that's the long and short of it. :) Matthew talked about this in chat about a week ago. Great stuff.... Sort of a reverse-Wilhelm's compiler. :)

#4 adamantyr ONLINE  

adamantyr

    Stargunner

  • 1,147 posts

Posted Sun Nov 21, 2010 1:44 PM

When the game contests started up around here again I was thinking of making an entry, but then remembered all the reasons I dislike BASIC and XB (besides how slow they are.) No indentation, no labels, comments that eat up memory, etc. I've wanted to make a new language for our beloved 99/4A for a long time, but alas that is just another project out of many on the list.

However, in lieu of a new language, I figured it would be easy enough to add some of those features via a "translator". You would still code with BASIC, but without line numbers and such, then the translator would trim out spaces and remarks, add the line numbers, and spit out the code to copy and paste into Classic99.

I wrote the guts of it last night with these features:

* No line numbers allowed, they will be assigned

* Labels can consist of A-Z, a-z, 0-9, _, and -. They can be any length, but a maximum line length is 256 characters. Label "definitions" must start a line and end with a single colon. Labels can be referenced any place a line number can be used, currently: THEN, ELSE, [ON]GOTO, [ON]GOSUB, and ON ERROR.

* Comments are stripped from the code. Comments are any line that start with REM or // (C/C++ style single line comment notation). XB also has a "trailing comment" designated by a ! that causes the rest of the line to be ignored. These comments will be stripped as well.

* Leading space is ignored so you can indent as much as you like.

* Long lines can be split by ending a line with ... These lines will be joined into one long line and the XB limit of 140 characters will be checked.

* Starting line numbers and the increment can be set.

* A keyword "proc" can be added to specify "procedure" line numbering, which causes the line number counter to change to the next highest multiple of the specified value. What this does is allows you to number subroutines starting at certain values, like 1000, 2000, 3000, etc.


Features I was thinking of adding:

* Support multiple source files.


Currently the translator is written in PHP, which makes it conducive to being set up on a webpage. However, that might make development cumbersome, so I was thinking of making it a native Windows app. I'd like to hear opinions either way.

Examples coming soon.

Matthew



A command-line app would be fine, although a native Windows app would be cool too. You could whip something like that up in C# easily enough. :)

Looking forward to seeing it! Line numbers are a pain, indeed, to deal with.

Adamantyr

#5 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,011 posts
  • Location:Uzbekistan (no, really!)

Posted Sun Nov 21, 2010 2:16 PM

Rather than pasting the resultant code in Classic99, how hard would it be to save the file in DV163 (merge format)?

I've never looked at DV163 - is it tokenised or text?

Mark

#6 unhuman OFFLINE  

unhuman

    Stargunner

  • 1,140 posts
  • Location:Vienna, VA

Posted Sun Nov 21, 2010 2:19 PM

Oohhh... Would be nice if we could make "includes" of commonly use functions, whatevers... I spend way too much time re-writing stuff.

#7 jchase1970 OFFLINE  

jchase1970

    Moonsweeper

  • 340 posts
  • Location:Newburgh IN

Posted Sun Nov 21, 2010 3:47 PM

Can you open source this, I'll like to fallow along with your development, since it mirrors a project I'm working on. I mainly want to see how you are pharsing the commands. And assigning varibles.

#8 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Sun Nov 21, 2010 6:26 PM

Here is some example code, sorry I didn't post any sooner. I'll get to the other questions in a little bit. This is an example of my Hunt Kill Maze generator.

Input:
Spoiler



Output:

Spoiler


Matthew

Edited by matthew180, Sun Mar 15, 2015 3:34 PM.


#9 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,258 posts
  • Location:Cookeville, TN

Posted Sun Nov 21, 2010 6:29 PM

That's pretty slick, man. =) You guys amaze me.

#10 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Sun Nov 21, 2010 6:58 PM

Rather than pasting the resultant code in Classic99, how hard would it be to save the file in DV163 (merge format)?

I've never looked at DV163 - is it tokenised or text?

Mark


I don't know anything about the Merge format. Direct me to the some info and I'll look into generating an output in that format if it is not too involved. I'm trying to keep it simply at this point, and not consume all my time.

Matthew

#11 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Sun Nov 21, 2010 7:00 PM

Oohhh... Would be nice if we could make "includes" of commonly use functions, whatevers... I spend way too much time re-writing stuff.


I can do something like C/C++ #include... I suppose that is cleaner than specifying a bunch of input files on the command line. Is this a desired feature then?

Matthew

#12 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Sun Nov 21, 2010 7:13 PM

Can you open source this, I'll like to fallow along with your development, since it mirrors a project I'm working on. I mainly want to see how you are pharsing the commands. And assigning varibles.


I guess so, but at this point it is a 4 hour hack and I totally abuse PHP's string handling. Initially I wanted to go the poor-man's way and just string replace the labels after I made the list. However, since BASIC supports strings, and the text in a string could legally be the same text as a label, you can't just search-and-replace, you have to parse the context. Language parsing is something I've been messing with for a while, so it did not take long to modify something I had written before.

Detecting the labels is easy because of the stipulation I made about them having to start a line and end with a single colon; that is pass 1. Replacing them later in context is pass 2, and that's where the parsing comes in. Depending on where this goes, it may evolve into complete BASIC parsing, but not right now.

Attached is the current code. It will run any place you have access to PHP 5.x, which includes Windows, Unix, and MAC. Depending on if people start to use it, I'm considering a C version with a native Windows/MAC/Unix GUI.

Matthew

Attached Files



#13 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Sun Nov 21, 2010 7:45 PM

Now that I have written a program for my own creation, I'm thinking I don't like the ... for continuation. Something shorter maybe, like .. or just a single . Can an BASIC or XB line ever end in a single period?

I was also thinking about adding an ENDIF token that is simply ignored, but it would allow closing of the IF statements that would look more natural.

Matthew

Edited by matthew180, Sun Nov 21, 2010 7:45 PM.


#14 jchase1970 OFFLINE  

jchase1970

    Moonsweeper

  • 340 posts
  • Location:Newburgh IN

Posted Sun Nov 21, 2010 8:08 PM

I like the ENDIF idea. Are you requiring all variables to be predefined?

#15 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Sun Nov 21, 2010 9:02 PM

Variables? You mean the labels? The program uses two passes, so the labels can be referenced before they are defined. The first pass goes through and finds all the labels and assigns line numbers. The second pass goes through and replaces the references with line numbers.

So you can do something like:

Loop:
    INPUT A
    IF A < 1 OR A > 3 THEN Loop

    ON A GOSUB proc1, proc2, proc3
    END

proc1:
    PRINT "You selected 1"
    RETURN

proc2:
    PRINT "You selected 2"
    RETURN

proc3:
    PRINT "You selected 3"
    RETURN

The references to proc1, proc2, and proc3 are used before they are defined, which is fine. The exact output for the above code is (I copied and pasted it to a file and ran the translator):

100 INPUT A
110 IF A < 1 OR A > 3 THEN 100
120 ON A GOSUB 140,160,180
130 END
140 PRINT "You selected 1"
150 RETURN
160 PRINT "You selected 2"
170 RETURN
180 PRINT "You selected 3"
190 RETURN


Matthew

#16 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Sun Nov 21, 2010 10:08 PM

Well, I just added the ENDIF pseudo token. I also changed the line continuation operator from three periods ( ... ) to just two ( .. ) and removed the need to have them on the end of a line that ends with XB's multi-line double colon ( :: ) operator.

// Old (meaning a few hours ago) way:
A=1 :: ...
B=1

IF A=B THEN ...
    C=2

// New way, .. is not required if a line ends with :: plus optional ENDIF
A=1 ::
B=1

IF A=B THEN ..
    C=2
ENDIF


// Translates to:
100 A=1 :: B=1
110 IF A=B THEN C=2

I guess I just need to add the #include support. I was also thinking of having unreferenced code automatically discarded. Doing this means you could have a huge file full of your favorite subroutines and just #include it in all your programs. Then, only the subroutines you actually reference will actually make it into the real output. I don't know, what do you all think?

Matthew

#17 OLD CS1 OFFLINE  

OLD CS1

    River Patroller

  • 3,826 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Sun Nov 21, 2010 10:17 PM

... for line continuation is nice, but I would also like to suggest that the \ be available, as well. It has been the standard "long line" indicator for just about every system I have worked on which allowed long lines.

#18 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,921 posts
  • Location:Denmark

Posted Mon Nov 22, 2010 2:17 AM

How about a toggle for automatic line continuation. Like if you're programming for TI Basic, you don't want it. For XB you might not want it, so debugging, tracing, editing is easier. And finally for XB you would want it (multiple-statement lines) for speed and efficiency (less memory as I understand). I don't know, but ENDIF might then be vital.

:)

#19 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Mon Nov 22, 2010 7:51 AM

... for line continuation is nice, but I would also like to suggest that the \ be available, as well. It has been the standard "long line" indicator for just about every system I have worked on which allowed long lines.


True, same here, however I tried the \ and didn't really like it. The main difference between BASIC and other languages is that the other languages *have* an end of line terminator, or other constructs to denote blocks (like parenthesis, curly braces, etc.) Thus, most languages fall into the category of "context-free grammar". BASIC (as we know it on classic computers, ie. "line number" BASIC) is not one of those languages.

Because the end of a line denotes the end of a statement in BASIC, you can only have one statement per line. To get around this, BASIC (in general) uses the single colon to allow more than one statement per line. TI's XB uses a double colon because of the PRINT statement's use of a single colon. However, even with the multi-statement operator ( : or :: ) you still cannot break the line over multiple lines because the language does not have any way to know when the statement is done (that and line numbers mess that up.)

In other languages, the \ is hardly ever seen because the languages allow you to structure the statements with as much formatting as you want, they simply eat the white space until the "end of statement" token is found. Thus you can do:

    if ( a == b ) { c = d; }

or

    if
    ( a == b )
    { c = d; }

or
    if ( a == b ) {
        c = d;
    }

or
    if ( a == b )
        c = d;
etc.

The parens denote the expression, the curly braces denote the block (which defaults to a single statement if omitted), and the semicolon terminates a statement. Imagine having to use the \ for every line break:

    if ( a == b ) \
    { \
        c = d; \
    }

Starts to look really bad, and this is what we have to do in BASIC since the end of a line is used to terminate a statement. I tested with part of the code I'm using as an example:

IF (MAZE(X,Y) AND 4)=4 THEN \
    IF C=98 THEN \
        C=96 \
    ELSE \
        C=97
    ENDIF
ENDIF

- or -

IF (MAZE(X,Y) AND 4)=4 THEN ..
    IF C=98 THEN ..
        C=96 ..
    ELSE ..
        C=97
    ENDIF
ENDIF

The double period just looked cleaner to me. Unless we adopt an end of line terminator (like a semicolon), and make the ENDIF required, then multi-line statements need an operator that is unused in the language, and it will need to appear on every line. I tried to use a character that was small and low on the line. Hmm, I suppose it could also be a single underscore.

IF (MAZE(X,Y) AND 4)=4 THEN _
    IF C=98 THEN _
        C=96 _
    ELSE _
        C=97
    ENDIF
ENDIF

Thoughts? Periods are simple to type though since they don't require the shift key.

Matthew

#20 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Mon Nov 22, 2010 7:58 AM

How about a toggle for automatic line continuation. Like if you're programming for TI Basic, you don't want it. For XB you might not want it, so debugging, tracing, editing is easier. And finally for XB you would want it (multiple-statement lines) for speed and efficiency (less memory as I understand). I don't know, but ENDIF might then be vital.

:)


ENDIF would be required, as would a terminator for any open-ended construct. Also, I would have to rewrite the code and basically make a full-blown BASIC parser so I could determine the complete state of the program (hell, at that point I could just start interpreting the language and executing the instructions... ;) )

Right now the multi-line support is done before my basic statement parsing (because it is easy to detect the :: or .. at the end of a line), and that would all have to change. Maybe down the road, but I'd rather have people start to use what I've so far and see where it goes. Right now it is good enough for what I wanted to do, and if I end up being the only one to use it, then it does not much matter.

Matthew

#21 unhuman OFFLINE  

unhuman

    Stargunner

  • 1,140 posts
  • Location:Vienna, VA

Posted Mon Nov 22, 2010 8:09 AM

This would be so helpful for the bucket of crap I've wound up with in the BoCC contest... I'm constantly renumbering... Almost done, though, but the code is no longer anything to be proud of - but will work - and is seemingly efficient enough. I won't ever be coding in BASIC again, but I'm curious - will the support single line BASIC statements? In a time-machine-based world, it'd be awesome if it could rewrite compound IF/THEN/ELSE into the crap we must deal with in BASIC... Again, this is totally unrequired by me - since I'll never be doing this again... :)

-H

Edited by unhuman, Mon Nov 22, 2010 8:09 AM.


#22 jchase1970 OFFLINE  

jchase1970

    Moonsweeper

  • 340 posts
  • Location:Newburgh IN

Posted Mon Nov 22, 2010 8:16 AM

Not sure you even need line extensions
SX=12 :: SY=12 :: ...
DIM MAZE(13,13)
[/code[
to
[code]
SX=12 :: SY=12 :: 
DIM MAZE(13,13)
[/code]

In this case after the interpreter see "::" it knows the next statement (if on the same line or not) will  be added to the same line in the output

The same with IF THENS
[code]
IF (MAZE(X,Y) AND 4)=4 THEN 
    IF C=98 THEN 
        C=96 
    ELSE 
        C=97
    ENDIF
ENDIF

once it finds a IF it enter a structure of what comes next and stays in this structure until it see the ENDIF.

#23 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Mon Nov 22, 2010 8:23 AM

but I'm curious - will the support single line BASIC statements?


This will support anything you can currently do in BASIC. All I'm mainly doing is automating the line numbers and adding support for labels. The multi-line support I'm adding is just cosmetic. The lines will be joined and still have to make a valid BASIC or XB single line statement. The multi-line operator I've added is simply for the tool to know what lines to join. Both BASIC and XB are supported, it simply depends on how you write your code. If you are using just BASIC, don't use XB instructions or the :: operator. The tool has no knowledge of BASIC vs. XB.

Matthew

#24 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,387 posts
  • Location:Castaic, California

Posted Mon Nov 22, 2010 8:29 AM

Not sure you even need line extensions

SX=12 :: SY=12 :: ...
DIM MAZE(13,13)
to
SX=12 :: SY=12 :: 
DIM MAZE(13,13)

In this case after the interpreter see "::" it knows the next statement (if on the same line or not) will be added to the same line in the output


Yup, I already did that. See one of my previous posts from last night. I came to the same conclusion. :)

The same with IF THENS

IF (MAZE(X,Y) AND 4)=4 THEN 
    IF C=98 THEN 
        C=96 
    ELSE 
        C=97
    ENDIF
ENDIF

once it finds a IF it enter a structure of what comes next and stays in this structure until it see the ENDIF.


That would mean making ENDIF required, which I can do, but that starts to change the language itself. But I'd like to know what people think. Also, you still have to use the multi-line statement operator if you have more than one statement in the "THEN" or "ELSE" clauses:

IF A=0 THEN
    C=1 ::
    D=5
ENDIF

- would translate to -

100 IF A=0 THEN C=1:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=5

Matthew

#25 jchase1970 OFFLINE  

jchase1970

    Moonsweeper

  • 340 posts
  • Location:Newburgh IN

Posted Mon Nov 22, 2010 12:34 PM

That would mean making ENDIF required, which I can do, but that starts to change the language itself. But I'd like to know what people think. Also, you still have to use the multi-line statement operator if you have more than one statement in the "THEN" or "ELSE" clauses:

IF A=0 THEN
    C=1 ::
    D=5
ENDIF

- would translate to -

100 IF A=0 THEN C=1:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=5




- would translate to -
100 IF A=0 THEN C=1:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=5





I think the :: would not be needed here because you are in the IF THEN structure and multiple resolves are going to be by default on the same line

IF A=0 THEN
    C=1
    D=5
ELSE
    C=2
    D=1
ENDIF


IF A=0 THEN  ;enter the structure resolve condition output 1st half of line "IF A=0 THEN "
Loop to compute resolve
repeat until ENDIF or ELSE
line 1 command C=1 store in resolve string RS="C=1"
line 2 command D=5 store in resolve string RS="C=1"+":<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=5"
end loop
line 3 command ELSE  add resolve string to output line "IF A=0 THEN C=1:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=5"
loop to resolve else RS=" ELSE"
line 4 command 1 C=2 in RS=" ELSE"+"C=2"
line 5 command 2 D=1 add to RS="ELSE C=2"+":<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=1"
line 6 command ENDIF
end loop cause of ENDIF and add RS to output line  "IF A=0 THEN C=1:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=5 ELSE C=2"+":<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=1"


You could of course have the resolves on one line before the translation it would just treat a :: as adding a new command to the resolve string.
IF A=0 THEN
    C=1:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=5
ELSE
    C=2:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=1
ENDIF

as far as that goes this should be allowable to because you are in the structure
IF A=0 THEN C=1:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=5 ELSE C=2:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=1 ENDIF
because the structure will in pass one break out all commands
line 1 "IF A=0 THEN "
line 2 "C=1"
line 3 ":<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=5"
line 4 " ELSE "
line 5 "C=2"
line 6 ":<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=1"
line 7 ENDIF

pass 2 output add lines 1 though 6
"IF A=0 THEN C=1:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=5 ELSE C=2:<img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_mrgreen.gif' class='bbc_emoticon' alt=':D' />=1"

Edited by jchase1970, Mon Nov 22, 2010 12:42 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users