LbNoteBoard, as I have come to call it, was born some months back as an idea to use a web based presentation for an application shown in a Liberty Basic based web browser. The novelty would come from the integration of the material being presented and the Liberty Basic program that would be generating that presentation dynamically based on the users interaction with the presentation.
What does all that mean? Well quite simply put - when I display an html document in the browser, and click on a link - I want my Liberty Basic program to generate the html document that I am linking to on the fly - dynamically. It seemed like a pretty neat challenge, and as it has turned out it was a tremendous challenge with many road blocks. LbNoteBoard represents a demonstration program that answers that challenge and will serve as a launch pad for further development into the integration of Liberty Basic and web based applications.
I began this project in early March of 2003 in response to a challenge that Jerry issued on the [ConForums website]. He was looking for people interested in building an appointment scheduler/calendar application. I wanted to make mine web based. Doyle Whisenant had created such a marvelous and glamorous little web browser that was Liberty Basic based (See the 10 year LB contest at [http://groups.yahoo.com/group/lbcontest/files]), I thought this was the perfect application to take his browser to the next level. The problem was how to integrate the navigation component of the web browser that occurred when someone clicked on a link. The DLL that Doyle's browser is built on just did not provide that kind of linkage.
I began to search for a solution, and tried many different ideas. Along the way I began to realize the only alternative around this problem was to write some bit of data to the user's hard disk, then get that data progamatically from the hard disk and interpret what function to perform based on the data. That sounded pretty much like a cookie to me. But how to write a cookie that did not require some kind of server-side processing. (In the Liberty Browser there is no server, so server-side processing such as Tlk or Perl would not work.) That seemed to leave JavaScript.
Some basic tests confirmed that JavaScript would run in the Liberty Basic browser (in fact someone posted a message to that effect about the time I was searching for a solution). The next problem was how to link a JavaScript to a hyperlink in such a way that the user could click it, cause a cookie to be written yet not trigger any navigation by the browser DLL. I am not a Java programmer, so this became a difficult problem. I was able to solve it by experimentation and some judicious appropriation of some JavaScript combined with some lucky guesses in modification. I was able to create a cookie with embedded information I could use AND prevent actual navigation from a hyperlink.
So things were coming together. But how to find the cookie from Liberty Basic. Well, that became a whole bunch harder than it sounds. Originally I started out trying to use my quick and dirty little DLL called IsFile, which simply tells you whether the file you specified exists or not. Unfortunately this did not work well. As it turns out cookies have a lot more complexity built into them than I first imagined. First the cookie name is not simply the name of the cookie that you thought you had written. The filename also includes the user name and a revision number as well. Second, cookies are not always in the same place from system to system and from OS to OS. These problems rendered the use of my simple DLL obsolete, as well as making the use of the native Liberty Basic FILES command very unattractive. To overcome the problem I developed a new, more specific DLL that would be able to determine where cookies are stored on the system and locate all cookies that conform to a specific search criteria. The new DLL was called CookieUtil, and it is featured elsewhere in this publication or site.
CookieUtil gave me the tool I needed to begin to pull the project together. I would simply trigger a scan for the cookies I was interested in once every quarter second or so when the program was idling - and if I saw a cookie I would shut the timer down and process the event. That meant it was all coming together - I could write cookies and locate and read cookies, all that remained was the actual integration of the components along with some dynamic html generation. And form there LbNoteBoard was born. I am still working on my web based appointment and calendar program. I realized that I would not have it done in time to create this article and test the DLL, so I created LbNoteBoard as a learning tool and a demo platform. I apologize, the demo could be better commented. I have tried to add as much comments as I could, but there is so much string manipulation in this program it may be hard to follow. For that reason I want to bring some critical components of the integration forward and highlight them throughout the rest of this article. I will not be listing the complete program here - it will be available as an attachment, as it relies on several external components to operate anyway.
What happens in the web browser is the first piece of the integration. Every page created by the LbNoteBoard contains the JavaScript in the header. It is actually added to the note page dynamically by copying it from a simple source file called head.inc. Here is the actual JavaScript that causes a cookie to be written when a link is clicked:
<script language="JavaScript">
<!--
function navViaCookie(noteName) {
cookie_name = "NBcookie";
{ document.cookie="NoteSelect:"+noteName+"; expires=Monday, 31-Dec-2012 08:00:00 GMT; path=/LBNoteBoard";
}
}
//-->
</script>
The script is very simple - it is a function and it receives a variable from the link where it is called. It specifies that a document.cookie will be created using a value passed to it along with several other parameters. The "path" parameter sets what the cookie file name will be. This is the very value that we will search for later with the CookieUtil DLL. The JavaScript is part of the section of the html page called the head.
In the body of the html page there may be a link that will look something like the following:
<a href="javascript:navViaCookie('Link')"><font color="#0000FF">
<strong>This Is the human readable part of the link</strong></font></a>
This link is an href, but it does not point to another page, but rather to the JavaScript that we just saw. When clicked it will cause the value "Link" to be passed to the script, and subsequently written out to a cookie somewhere on the user's system.
When used in this fashion, the JavaScript becomes the middleware layer that is required to tie the browser and Liberty Basic together. By controlling all the links and limiting them to these Java variety, we can prevent the LB browser from spawning new IE windows, and we can have positive control over the flow of our application.
Next we need to find out cookies and then act on them. We employ the DLL called CookieUtil which was previously described, and is detailed elsewhere in this publication as well. The DLL is simple to use and it will return a value which reflects how many cookies matched my search criteria that I used when calling the DLL. I put this call to the DLL into an event handler and trigger that event routinely using the TIMER command. I would expect that most calls will result in a zero because the user is usually NOT clicking links. As soon as something other than a zero is returned, the timer is suspended and we go get the cookie and read the contents. In pseudo-code it looks something like:
[loop]
timer 100, [checkcookie]
wait
[checkcookie]
timer 0
check_for_cookies (using CookieUtil)
if cookiecount = 0 then [loop]
'if we are here there is a cookie...
One of the next problems is actually reading the cookie. It will contain a whole bunch of data all strung together. I have written a parsing routine for stripping the components we need from the cookie - specifically the variable data that was encoded and written there. In the case of LbNoteBoard, the data is a link name which is compared with existing link names in an array. If the link name is located, then the file is opened and viewed in the browser. This takes quite a bit of code and can be observed in the attached program.
Because this application is centered around creating notes, it has a basic editor at its core. The editor functions may be basic, but the editor implementation is not basic. There is significant error checking, parsing of strings and organization of information that goes on inside the editor. The majority of this is in support of the custom link mechanism. Links have specific rules that allow the program to efficiently recognize and encode them. Even with shortcuts I have taken to simplify the editor and the embedding of links, the editor still takes up a large portion of the code.
The heart of the editor, after all the data validation is done, is where our Liberty Basic program creates the new html file dynamically right in front of us. Even before we can write the html file out to the hard disk, we must convert any links that the user has encoded (I use a proprietary link format) into the JavaScript form of a link shown above. This is done while scanning the text that the user entered into the texteditor. When a link is encountered the link name is extracted and stored in the variable Hrlink$. Then the code below embeds the link into the text stream that will be written out to the html file.
'Now encode the link using an href and java induced cookie...
work$ = work$ + "<a href=" + chr$(34) + "javascript:navViaCookie(" + _
chr$(39) + link$ + chr$(39) +")" + chr$(34)
work$ = work$ + "><font color=" + chr$(34) + "#0000FF" + chr$(34)
work$ = work$ + "><strong>" + HRlink$ + "</strong></font></a>"
Once the text stream has been completely scanned and all the links replaced, the actual html file is ready to be written out to disk and created dynamically. This is done by first opening the header file - called head.inc (which contains the actual JavaScript function shown above) and then writing its contents out to our new html file. There are two markers in the head.inc file that are dynamically replaced as the code shows below. The first is the background string (I originally wanted to allow the user to select a background, but did not get that implemented) and the second is the page title which is embedded in a table.
'Ok lets open the file and save our note!
OPEN NoteFileName$ FOR output AS #noteFile
open CurrentDir$+"\head.inc" for input as #headFile
'Now write the header out there
while not(eof(#headFile))
line input #headFile, a$
if a$ = "****BackGround****" then
a$ = "<body background=" + chr$(34) + "#ECE7D2" + chr$(34) + ">"
end if
if a$ = "****Title****" then
a$ = NoteTitle$
end if
print #noteFile, a$
wend
After the head portion of the html file is written the body is then added to the file. The texteditor separates lines to text (where the user has pressed enter to cause a new line) with both a carriage return (character 13) and a line feed (character 10). We do not want to write these out to the html file, so they are replaced with a single line break tag:
<br>
Once the file has been written it is closed so that it can be subsequently displayed in the browser.
'Now write the rest of the file out there...
for x = 1 to len(work$)
if asc(mid$(work$,x,1)) = 13 then
print #noteFile, "<BR>"
else
if asc(mid$(work$,x,1)) <> 10 then
print #noteFile, mid$(work$,x,1);
end if
end if
next x
'Now finish it off
print #noteFile, "</p>"
print #noteFile, "</body>"
print #noteFile, "</html>"
'Now close the files
close #noteFile
close #headFile
That is the heart of how it works.
So after quite a bit of work, I am happy to release LbNoteBoard. I hope that people will study it, and use ideas from it. There are many unique ideas presented, some mine, many from friends in the community. For instance, LbNoteBoard tracks all the notes belonging to the given project in a set of arrays. To save memory and allow efficient operation, the arrays are only dimensioned to 20 elements. If the total number of notes should grow larger, then the arrays are dynamically resized using the following code:
'expand the array size for our notes arrays
MaxNotes = MaxNotes + 20
for x = 1 to NoteCount
TempNotesArray$(x) = NotesArray$(x)
TempNote2File$(x,1) = Note2File$(x,1)
TempNote2File$(x,2) = Note2File$(x,2)
TempNote2File$(x,3) = Note2File$(x,3)
next x
redim NotesArray$(MaxNotes)
redim Note2File$(MaxNotes,3)
for x = 1 to NoteCount
NotesArray$(x) = TempNotesArray$(x)
Note2File$(x,1) = TempNote2File$(x,1)
Note2File$(x,2) = TempNote2File$(x,2)
Note2File$(x,3) = TempNote2File$(x,3)
next x
redim TempNotesArray$(MaxNotes)
redim TempNote2File$(MaxNotes,3)
Additionally, as notes are added or removed, the arrays are written out to the project file so that the project can be re-opened and worked on at anytime. This dynamic autosave type feature is similar to that of Microsoft Access, if you have ever use that program. Using this scheme allows the user to concentrate on creativity and not need to worry about saving thier project.
Inspite of all the neat stuff, there was a lot more I wanted to add. As you study the code and play with the program remember: This is a test program and not a completed application. It is intended to demonstrate what can be done to integrate IE as a application foundation. There are many places for improvements in the program. Some I wanted to do, but just ran out of time. For instance, the HELP system is very minimal. It would be nice to be able to edit existing notes, and importing notes would be neat too.
LbNoteBoard is designed to store html formatted notes. These could be recipes or letters or poems - what ever the user desires. They support html formatting because they are displayed in a web browser. As you create notes, simply type your text. If you require special formatting - insert html tags to create that formatting.
The only unsupported tag is the href tag. Links must be formatted using the LbNoteBoard proprietary link formatting. The following from the help file describes that formatting:
Entering text in the editor window is easy. Finished notes are displayed by the IE engine, so they support all HTML tags. I purposefully have disabled your ability to add HREF tags because I do not want LBNoteBoard spawning separate IE sessions which I can not control. All links are from one note to another. Linking is handled in the background using cookies that are set by JavaScript. LbNoteBoard scans for these cookies and they tell the program what link to follow.
Links to Notes that do not exist will cause the program to prompt you to create the page when clicked. Links must follow a strict formatting rule: Links begin with: "<
<<link=My_Link_Page_One||This links page one>>
To link two pages together with links - first create the initial page and place a link on it with a link name that you want to use for your second page. Save that page and it will be the current note. Click the link and you will be advised that the page does not exist and do you want to create it. Click YES to create the page.
Now on this second page, place a link with the title of the first page as the link text. Remember that spaces are not allowed in link text, so if the title had spaces, they were replaced with underscores. If your first page title was "First Page of Project" the your link would look like the following:
<<link=First_Page_of_Project||Link back to first page>>
Try creating links between two pages and see how it works.
I recommend studying the code and playing with it to learn more about how it all fits together. There are many directions this application could go and your imagination is the only limit. I would love to see someone develop LbNoteBoard into something larger. To that end, here are the license requirements that I have imposed upon this code. For the most part it is open source and you are free to develop it or use from it as you want. Please pay attention to the few restrictions below:
This program is copyrighted by Brad Moore, 2003. Many elements are borrowed from other very generous authors in the Liberty Basic Community. Any programmer is welcome to use portions of this program in their own work. You are not permitted to use the entire source package and distribute it as your own work. Additionally, as this is an incomplete demo with many expansion possibilities, you are free to use and expand upon the program turning it onto your own creation. I ask anyone doing this to do two things: 1) rename it to something else, 2) send me you final copy - see my website for email information. Additionally, Doyle requests the following for any programs that incorporate his LB Browser:
Copyright © 2002 by Doyle Whisenant
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Internet Explorer, IE, Internet Explorer Web Control are Copyright © Microsoft Corp.
This DLL is demonstrated in the more elaborate program called LBNoteBoard. An article on this program appears elsewhere in this publication or on this website. The DLL described in this article, the sample program and some basic documentation are all included in a zip archive that accompanies this newsletter.
This was written by Brad Moore - bjaz.moore@copiasystems.com