(If you do not see the frame version of this page with a table of contents in the left frame, click here.)

Change Log



2015/05/30 pjm

* Added code to allow to add a child topic node to the current topic while editing the text of the topic. Mark the text you would like as the title of the new child topic, and then, using the right mouse button to obtain the context menu, choose the Add Topic menu item. This will display a dialog to allow you to edit the title and the source, and then will create the new topic and display its text in a separate edit window. You can drag and drop text from the the first window to the new window if you want.

* Also fixed code to save aliases of a topic while editing its content. An alias is a symbolic reference to a topic and can be any string with a length less than the maximum key length as set in the Preferences file. An alias is subject to the Search function. Mark the text you would like as an alias of the topic, and then, using the right mouse button to obtain the context menu, choose the Add Alias menu item.

* Just a note while I am discussing the text context menu: If you select (highlight) a word and then choose the Search menu item from the context menu, farVIEW will search for topics having an alias matching the search text.  If you select more than one word, depending on the setting of the Search dialog radio buttons, the search words form either an "AND" expression or an "OR" expression. Note marked aliases are not stemmed so you have to make an exact match. This does not apply to aliases generated by one of the indexing modules (Dexter.exe or index.far). These modules stem aliases if specified in their parameters.

* Due to a bug, the search function appeared not to find titles and aliases of topics that you had created unless you had previously indexed the book. This problem has been fixed. Make Topic and Add Alias menu items have been added to the text window RMB context menu that


2013/04/25 pjm

* Probably time to list the XUL widgets that farVIEW currently supports, along with their attributes(tbd):

   box
   hbox
   vbox
   button
   canvas
   checkbox
   groupbox
   caption
   image
   radio
   radiogroup
   deck
   spacer
   tab
   tabbox
   tabpanel
   tabpanels
   tabs
   label
   textbox
   editor
   listbox
   listitem
   menulist
   popupbutton
   menupopup
   menuitem
   menuseparator
   hrule
   script
   template
   rule
   window


2011/01/03 pjm

* Added an ability for farVIEW topics to handle events using farSlang or XUL modules by associating events with handlers in the topic's new Events property. You associate a specific event with a particular handler using the same onevent form that you use in an HTML or XUL element. For example, to associate a left-mouse-click with the lovely moonwind.xul script, you would code onLMBDown="xul:moonwind" If you wanted to play the Sodoku game by clicking on a particular topic, you could type onLMBDown="far:sudoku". Of course, you can write your own XUL and farSlang modules to handle events as well. Note that you specify a farSlang event handler using the "far:" prefix ("far" followed by a colon), and you specify a XUL event handler using the "xul:" prefix ("xul" followed by a colon), as in the examples.

A topic will pass an event up the path from itself toward the root of the topic tree. Any ancestor or parent topic that can handle the event will do so according to its onEvent specification.

Here is a list of events (without explanation :-() that are candidates for use in a topic:

   onFarVIEW
   onClosing
   onDropFiles
   onPasteData
   onDefButton
   onOk
   onCancel
   onYes
   onNo
   onAbort
   onRetry
   onIgnore
   onKeyDown
   onGetDispInfo
   onSelChanging,
   onSelChanged
   onNodeExpanding
   onNodeExpanded
   onEditTopic*
   onEditBody*
   onBeginDrag
   onLMBDrop
   onRMBDrop
   onBeginLabelEdit
   onEndLabelEdit
   onDeleteNode,
   onMouseLeave*
   onMouseEnter*
   onMouseWheel
   onMouseMove*
   onLMBDown*
   onLMBUp*
   onDoubleClick*
   onMMBDown*
   onMMBUp*
   onRMBDown*
   onRMBUp*
   onOutOfMemory
   onReturn
   onEnter
   onGetSizeInfo
   onSizerMoved
   onSetToOn
   onSelTab,
   onPaint
   onPaintNode
   onPost

I've tested the starred events. Can't speak for the rest at this time.

* A topic can modify the menu items in any of four topic popup menus. Add the appropriate property/properties to the topic.

TreePopup
TreeDropPopup
TextPopup
TextDropPopup

I had to invent yet another "language" that you have to use to do this, which is described below. Add the property for the specific popup, and then add text to that property that specifies the menu items you want to add. Be sure to read the menu notes for 2009/10/27 immediately below this for some context. Also you can read the <menus> section of the farview.fix preferences file for even more context.

Format of the popup menu properties is

menuitemlist ::= menuitem[ ";" menuitem ]
menuitem     ::= "-" | "--" | "-" name | name [ parameters ]
name         ::= [ menuname "." ] itemname
parameters   ::= "(" command [ "," disabled ] [ "," check ] [ "," value ] ")"
command      ::= "command=" commandname
disabled     ::= "disabled=" "true" | "yes" | "false" | "no"
check        ::= "check=" "true" | "yes" | "false" | "no"
value        ::= "value=" argument for Run command.

   * [..] indicate zero or more, {..} indicates zero or one.
   * The parameter names can be abbreviated to as little as "co", "d", "ch", and "v".
   * Except for text to appear as a menu item, this isn't case sensitive.
   * You can find example of Run-type menu items in the <menus> section of the preferences file.

Sample:

     Sudoku(com=Run,val=far:sudoku);-;Moonwind(command=Run,value=xul:moonwind)

The two menu items, Sudoku and Moonwind, will be added to the end of the menu before it appears to the user. Note the separator.

You can add menu items to any sub menu in the menu by prefixing the menu item name with the name of the sub menu followed by a period. (See the name rule above).

 Notes:
    * Indicate a menu item separator using the dash (-) character alone.
    * Remove a menu item by prefixing the item name with a dash.
    * Insert a menu item or sub menu in a sub menu by using the menu-name.menu-item nomenclature.
    * Clear the whole menu of all items using the double dash (--).
    * Use only the properties you need, but command is required and must be first.
    * The menu item property names need only be long enough to identify them.

* There are currently some directory path issues for running XUL and farSlang modules from farBooks not residing in the farVIEW executable directory if the modules are not within the directory containing the farBook. This needs to be fixed so that the fars subdirectory and the xul subdirectory of the farVIEW executable directory should be searched for the specified module after not finding the module in the farBook directory or its subdirectories.

* This program remains forever alpha. Yeah, I need to follow more stringent rules of development.

* You can add your own popup menus for farSlang by embedding them within the <menus> element in the preferences file, or you can load them into an XML document yourself from a file or wherever.

Use the following code snippet to load a menu from the preferences file:

proc loadMenuFromPreference: CMenu(menuPrefName$)
   return CMenus.XULMenuPopup(menuPrefName)
   endProc loadMenuFromPreference

Remember that the <menupopup> element must be a child of the <menus> element in farview.fix.

Or, if you want to load the menu from a XUL file that contains (only) the popup menu, you could go this route:

proc loadMenuFromFile: CMenu(menuFileName$)
   var document := CDocument
   document.Load(menuFileName)
   return CMenus.XULMenuPopup(document.DocumentElement)
   endProc loadMenuFromFile

I omitted error checking for clarity, but you would do well to add error checking to your own code.

* When you add a topic to a farBook, the manifest is now derived from the manifest template in the preferences file. It used to be drawn for the manifest template that was in the preferences file at the time the farBook was created. You can find the manifest template in the <manifest> element. Note that the order in which the properties are displayed in the topic editor is the same as the order in the manifest template.


2009/10/27 pjm

farVIEW now lets you control its menus using XML in the preferences file, farVIEW.fix, using Mozilla's XU languageL. To see the default menu setup, search for the <menus> element in the farview.fix file. farVIEW's menu system supports <menubar>, <menu>, <menupopup>, <menuitem>, and <menuseparator>, which you can read about here.

farVIEW locates the XUL menu description to use in a specific context by matching on the name attribute of either a <menubar> element or a <menupopup> element, depending on the context. There are six contexts in which farVIEW uses a menubar or menupopup.
Use the <menubar name="treemenu"> element to describe the TOC menubar and the <menubar name="textmenu"> element to describe the Text editor menubar. farVIEW also presents context menus on Right-Mouse-Button release events, and you describe these using the <menupopup name="treepopup"> and <menupopup name="textpopup"> elements. The farview.fix file contains examples of all of these. farVIEW also presents a popup menu when you release the RMB when you drag and drop an object using the RMB.

farVIEW does not support every XUL attribute in the menu descriptions, but it does support the more salient ones, specifically in the <menuitem> element:
You can read about these here.  Note that the accesskey attribute is not yet supported, but will be at some point, so you can feel free to include it, it just won't do anything for now. Also, the value attribute is used for two specific menu commands, but is ignored for all other usable commands. I'll explain its use after this list of the available menu commands.
You can use the value attribute with the Run and Menu commands. When you use it with the Run command, the value attribute should contain the name of a farVIEW object, such as a farSlang module or a XUL module that you want farVIEW to run. You identify whether it is farSlang or XUL by using a prefix of far: for a farSlang module, or xul: for a XUL module. For example, use the following menuitem to run the Sudoku module:

    <menuitem label="Sudoku" command="Run" value="far:sudoku"/>

And use the following menuitem to run the moonwind XUL module,

    <menuitem label="Moonwind" command="Run" value="xul:moonwind"/>

The second situation where the value attribute is supported is with the Menu command. This allows you to associate a popup menu with a menuitem. Here is an example:

    <menuitem label="More tools" command="Menu" value="toolspopup"/>

The value "toolspopup" must match the name attribute of a menpopup element for this facility to work properly. Note that this is not the way it's done in Mozilla XUL, but you can embed the submenu inside a menu the way that Mozilla XUL does it. See their examples.


2008/06/27 pjm

You can download a couple of farBooks and the latest farVIEW. The farBooks are Forms and a searchable version of the American Standard Version of the Bible.

I am currently revamping the farVIEW widget library to use a subset of the Mozilla XUL language, which is now possible since I implemented the DOM Level 2 Events (see the 2008/01/07 entry below). It is coming along very well , and you can follow along if you like by downloading the latest farVIEW from time to time along with the latest Forms farBook. The farBook has the samples that I am using to test that my version of the XUL layout manager works the same as the fireFox version.

To install either of the new farBooks, download the install file using the links above, create a new local folder, and unzip the contents of the install file into it. Be sure to install the latest farVIEW as well. Once you have installed farVIEW, add it to your environment Path. Then you can run the Bible farBook by making the folder current, and then typing farview asv at the command line. To run the Forms farBook, make its folder current, and then type farview forms at the command line.

The Bible folder includes a list of all the words in the ASV version of the Bible, along with a count for the number of times each word occurs, in the file asv.wds. Note that the words are stemmed. Since there are words that are used very frequently, many words are not indexed. The list of words that were not indexed are in the file stop.wds. You can use the File/Search menuitem in farVIEW to search for where a word occurs in the various books. You can reindex any time you want by using the index.far farSlang module in the fars folder that comes with the farVIEW installation. If you want to index all words, just change the name of the stop.wds file. I wouldn't index the common words though. You are just slowing down the whole process for no good reason. Include the words you don't want to index in the stop.wds file before you run the index.far module.

To use the Forms farBook, open any XUL topic to find its Test topic, and then double click on the topic. To see how farVIEW runs a XUL file -you can add your own test XUL - right-click on a Test topic to see that the name of the XUL file to be run is entered in the Form property. I'll upload updated Forms farBooks as I continue development. To see how I am coming, just run the same XUL files in fireFox and compare. Do expect occasional misbehaviour when using Forms.

I'm still having trouble with the editor occasionally bombing unexpectedly, along with an occasional drag-and-drop issue. I have not been able to root these problems out, but they aren't that high on my list at the moment.


2008/04/24 pjm

Even more updates and improvements:

* This first item was mentioned last time, but it has evolved into a more complete solution. The Source field in the topic properties is where you store file names, command lines, scripts to run, and plain-old-emptyness. The type of information that is in the Source field determines the image that farVIEW shows in front of the title of each topic in the Table-of-Contents window. It also determines how farVIEW responds when you double-click the topic title or press the Enter key when the topic is selected. Heretofore, how you indicate the type has been hard-coded in farVIEW. Namely, it has been determined according to the rules described here. But this has proven awkward and inflexible. The farVIEW user should have much more control over this. This note describes how you can control this. There is now a section in the preferences file (farview.fix), called <sourcetypes> that allows to control how farVIEW handles the topic image and how to open it. There is a <images> section in farview.fix, which identifies the image files to use in the TOC window. There should always be two images to represent when the topic is closed and when it is open if it has children. If it has no children, then there should be a leaf image. For example, the following XML group identifies the images to use for an empty Source field.

        <source>
          <image>textclose</image>
          <image>textopen</image>
          <image>textleaf</image>
        </source>

You can add image sets of your own, and you are certainly welcome to change the images sets that are in the <images> group. You can also select which image set to use with different files based on patterns that you code. Right now, I have added a set to handle a variety of file types and source strings. Here is the section as it currently appears.

  <!-- Associates various properties with topic source strings according
       to how they match specified patterns. If a source string matches
       one of the specified patterns, returns the value of the specified
       attribute associated with the matching pattern. Note that you can
       use a regular expression by preceeding it with an equal-sign. As
       it is, I convert the pattern into a regular expression and match
       it against the source string anyway, so you can too. The image attribute
       should match one of the image sets in the images section. The open
       attribute specifies how farVIEW should open the content when the user
       double clicks on the topic. Other
attributes are possible. You can
       access this in farSlang using the following function call:

           var openValue := CManifest.SourceType(<stringtotest>, 'open')

       for example. You can add other attributes and <type>s as needed. -->

  <sourcetypes>
    <type image="text" open="edit">=^\$.*</type>
    <type image="farrun" open="run">=^|.*</type>
    <type image="cmdrun" open="os"><![CDATA[=^>.*]]></type>
    <type image="text" open="edit">*.txt,*.far</type>
    <type image="music" open="os">*.mp3,*.wav</type>
    <type image="image" open="os">*.bmp,*.gif,*.jpg,*.jpeg,*.png,*.pcx</type>
    <type image="movie" open="os">">*.mov</type>
    <type image="text" open="os">*.c,*.cpp,*.h,*.hpp</type>
    <type image="text" open="edit">*.xml,*.xul,*.xsd,*.xsl</type>
    <type image="http" open="os">file://*,https://*,http://*,*.htm,*.html</type>
    <type image="wildfile" open="os">mailto://*</type>
    <type image="far" open="open">far://*,*.vue</type>
    <type image="wildfile" open="os">=^.*\*.*$</type>
  </sourcetypes>

The comment explains the particulars. Note that the images attribute identifies which image set to use if the specified pattern matches the Source field contents. The open attribute identifies the way that farVIEW opens the topic when you double click it. The options currently are "edit", "run", "open", and "os".

The Edit option opens the content in the farVIEW editor. Note that farVIEW alsways opens the topic contents in the farVIEW editor when the Source field is empty. The Open option opens the specified farVIEW farBook as a child of the topic. The Run option compiles the specified farSlang module (if necessary) and runs it. And the OS option sends the source string, as is, to the operating system for processing.

* Have been working to clean up memory leaks. Have made great strides here.

* Working for farVIEW to be a dragSource. Currently, it is only a dragDrop kind of guy.

* Added the ability to select the keyboard assignments in the farview.fix file. You can add alternative assignments fairly easily, and I intend to add some Word-compatible and Emacs-compatible assignments. Not all of the keyboard assignments, mind you, but enough to maybe make you feel reasonably comfortable using the farVIEW editor. To select the keyboard assignment set, look in the <interface> section of the farview.fix file for the <editor> element. Change the name attribute to identify the keyboard set section you want to use. Each keyboard section is contained in the <editor>/<commands> part of the preferences. Look for the name attribute in the <commands> element that matches your editor preference and specify that.

 

2008/01/07 pjm

* A lot of updates.
* A lot of irons in the fire.


2007/06/19 pjm

* You can use farVIEW as portable software, which means that you can install it directly to a USB drive. farVIEW does not use the registry, but uses a file, called farview.fix, to contain its working parameters. farVIEW addresses an additional problem faced by portable software: the problem that the drive can have different drive letter assignments on different machines. If you include the drive letter in a reference to some resource, you may not find the resource on another machine. However, farVIEW solves this using the volume name. If you assign a volume name to your USB drive, farVIEW will use that name instead of the drive letter when it stores a reference. And then, when you plug the USB drive into a different machine, farVIEW will translate the volume name to the proper drive letter transparently. It does that for all the drives in your system, which means that it won't get confused by C-drives on different computers if they have different volume names. You won't even know it's happening. I guess I coulda kept my mouth shut. You'd have never noticed :-)

Another problem with installing farVIEW on a USB drive is that the farVIEW executable and its DLLs are somewhat large. I now use a program, called UPX (go to http://upx.sourceforge.net for your own copy) to compress the files. It reduces their size by quite a margin.

I want to provide a version of the install for farVIEW that integrates with the PortableApps menu. I'll try to do that soon. I looked the integration requirements for U3 over, but it seemed complicated enough that I probably don't have the time for it right now.

You can reach the farVIEW download page here.

* BTW: For Java developers, I have added a new program, called XUL2Swing. This is comprised of several Java source files and sample XUL files. XUL2Swing provides a toolset for prototyping a GUI using XUL, and then using the XUL code to generate native Java Swing code to incorporate into your Java project. XUL is very easy to learn, if you don't already know it. XUL reduces the task of describing a GUI to its bare essentials. You can modify your GUI very easily in XUL, which you can't say for the Swing code you would have to write for the equivalent GUI. The conversion rate appears to be about 5-to-1.

Use the XUL2Swing link above to reach the manual and the download link. Feel free to modify and add features. The more the merrier. Also, some ambitious C# person might like to do an equivalent conversion from XUL to C#. It wouldn't be all that difficult.

Also, Tags has been updated, but the manual is getting a bit out of date.


2005/12/10 pjm

* I have been so derelict in keeping this log up to date. Not that I haven't been working on farVIEW, but, with the zero interest in it by anyone else, I have not bothered to say anything here. This entry will only cover what I can think of as I write this. There are many improvements and bug fixes that I simply have forgotten.

There are some new farSlang modules. In fact, the reason I am adding this note is because I just finished coding a module that helps play the Sudoku game. It has a number of features, including a pretty comprehensive, but simple, hinting algorithm. It can also save alnd load games.

I had promised myself that I wouldn't play Sudoku, but I had a few minutes a couple of weeks ago, and there was a game published in a magazine. So, I tried it. But as I played the game, I couldn't resist designing a farSlang implementation of a Sudoku Sidekick. I just finished the code for it a couple of hours ago. The module came to about 700 lines, including comments, which is the largest farSlang module I have written for the new engine to date. As a side effect, I removed some farVIEW bugs, and made some improvementsas well. I have included the source file for sudoku.far in this release. I think that I might code a few other simple games as time goes on.

Since the date of my last log entry, I have added or improved about 20 farSlang modules. The only documentation available for them, though, is in the modules themselves. Some highlights are

send.far and recv.far make up a topic mail system that you can use with other farVIEW users to share topic trees using drag-and-drop. You need to know their URLs or IP addresses to use this, and they have to agree to the relationship.

export.far and import.far comprise a simple rebuild system that converts a farBook into a text file containing a list of XML documents, one for each topic. The list can be used to build a new farBook or any part of one. The output can be emailed, of course, since it is just a text file. That's if you don't want to use the send/recv modules, for which some assembly is required.

indexer.far indexes part or all of your farBook so that farVIEW can provide full-text searching when you select the Files/Search menu item. The cool thing from an implementation point of view is that the indexing process builds another supporting farBook that contains only keys and links into the primary farBook. As part of the index and search process, there is a text file, called stop.wds, in the farVIEW directory, that lists the words that the indexer should ignore. There are a number of stop word lists on the internet, and you can make your own. Another farSlang module, words.far, can help you in this. As far as stemming is concerned, I am using an algorithm by Porter posted on the internet at http://www.tartarus.org/~martin/PorterStemmer: "This is the Porter stemming algorithm, coded up in ANSI C by the author. It may be be regarded as cononical, in that it follows the algorithm presented in Porter, 1980."

http.far implements a bare-bones HTTP server.

download.far will download a file from a specified URL

login.far is intended to provide a security frontend, but there isn't any backend as yet, so it is just good as an interesting code sample for now.

To run these modules, you first start up farVIEW, then select the farSlang/Run menu item. If you make changes to the code, be sure to also pre-select the farSlang/Debug menu item. That will make sure that the farSlang compiler recompiles the module before running it. There is a command-line way to run a farSlang module, but it still has some wrinkles, and I will upload more about that when it works properly.

While I am having fun writing farSlang modules, the reason I am including them in the farVIEW releases is to provide others a modicum of information about how to write farSlang. There is a HTML manual in the website subdirectory, and on my website, but it doesn't tell you how to interface to the farVIEW library, which is now up to about 3380 APIs at this point.

BTW: the APIs are listed in the farslang.xml document, which comes with the release.

This entry was entered using Amaya 9.2.2., which will take me some getting used to.


2004/05/02 pjm

* Added the ability to send mail from a farVIEW topic. Set the Source property of a topic to the email address, using the following form:

mailto:<email-address>


Here is an example:

mailto:paul@bigbucks.com

The code for this uses the program that is the default "Open " program for the "mailto:" prefix, so, if it doesn't work for you, check to see what is assigned to open it. Don't ask me how you tell, though. I don't actually know. If you do, tell me, I would appreciate knowing.

* Fixed a couple of bugs, one a crash, the other just irritating:
* There is still a bug in the editor that seems to happen when the editor is in word wrap mode and you are typing near the end of the text. I haven't gotten it to occur regularly enough to debug it yet.

* Added the ability for a farSlang  module to use Microsoft's iDispatch interface to COM software. Here are some example calls:


module sampleiDispatch

   -- Open a document window in Word.
   var wrd  := CObject("Word.Application")
   var docs := wrd.Documents: CObject
   var doc  := docs.Open("c:\\My Documents\\test.doc"): CObject

   -- Same thing on a single line
   CObject("Word.Application").Documents:CObject.Open("c:\\My Documents\\test.doc")

   -- Create a text file containing a single line of text
   var fso  := CObject("Scripting.FileSystemObject")
   var file := fso.CreateTextFile("c:\\comtest.txt", true, false): CObject
   var file := fso.OpenTextFile("c:\\comtest.txt", 2, true): CObject
   file.WriteLine("This is the only text line in this file")
   file.Close

   endModule sampleiDispatch

Notice the use of the new CObject type to connect to the iDispatch object.  All the variables in the sample code are CObject objects. The iDispatch interface does present a problem to the farSlang problem, however. The farSlang compiler requires that it know the type of all values at all times, and, an expression like wrd.Documents does not have a discernable type to farSlang.

Consider an abbreviated version of that sample line:

   var docs := wrd.Documents

As the compiler compiles this line, it is left in the air about the type it should assign to the variable docs. wrd.Documents is not a symbol the compiler knows, so it cannot deduce its type. But farSlang is a strongly typed language, so a line of code such as this presents the farSlang compiler with a problem: it must know the type of the variable to assure the validity of subsequent use of the variable. The simple solution to this problem is that, since the programmer knows, she can (and must) pass that information on the the compiler. She does this by adding the type information to the symbol in question., as in

   var docs := wrd.Documents: CObject

Not only must thecompiler be kept informed of a variable's type, but it also must be informed every step of the way through a complicated expression as in this code:

   CObject("Word.Application").Documents:CObject.Open("c:\\My Documents\\test.doc")

If the :CObject type not been assigned to the Documents symbol here, the compiler would not have known that Open is an iDispatch method of the Documents object.



2004/02/03 pjm

Added the ability to run a farSlang module from the command line or a shortcut making farVIEW now available as a scripting shell. The following example demonstrates its simplist use:

   farview run=calendar

This command loads farVIEW as a scripting shell and executes the farslang module, called calendar.far.run= is is an example of a named argument.

You can place positional arguments to the module to be run on the command line as in the following example:

   farview run=calendar March 2004

The run= named argument does not occupy a particular position and can appear anywhere among the command-line arguments. It reads better in the first position, though.

Currently, run=, compile=, and decompile= are the only named arguments recognized by farVIEW. Named arguments are not currently available to farSlang modules. There must be no spaces between the name, the equal sign, and the value. If the value contains spaces, it must be surrounded by quotes.

When running in the scripting shell mode, the full farVIEW environment is available to the the farSlang module. Take a look at the calendar.far module for a simple example.

Note: the current version of calendar.far does not accept arguments as in the above example, but they are available through the System global. For example, to obtain the two arguments in the above command line, write something like the following sample code:

   glb System: CSystem
   ...
   var month := integer(System.Args.Arg(1))
   var year  := integer(System.Args.Arg(2))

In the above command line, month would be "March", and year would be 2004. The System global is discussed in several places below this entry in this document.



2004/01/09 pjm

It has been a long time since I worked on farVIEW to any significant extent as you can see by the last entry date. But I thought I would check out farVIEW's supposed ability to act as a HTTP server. I wrote a small bit of farSlang to handle the HTTP Get command. (you will find this code in the farSlang module http.far.)

   proc get
      glb System is CSystem

      -- Get the URL from the first header line
      System.CommHeaders.GotoHead
      var s := System.CommHeaders.StrItem

      -- Get the file name of the specified resource
      var rec := CRecord(' ' + s)
      s := rec.GetField(2)
      if pos('/', s, 1) = 1 then
         s := after('/', s)
         endIf
      if s = '' then
         s := 'default.htm'
         endIf
      s := 'wwwroot\\' + s

      -- Return the resource to the client
      var result := CCommResult(false) -- don't wait
      var body   := CBlock
      body.Load(s)
      System.Comm.SendMessage(System.SessionID,
                              "ACK",
                              "",
                              "200 OK",
                              "",
                              body,
                              closeConnect,
                              result)
      endProc get



and added the following sub-element to the <comm> element in the preferences file (farview.fix):

    <http>
      <connect/>
      <delete/>
      <get>|http|get</get>
      <head/>
      <post/>
      <put/>
      <trace/>
    </http>

I started farVIEW up, and then tried it out by directing my Mozilla browser to the following URL:

   http://localhost:8000

Of course it didn't work. After some debugging though, it now does work, and farVIEW can now serve the farVIEW manual from the subdirectory called wwwroot under the farVIEW directory. That includes the gif-files. There are still some reference counting problems, which I will try to straighten out in the next couple of work sessions (nights).

I haven't finished the case management tool I described last April. I decided that farVIEW is not really stable enough to expect someone to depend on it to make a living.



2003/04/26 pjm

My wife is a case manager in the health industry, and works from home. She has an enormous amount of paperwork that she has to do, and I have been wanting to help lighten her load for months. Yesterday, I finally decided that farVIEW should be ready for her to use. The farBook that I envision will let her organize the names of the many people and organizations she must deal with, provide tools to generate and track the many documents her company requires, help her track her billable hours, and spin off directory and location information for her handheld for use in the field. A tablet would be a great platform for this application. Other functions will certainly come to mind as the project unfolds. There are products that do these things, but, by using farVIEW for the application, I get the added benefit of cleaning up bugs; and I know how to expand this tool as she needs features that other tools would not provide.

Here is the basic shape of the farBook:

    Home
        Activites
            To Do
        People
            Clients
            Lawyers
            Physicians
        Tools
            Documents

As she gets new clients, she will add new topics, one for each client, to the Clients topic. She will do the same for new Lawyers and Physicians. As activities and materials accumulate for each person, she will collect them as children of the corresponding topics. I wrote a farSlang module that is to be run by the Clients, Lawyers, and Physicians topics when the People topic is expanded. To keep them in order, she will set the title of each topic to the name of each client, last name first.

This farSlang module contains an event handler for the onAddChild event, to be run whenever a topic is added to the Clients, Lawyers, or Physicians topics. This event handler copies the form property from the parent topic to the new child topic, and it copies the contents of the parent topic to the new child topic. This sets up each new child so that its content is displayed through an appropriate form, rather than just an unstructured sheet.

Here is the code for the farSlang module:

    module parent
        glb System: CSystem

        proc addChild?                    -- event handlers must be boolean!
            var parent := System.Topic
            var child  := System.DragTopic

            -- Copy the form name
            child.SetForm(parent.GetForm)

            -- Copy the parent body list to the child
            child.SetBody(CStrList(parent.GetBody))

            -- Allow to add the child to the farBook
            return false
            endProc addChild

        System.Topic.SetEventContext(System.FarSlang)
        System.Topic.SetEventModule('parent')         -- name of this module

        -- Link the topic onNewChild event to the onAddChild handler proc
        System.Topic.SetEventProc(System.Topic, onAddChild, 'addChild')

        endModule parent

Not a lot of code, but, then, it doesn't need to do much. Note that farVIEW sends the onAddChild event after it has constructed an in-memory topic object, which includes a manifest and possible content, and before it has written the topic information to the farBook. Had the event handler returned true, the topic would not be written to the farBook.

In writing and testing this bit of code, along with the form, which I had adapted from the Patient form, which is in the install, I found several bugs in farVIEW, which I fixed. Most important was that farVIEW didn't save the data that was entered into a form. That was a big one.

While I don't have much to say at this point about the Activities topic, the Tools topic is intended as a "tear-off" TOC so that she can drag-and-drop individual person topics onto specific document topics. The farSlang event handler for the onEndLMBDrag event could then copy the document file to a work site, maybe use Word/Excel objects to fill in the person-specific information, then start Word or Excel so she can finish the document. It could also add a child to the person topic for that document so that she can later access the document easily. I haven't done this yet. The function will probably be implemented using JScript as well as farSlang, since farVIEW doesn't have the ability to access MS Automation objects yet. Would be very nice though.

I've written this to give an idea of how one might develop an application using farVIEW. I'm a bit on the sloping side of the learning curve, myself, and the project will be ongoing. I may have more to say in a later entry.
 



2003/04/06 pjm

With this release of farVIEW. I am introducing a new national pasttime: Xtump the Xhump. Here's how it's played:

  1. Divide the convival group into two teams, call them the Xhallegers and the Xhallanged.
  2. Mutually choose an XML file.
  3. Run farVIEW in the "usual" way.
  4. Through the farSlang/Run menu item, run the TXPATH farSlang script.
  5. When the script requests the XML document name, enter the name of the XML file you have chosen, then click the Ok button..
  6. When TXPATH requests the XML test expression file name, leave the name field empty, just click the Ok button.
  7. Use your favorite editor to display the XML file in a window.
  8. Now you are ready to play the game.
  9. Teams take turns xhallenging each other to obtain results that are possible. Award points for both xhallenges and XPath expressions for their difficulty and resourcefulness.
  10. The team with the most points after an agreed-upon time wins. the game.
Play this game at your next birthday party, wedding, or wake, if you can find another living person who even knows what XPath is. I haven't.

So, you may gather from the above that this release of farVIEW includes pretty much the full rendition of XPath 1.0 according to the W3C Recommendation dated 16 November 1999. Note that the CNode version has been removed from farVIEW.

Here is a list of the current XPath to-do's and limitations:

  1. evalDiv and evalMod - divide by zero causes XPE_DIVIDEBYZERO to be thrown. Will have to study up on real arithmetic.
  2. evalVariable - defined only for farSlang globals? Not yet supported.
  3. evallId - I didn't understand the recommendation entirely and was too sleepy to try too hard
  4. namespace - no namespace support in the DOM, so none in XPath either
  5. Unicode - doesn't handle the form &#nn;#nn; Does handle &lt; &ht; &amp; &apos; &quot; and &#xx; forms.
  6. XP_ALLNAME - evaluator doesn't handle the XPath case NCName:* yet.
  7. The readout order of a nodeSet during evaluation of a [predicate] is not always according to the recommendation. I will fix this.
  8. I am considering a nonstandard feature of allowing to extend an XML document when specified nodes are missing during child-axis traversal for the SelectSingleNode() API only. I don't see any problem with this, but will think on it for awhile before adding the feature. It should be ok with caveats.
Other things I've done to the code base lately:

2003/03/29 pjm

The spec-version of XPath is almost completed. The code is virtually complete, and I am testing it now. This is a part-time endeavor so it does take more time than I would like. I have added an additional API to the two described below. The Evaluate() API allows to use the XPath processor to obtain results as booleans, numbers, strings, or nodesets.

    CXPath.SelectSingleNode:CNode(node: CNode, path$)
    CXPath.SelectNodes:CNodeList(node: CNode, path$)
    CXPath:Evaluate:CXPathItem(node: CNode, path$)

The CNode versions remain in the farVIEW build for now until XPath is fully debugged.

Here is a farSlang module showing how to access the results of a CXPath:Evaluate call:

module sample
   -- Load an XML document
   var dom := CDocument
   dom.Load('data.xml')

   -- Create an XPath object and use it to evaluate an XPath expression against the XML document
   var path := CXPath
   var item := path.Evaluate(dom, XPath_expression)

   -- Make sure the results are valid
   if   not valid(item) then
      CMessageBox("XPath Test - No Item Returned", "Error = " + path.Error, FWW_ATCENTER | FWW_OK).Run

   -- Handle the nodeSet (in a CNodeList object) returned by the evaluator
   elif item.Type = XP_NODESET then
      var nodes := item.NodeSet

      -- Check for no nodes found
      if nodes.Length = 0 then
         CMessageBox("XPath Test - Nodeset Returned", "Empty", FWW_ATCENTER | FWW_OK).Run

      else -- Show the first node found
         var node := nodes.Item(0)

         var txt$
         if valid(node) then
            if node.NodeType = ELEMENT_NODE then
               txt := '<' + node.NodeName  + '> (' + string(nodes.Length, 1) + ')'
            else
               txt := '<' + node.NodeValue + '> (' + string(nodes.Length, 1) + ')'
               endIf
         else
            txt := 'No match for <' + exp + '>'
            endIf
         CMessageBox("XPath Test - Nodeset Returned", txt, FWW_ATCENTER | FWW_OK).Run
         endIf

   -- Handle String returned
   elif item.Type = XP_STRING then
      var val := item.String
      CMessageBox("XPath Test - String Returned", val, FWW_ATCENTER | FWW_OK).Run

   -- Handle Number(type is %) returned
   elif item.Type = XP_NUMBER then
      var val := string(item.Number)
      CMessageBox("XPath Test - Number Returned", val, FWW_ATCENTER | FWW_OK).Run

   -- Handle Boolean returned
   elif item.Type = XP_BOOLEAN then
      var val := string(item.Bool)
      CMessageBox("XPath Test - Bool Returned",   val, FWW_ATCENTER | FWW_OK).Run
      endIf

   endModule sample

Added a new user command, called Cross,  to farVIEW in the RMB drag and drop menu that performs a bidirectional link between the drag topic and the target topic. Not only does the drag topic become a child of the target topic, but the target topic also becomes a child of the drag topic. farVIEW currently allows the user to expand crossed topics indefinitely. Will probably put a stop to that at some point. If you have nothing better to do with your time, feel free to see how long it takes for farVIEW to die in that particular way.



2003/03/15 pjm

Not much that's new except that the farVIEW download is now a real install file instead of just a zip file. The install program is set not to wipe out your working files if you have previously installed farVIEW. However, they are written to the backup subdirectory, in case you need them.

I'm using the Inno Setup Compiler, version 3.0.6 (b) by Jordan Russel. His homepage is http://www.innosetup.com. It is easy to use and more than enough for farVIEW's installation needs.

I am working on an implementation of XPath. This is a significant undertaking, but it's fun, and I am understanding the XPath spec a whole lot better than I did when I could have used the knowledge writing XSLT scripts a couple of years ago. I have written a parser that works fine on almost all the XPath examples in Michael Kay's book, XSLT Programmer's Guide, Copyright 2000, from WROX Press. I got the traversal code for 12 of the 13 axes written last night (no namespace axis, which the farVIEW DOM doesn't yet support anyway).

Added a System.Parameter$ property. This supercedes the discussion below (2003/02/26) about how to obtain the call parameter from farSlang code.



2003/02/26 pjm

The latest update to the download includes mostly bug fixes, but there are some issues of interest:

* Converted the preferences file (farVIEW.ini) from a conventional ini-file to an XML file. There is no DTD or schema for it. The DOM code is working well.

* Added two methods (borrowed from MSXML) to the CNode class to support a stripped-down version of XPath:

      CNode.SelectSingleNode:CNode(path$, extend?)
      CNode.SelectNodes:CNodeList(path$)

The extend parameter, when true, makes sure the specified path exists, even if it didn't before the call. This may prove troublesome later, but for now it is very convenient.

One of the limitations (a very big one)  is that predicates are always true. The general form of what is supported is something like the following:

    path ::=     [ "/" ] [ "/" ]  step { "/" [ "/" ] step }
    step ::=     [ axis :: ] nodetest [ "[" predicate "]" ]
    axis ::=     "ancestor" |
                 "ancestor-or-self" |
                 "attribute" |
                 "child" |
                 "descendant" |
                 "descendant-or-self" |
                 "following" |
                 "following-sibling" |
                 "namespace" |
                 "parent" |
                 "preceding" |
                 "preceding-sibling" |
                 "self"
    nodetest ::= nodename |
                 "@" attributename |
                 "*" |
                 "node()" |
                 "text()" |
                 "comment()"
    nodename ::= attributename | elementname
    predicate not supported.

This is nowhere near what the XPath spec allows. You can read tutorials at various XML sites for how XPath works, just remember that predicates are always true in farVIEW for now. It was still useful in getting values in and out of the preferences document.

* Changed the names of the colors in the Forms Color= and BackColor= attributes to not use the programmer's FWG_ prefix.

* Added farSlang event handler support to the widgets that make up the Forms subsystem.

* Added the user ability to mark text in the text window using the right mouse button and choose to associate the marked text as a keyword or keyphrase to the topic for use with the search function.

* Added the System.Menu:CMenu property. (See also, 2002/04/01 below) This property is valid when handling OnRMBUp events and references the RMB context menu. The farSlang event handler can modify the menu before it is displayed. I'll publish more on this later. (Like an example would be good, Paul.) The System.Menu property is also valid when handling the OnEndRMBDrag event and references the RMB drag-n-drop menu. Note that the content of these menus depends on whether the drop target is in a text window or a TOC window. You will find the methods to manage menus in the classes CMenu and CMenuItem enumerated (but not documented) in the farSlang.XML file. That's all that is available for documentation at this time. A forthcoming example will provide some how-to.

* Cleaned up the farSlang run capabilities of topics. You can now use the Source and Run topic manifest properties to run farSlang code. Which of the two properties you use determines when the farSlang proc is executed: when you use the Run property, the specified farSlang proc is run (after compilation, if needed) when the parent of the topic is expanded. When you use the Source property, the proc is run (again, after compilation, if needed) when the topic is opened by, for example, double-clicking the topic with the mouse.

These two moments in the visible life of a topic are important opportunities for an enterprising topic.When a farSlang proc executes as the topic is instantiated during parental expansion (the Run property), it gives the topic an opportunity to "arm" itself to handle possible incoming events for the remainder of its visual existence. This allows the topic to become an active participant in the farVIEW session. On the other hand, when a farSlang proc executes when the topic's content is accessed (the Source property), the topic can exhibit deviant behaviours in lieu of presenting its content. Note that you can suppress farSlang execution by checking the farSlang/Ignore Events menu item on the main menu bar.

BTW: none of these things happen when farSlang code loads a topic into memory.

The Run and Source properties can contain a farSlang proc invocation specification of the form:

    "|" modName "|" procName "|" parameter

where
    modName is the name of a farSlang module
    procName is the name of a visible parameterless proc within the specified module
    parameter allows you to pass a string to the proc.

Be sure to use the vertical pipes before each field as needed.

The procName and parameter fields are optional, in which case only that part of the module code that is outside any proc is executed. If the procName is specified, it must reference a proc that is visible (no tilde (~)) and has no parameters. If the parameter is specified, the farSlang runtime stores the parameter value in a global, called parameter$.

When a parameter is specified, farSlang code can access the global after first declaring it, as in the following example:

    module sound
        glb System: CSystem
        glb Parameter$
        CSound.PlaySound(System.App, Parameter, "", 0, FWA_SYNC, 0, 0)
        endModule

(Note that there is no error checking in this example, so it would be good if the parameter contains the name of a wav-file.)

When the farSlang proc relinquishes control back to farVIEW by exiting, the module can no longer count on the value of the Parameter global, since it may be reused when running other modules later. If you need its value for event handlers later on, copy it into a module variable as in this fragment:

    glb parameter$
    var myParameter := Parameter

The following would invoke the sound module shown above when the parent of a topic is expanded if in the Run property, or when the content is accessed if in the Source property::

    "|sound||sound2.wav"

assuming there is a file called sound2.wav in the farBook directory. Note the empty procName field. See the sample in the Forms farBook.

With the functionality now available to farVIEW topics, we can soon start creating topics that act as waystations, community centers, postoffices, newsposts, auctioneers, mailboxes, and other message-handlers. A topic can now remain passive, or become an active participant - an agent, if you will. For example, soon, you will be able to drop a file or topic onto a mailbox topic and expect a correspondent to receive the dropped information (or a link to the information) over the internet or LAN.



2003/01/15 pjm

Ok, it took a little over a week to get the forms cleaned up (see previous entry). And, they still aren't cleaned up since I  completely rewrote them as platform-independent widgets as children of the CFormWindow class. The new forms subsystem has been (is) a major project. I could spend all my time adding more and more widgets. The popup menu and combobox widgets are the most needed at this point.

There are a number of sample form files (look for *.frm files in the main farVIEW directory.) Not all of these work, and some of them may cause farVIEW to bomb, and a couple of them appear not to do anything.. But there is a fair amount of XML in the .frm files for examples. There are a few problems and bugs remaining, but, generally, they are pretty clean. As an exercise, you can play with the patient.frm data-entry form and polish up the elements in the second tabpanel. I have already done the elements in the first tabpanel as an example.

I have added a couple of nice farSlang modules that demonstrate how to handle the onPaint event: edges.far and shades.far. Try running them through the farSlang menu (farSlang/Run/ModName: "edges"/Ok), and also look over the code using the forms farBook. The samples show how easy it is to handle events in farSlang. Also, there is the dateTime.far module to demonstrate the use of the CTimer object.

Over time, I have noticed a few little show-stopper bugs in the text editor and in the tear-off topic window facilities. I need to fix these, but they have been elusive to pin down.

There are small sample farBooks in the release: sample.vue and forms.vue. Make shortcuts that run them using a command line like

    c:\farview\farview.exe sample.vue
or
    c:\farview\farview.exe forms.vue

For peculiar reasons, you can't run farVIEW from a command line. I'll work on this sometime.



2002/10/30 pjm

I have not made a release of the farVIEW program since April. I did virtually no work over the Summer, but this changelog does reflect what I am currently doing. I intend to make a release as soon as I clean up the forms. That should be within a week or two, as long as my interest holds up.

An aside: a big problem with doing a project like this off in the boonies is that there is no dialog, just a monolog with myself. I don't know how to get any attention for this project. I don't want to make it Open Source for a variety of reasons, at least for now, but I would love to have feedback. I guess the fact that it isn't OS would leave Slashdot out as a possible venue. But it is free. I haven't tried. I think I hesitate because there is "always one more thing" that needs to be done before I could possibly consider it worth presenting to others. (other than my friends, of course)

The rest of the TBD list here will be for the next release, or so.

* TBD (New section - I'll try to add a TBD to keep some focus on where I'm heading)



2002/10/27 pjm

* Added tabbed windows. Using a tabbed window in a form, you can construct an organized presentation of lots of information. The tabbed window actually comprises five different window classes:

  1. TabBox window contains the Tabs and TabPanels windows
  2. Tabs window contains the Tab button windows
  3. Tab buttons select TabPanel windows
  4. TabPanels window contains the TabPanel windows
  5. TabPanel window contains widgit windows to display information
* Changed some nomenclature throughout the online documentation.: * Added new event handling support to farSlang. There is now support for three classes of events:
  1. Topic events (not new). See Topic Events.
  2. Form events (new with forms). See Event Attributes in the Forms manual.
  3. Window events (that's new). See farSlang Event Handlers.
* Added User-controllable display ordering for topics. See Topic Properties.
2002/04/01 pjm

* Added support for the fars and cache directories. The fars folder is created by the pkunzip install while the cache folder is generated by farVIEW when it is needed. Be sure that you choose to install all subdirectories when you use WinZip to unzip the package file.

* Fixed the compiler to correct an error in allowing functions and constructors to be used as procedures and dot-operands as in

     System.Body.GotoHead

(Body is a "getter" function and GotoHead is a boolean function)

     CSound.PlaySound(System.App, "c01a015h.wav", "", 0, FWA_SYNC, 0, 0)

(CSound is the default constructor (i.e., no parameters))

* Found a situation when the compiler under-calculated the maximum size of the stack because of the way lbj instruction was back-patched over a pre-generated nix instruction at the end of parsing a procedure call. By the time the lbj was back-patched at the end of the parse, the running size of the stack was smaller that its maximum due to expression parameters. I decided to increase the stack size on the nix instruction even though it might later prove to create a slightly larger stack than is absolutely necessary. The following code caused the problem.

    CMessageBox("title", "message", FWW_ATCENTER | FWW_OK).Run
insts:   nix      lstr      lstr        lit          lit
  sz1 =   0         1        2           3            4
                                          \___opi____/    lbj
                                               3           4 => 4 (too small by one entry)

  sz2 =  (1)        2        3           4            5    5 => 5 (just right)
                                          \____4_____/

sz1 = old stack height calculation, sz2 = new stack height calculation. I used to ignore the nix (no-operation) and count the lbj (load object). Now I count the nix and not the lbj, since I can't trust the stack height by the time the lbj comes into play.

* Found that the interpreter pushes doubles and strings onto the stack without deleting them afterwards. Big memory leak. Fixed this by adding delete[] statements to the library interface routines in farslang.inc. But I still need to check out other types of calls, such as inter-module calls, and farslang class calls.

* Added remote file support with a new class: CRemoteFile, which is derived from CFile. This class handles remote files by copying them to the local cache (OpenInput, OpenAppend), then opening the cache copy for local file operations. When the file is closed, it is sent back to the host (OpenAppend, OpenOutput) as needed. Also added two methods (SendFile, ReceiveFile) to transfer between the local machine and a host machine. Added two new host commands: SF (sendFile) and RF (receiveFile), which are implemented in CServer. These commands support files that are larger than the transfer buffer size (32k).

* Added CFile::NewFile() static method to examine the file name and construct the appropriate CFile or CRemoteFile object.

* Added a CSystem object, called System, for farSlangers to access the current farVIEW environment as a global. Access System with the following global declaration:

    glb System: CSystem

You can then access various farVIEW objects as properties of System.

    System.App: CApplication              -- farVIEW application object
    System.Args: CArgs                    -- command-line arguments object
    System.Book: CBook                    -- active farBook object
    System.BookName$                      -- active farBook name
    System.BookPath$                      -- path to the active farBook
    System.CachePath$                     -- path to the cache folder
    System.Comm: CComm                    -- communication interface object
    System.CommBody: CAtom                -- received message body (server)
    System.CommHeaders: CStrList          -- received message headers (server)
    System.Console: CConsole              -- console window
    System.CurrentPath$                   -- ???
    System.DragTopic: CTopic              -- valid only after a drag operation
    System.Event: CEvent                  -- valid only after a received event
    System.ExecPath$                      -- path to the farVIEW executables folder
    System.FarsPath$                      -- path to the farSlang library folder
    System.FarSlang: CFarSlang            -- farSlang environment object
    System.ParentTopic: CTopic            -- parent of the selected topic
    System.Prefs: CPreferences            -- farVIEW.ini object
    System.RootTopic: CTopic              -- root topic in the Contents window
    System.ServerIP$                      -- farVIEW server URI (TBD)
    System.ServerPort#                    -- farVIEW server listener port (TBD)
    System.SessionID$                     -- ID of server session (server only)
    System.TargetTopic: CTopic            -- valid only after a drag operation
    System.Topic: CTopic                  -- selected topic
    System.UserName$                      -- farVIEW user name
    System.Window: CWindow                -- active window object

    -- Factory-type object builders
    System.NewFile(fileName$): CFile      -- Create a CFile object for a local or remote file.
                                          -- The fileName of a remote file begins with either
                                          -- "http://" or "far://".
    System.NewBook(bookName$): CBook      -- Create a CBook object for a local or remote farBook.
                                          -- The bookName of a remote book begins with "far://".
    System.NewWindow(parent: CReceiver,   -- Create a CWindow object based on the type parameter.
                     windowType#,
                     rect: CRect,
                     attr#,
                     title$)

Note that all System properties are read-only for farSlangers. To use a System property object, you have to look at the documentation for it, which is pretty scarce at this point. The best I can suggest for now is to look at the files farslang.sym and farslang.xml. The XML file will eventually become the source for an online farSlang library document, since it is automatically generated, and it encompasses the entire library; but it currently lacks natural-language descriptions of the interfaces. This may make using the library very difficult for now. I will turn my attention to this problem in the near future.

* Converted all XML server far commands to the form:

     <fareq op=".." user".." ... />

This will allow me to hide all command information in the body, which will eventually be encrypted and authenticated to help eliminate(?) spoofing, etc. Note: all is plaintext for now.

* Added a new window called CFormWindow to act as the primary window in a form-controlled display. It derives directly from CWindow and adds an onEvent method to deal with scripting events. See below.

* Added farSlang event handling to farVIEW forms with a new element.

     <script src="modName" />

modName must specify a local file.

The following is a list of the event attributes recognized as form events:

    ONBLUR            the window is losing focus
    ONCLICK           the mouse was clicked on the button
    ONCLOSE           the window will be closed immediately
    ONCOMMAND         a command key was pressed
    ONDBLCLICK        the mouse was double-clicked in the window
    ONFOCUS           the window is gaining focus
    ONINPUT           a key was pressed
    ONLOAD            the form has been loaded
    ONMOUSEENTER      the mouse has entered the window
    ONMOUSELEAVE      the mouse has left the window
    ONMOUSEMOVE       the mouse has moved in the window
    ONLEFTMOUSEDOWN   the left mouse button was depressed
    ONLEFTMOUSEUP     the left mouse button was released
    ONRIGHTMOUSEDOWN  the right mouse button was depressed
    ONRIGHTMOUSEUP    the right mouse button was released

* Added a CSystem object as a farSlang global that provides a farSlang module with a source for the current state of the system. It contains a number of properties, such as references to the application object, the preferences container, the comm object, and the current book object, among other properties.



2002/02/28 pjm

* Implemented CEditWindow::onEditCut, onEditCopy, and onEditPaste. Also added onEditClear, onEditDelete, and onSelectAll. Still need to add onEditUndo. Also implemented RMB menu for CEditWindow. Behaviour of  RMB is same as Borland IDE, which is similar to Word 97, except that  the latter does not obtain a context menu while the IDE and farVIEW do. In keeping with normal Windows behaviour, RMB no longer selects text in CEditWindow, it only pops the context menu.

* Fixed text wrapping problem for some edit commands in CTextWindow.

* Fixed bugs in CTextWindow update function (CFarVIEW::UpdtBody) so that it doesn't bomb and actually does the update it's supposed to.

* Fixed active window problem in CTreeWindow that caused the label popup to appear even when the window was not active.

* Added CRadioButton and CGroupBox to the family of windows in the farWin library. CCheckBox is the base class of CRadioButton. Included an ability to link a group of checkboxes and/or radiobuttons together by identifying them by a common keyword. Added a notification to CCheckBox to indicate that the state changed to on for a "linked" CCheckBox. Also added code to CWindow to handle the notification by setting the state of all other CCheckBox children to the off state. To summarize, to link a group of sibling CCheckBox or CRadioButton widgets together, simply give them all the same link string. That will cause their parent to turn off all the other children having the same link string as the child that was turned on.

* Revamped CAcceptDialog to support CRadioButton and CGroupBox. To use the groupbox, place a "G"-entry before the radio buttons to be grouped, and an "H"-entry following them. The radio buttons will operate in the one-on-only mode whenever they are placed within a  groupbox in the accept dialog. See accept.far for how the Search dialog is constructed. Added ability to hide the title of an edit window. Add a "!" in the type field to hide the title. While the  title will not appear in the dialog, it is still used to obtain the value of the edit window. See sample code in accept.far for an example of a groupbox and radio buttons.

* Added tool tips to CWindow. To add a tool tip to any window, simply pass the tooltip string to the window using the SetToolTip() method. To kill the tool tip, pass an empty string as the parameter. Also added "toolTip=" attribute to forms (~XUL) window elements.

* Continued work on the farVIEW Communications Library documentation with sample farSlang code to demonstrate how to implement a simple Remote Procedure Call.

* Uploaded a new farVIEW zip incorporating these changes, except for the RPC stuff. I'm finding some bugs in the farSlang environment initialization code that still needs to be resolved, so stay tuned on that. Generally, I have not tested the farSlang sample code that I am including with this release yet. I'll get to it soon. so just look at the farSlang as coding samples for now. You can try them but no guarantees.



2002/02/27 pjm

* Uploaded corrections to Searching along with new dialog images


2002/02/16 pjm

* Uploaded the farVIEW executable library as a zip-file to the internet.