Introducing LameCard!

It's Waaaay Too Lame to be Considered "Real Programming"!

by Tomas J. Nally

Steelweaver52@aol.com


Home

Newsletter Index - Terra

Sprite Byte - Watson

Filtered Numeric Input - Bromley

Changing the cursor - Sweet

QBASIC to Liberty BASIC - Sweet

Contact Manager - Lewis

LameCard - Nally

Submission Guildlines

Newsletter Help

Index

Introduction

LameCard is a technology for writing [Liberty BASIC] programs using a card-like format.

There are two parts to the LameCard technology.

  1. The first part is a set of syntactical rules for writing LameCard source code. Source code written according to LameCard syntax is called LameTalk. (For a discussion of LameTalk, go here.)

  2. The second part of LameCard technology is the LameCard Interpreter, or LCI. The LameCard Interpreter reads a LameCard source code file and converts it into Liberty BASIC code. In addition to that, the LameCard Interpreter creates the Liberty BASIC code that enables all the controls of one card to move "off window", while the controls of another card move "on window". This produces the card navigation effect characteristic of card applications.

Once Liberty BASIC code has been generated by the LameCard Interpreter, it can be compiled and run like any other Liberty BASIC program. However, the resulting LB program will resemble a "card-like" application, similar to what we saw with Apple's venerable [HyperCard]; and as we currently see with [Revolution] and [SuperCard]. The curious may also look at [LBCard], which was my early attempt to produce a Liberty BASIC application that resembled a stack of cards. You can find LBCard discussed in [Newsletter 106].

If you would like a description of how a card application behaves, read this little article.

So, What Does a LameCard Program Look Like?

A LameTalk source file can be written with any text editor. For the LameTalk that I've written to date, I've used Windows Notepad. LameTalk source code should be saved with a *.lame extension. This is because the LameCard Interpreter recognizes *.lame as the default extension for a LameTalk file.

For an example, see the complete LameCard program below:

'filename: testinglc.lame

stackdata
    lameversion 1.0
    windowhandle TLC
    stacktitle "Testing LameCard"
    stackwidth 500
    stackheight 340
endstackdata
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
newcard
    cardname [First.Card]
    statictext "This is the first card."  25  20  200  25
    button "Quit"      [exitlamecard]     400  230  75  35
    button "Go to second card." [Second.Card] 50  230  200  35
endcard
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
newcard
    cardname [Second.Card]
    statictext "This is the second card."  25  20  200  25
    button "Quit"      [exitlamecard]     380  180  75  35
    button "Go to first card." [First.Card] 90  180  200  35
endcard
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
endlamecard

Interpreted application: "Testing LameCard"

Note that I have subdivided the source file into three different sections using the apostrophe, which the Interpreter recognizes as a comment designator.

The first section begins with the command stackdata and ends with the command endstackdata. This section establishes variables and conditions that apply to the stack as a whole. By inspection you can tell what the conditions are: the title, the handle, and the window size are established. Note also that there is a command for the LameCard version. The Interpreter wants to know what version of LameTalk governs for the source file, in case there happens to be subsequent version of LameCard/LameTalk.

The second two sections define the contents of two cards. Note that each of the two cards contains one statictext control and two buttons. On the first card, one button is used to navigate to the second card, while the second button is used to quit the application. On the second card, the first button is used to navigate back to the first card, while the second button also quits the application.

Buttons are critical in LameCard, as a tool for navigating between cards. The article on LameTalk syntax will discuss this in greater depth.

You've probably made the observation that in Version 1 of LameCard, controls are not given names. Instead, names for controls are assigned by the LameCard Interpreter. (The wisdom of this design feature is dubious, and it will likely change if there happens to be a LameCard 2.0). Otherwise, control definitions are very similar to those for Liberty BASIC. It's beneficial that this is the case, because the Interpreter will be converting this source file into Liberty BASIC source code.

The LameCard Interpreter

OK, Now What Do You Do With Your LameCard SourceCode?

Once you've created a LameTalk source file and saved it with the *.lame extension, it's time to run the file through the LameCard Interpreter. The Intepreter will read the LameTalk source code, convert it into Libery BASIC source code, and create the code necessary to allow card navigation. A screen capture of the LameCard Interpreter is pictured on the right.

To install the LameCard Interpreter and several *.lame files on your computer, locate the archive called LameCard.zip which can be found inside the archive for this newsletter, nl121.zip. Unzip all the files in LameCard.zip to a folder of your choosing. To activate the LameCard Interpreter, run LCI.bas, or LCI.tkn.

When the Interpreter runs for the first time, it attempts to find a file called libertylocation.ini. This ini file will contain the location of Liberty BASIC on your own computer. If the Intepreter cannot find this file, then it prompts you to locate Liberty.exe. When you've navigated to Liberty.exe, the interpreter will store its location in libertylocation.ini. The Interpreter must know the location of Liberty.exe, because it calls Liberty.exe when it runs the interpreted program.

Now the the location of Liberty.exe has been established, open a *.lame file. I recommend that you open the file Welcome.lame. This mini-application provides introductory information about LameCard, and contains a bitmap file and lots of buttons. You can open LameCard files by either using the menu, or pressing the "Open and interpret..." button.

Once opened, the LameTalk source file will appear in the upper of the two TextEditor controls. Moments later, the converted Liberty BASIC source file will automatically appear in the lower of the two TextEditor controls. If the programmer has developed what I call a "Pure LameCard" application, then the app is ready to RUN right now. (More about "Pure LameCard" in the section below.) If the user needs to make additional Liberty BASIC modifications to the file, she can save it to disk without testing it. Once saved, the new LB source file can be revised within the Liberty BASIC editor just like any other LB program.

LameTalk Keywords

  • lameversion

  • windowhandle

  • stackdata

  • endstackdata

  • stacktitle

  • stackwidth

  • stackheight

  • newcard

  • endcard

  • cardname

  • statictext

  • button

  • staticfile

  • graphicbox

  • endlamecard

  • But Welcome.lame does happen to be Pure LameCard, so it is ready to RUN. To RUN it, press the "Test LB source file..." button. The Interpreter will call up Liberty.exe, which will compile and run the interpreted LB source file. With Welcome running, navigate through all the cards in the stack by pushing the buttons. This will give you an appreciation for how stacks operate.

    Error Checking With the LameCard Interpreter

    A limited amount of error checking is done by the LameCard Interpreter. The Interpreter accomplishes this by leaving the MAINWIN open in the background. As each LameTalk statement is read by the interpreter, the interpreter evaluates it to determine if the first word of the line is a legal LameTalk keyword, an illegal LameTalk keyword, or if the line is a comment. The results of this evaluation are printed in the MAINWIN.

    If you would like to create your own LameTalk source files, I recommend that you start with one of the existing files, and modify it card by card. If you make syntactical errors, the feedback provided in the MAINWIN should offer hints as to what these errors are.

    What the Heck Do You Mean by "Pure LameCard"?

    As you can see by the list on the right, the number of LameTalk keywords is rather limited. Regardless, it is still possible to write a complete LameCard application using only these keywords. (Welcome.lame is one such application.) When an application can be constructed using LameTalk without any additional revisions, this application can be called "Pure LameCard".

    Realize, of course, that at this stage of LameCard's development, "Pure LameCard" apps will not be sophisticated. They can be useful for providing information (a "help file", for example), but "Pure LameCard" is not well-suited for computation intensive tasks at this time.

    Of course, once LameTalk source code has been interpreted into Liberty BASIC source code, the code is as flexible as any other Liberty BASIC program. The entire set of LB capabilities becomes available. The difference is that your new LB program now has a card-like character to it.

    LameCard Deficiencies (and there are many...)

    Among the known shortcomings of LameCard are these:

    License

    LameCard is copyright Tomas J. Nally. Additionally, LameCard is released as open source.


    Home

    Newsletter Index - Terra

    Sprite Byte - Watson

    Filtered Numeric Input - Bromley

    Changing the cursor - Sweet

    QBASIC to Liberty BASIC - Sweet

    Contact Manager - Lewis

    LameCard - Nally

    Submission Guildlines

    Newsletter Help

    Index