I’m using pdf images as the background of electronic forms. The purpose of doing this is to make the electronic form feel just like the familiar paper one. It’s user friendly. Also the electronic forms can perform calculations automatically and accurately.

WHY A WIDE STRING?

One of the cases that inevitably has to be handled is when a string has to be entered, with its characters equally spaced in a sequence of contiguous boxes, like this:

THE COCOA WAY

Cocoa has this nifty NSString method, drawAtPoint, that lets you do this when the field is not active. (But when it is active you can enter the string – unformatted – in the text field, which exactly covers the boxes in the background, so it all feels quite natural.)

- (void)drawRect:(NSRect)rect
{
    if ((![self focus]) && ([self format] == kWideFormat))
    {
        // drawWideString calculates the bounds for each character
        // and calls a routine to draw it using drawAtPoint.
        [self drawWideString: [self stringValue]];
    }
    else
    {
        [super drawRect:rect];
    }
}

THE CAPPUCCINO WAY

Unfortunately, there is no -[CPString drawAtPoint] method in Cappuccino, so this approach can’t be used.

I must confess that this “deficiency” left me with some confusion about how to procceed to implement the WIDE string behavior in Cappuccino.

I wondered if there was a way to do it using Canvas or CSS, or if Cappuccino text support for this kind of thing might be “just around the corner.”

And the sledgehammer approach of creating a sequence of single character text fields to display the inactive text, to be swapped-out with a regular text field while editing, seemed inelegant.

But a recent conversation with @saikatc at #shdh37 convinced me that the “buffered” approach was, in fact, a reasonable way to do this. And as it is with so many things in life, once the approach was determined, it started happening.

KEY MECHANISM

The one CPTextField subclass I use throughout the forms project overrides becomeFirstResponder / resignFirstResponder to bracket the active field with controlTextDidBeginEditing / controlTextDidEndEditing calls, something that neither Cocoa nor Cappuccino does, but which is critical to knowing when to swap the static text array in and out with the regular text field. Having this mechanism obviates the need for a special CPTextField subclass for these WIDE fields!

The Begin/End Editing messages are passed to the Text Field’s delegate, a widget subclass, which sends setFocusedDisplayFormat/setUnfocusedDisplayFormat messages to the object being activated/inactivated.

It’s important to note that the approach used here takes advantage of fact that the text field covers the char-array. If this were not the case, it would be necessary to buffer the char-array’s stringValues, so they wouldn’t be displayed, while the text field was active. That would be confusing.

So to avail ourselves of this pattern, we create a WIDE Widget subclass which switches the display of the static array on and off.

Here’s the code for that class.

PDQWideWidget descends from the concrete PDQTextWidget class and adds an array for the equally spaced characters.

// PDQWideWidget.j

@import "PDQTextWidget.j"

@implementation PDQWideWidget : PDQTextWidget

{
	CPMutableArray chars @accessors; // The array of equally spaced characters
}

Init calls super, then creates the array.

- (id) init
{
	self = [super init];

	if (self)
	{
		// Do any initialization here!
		chars = [];
	}

    return self;
}

makeView is overridden to create the array of one-char text fields. The order in which the constituent fields are created is crucial. The real CPTextField is created last, so it will be on top and receive mouse events. And the widget is put into “unfocused” mode.

- (void)makeView:(CPView)itsSuperview
{
	[self buildChars:itsSuperview];

	[super makeView:itsSuperview];

	[self setUnfocusedDisplayFormat];
}

buildChars builds the array of one-char text fields using the maxLen parameter to determine how many to create that will cover the widgetRect.

- (void)buildChars:(CPView)itsSuperview
{
	var frameRect = [self widgetRect];

	var width   = frameRect.size.width;
	var height  = frameRect.size.height;
	var x	    = frameRect.origin.x;
	var y	    = frameRect.origin.y;

	var cellWidth = width/[self maxLen];

	for (var index = 0; index < [self maxLen]; index++)
	{
		var left = x + cellWidth * index;
		var charFrame = CGRectMake(left, y, cellWidth, height); // x,y,w,h

		var newCharField = [[CPTextField alloc] initWithFrame:charFrame];

		[self initCharField: newCharField];
		[newCharField setStringValue: @""];
		[newCharField setDelegate:self];
		[itsSuperview addSubview:newCharField];
		[chars addObject: newCharField];
	}
}

Each charField must be initialized to (among other things) not accept events nor become a responder.

- (void) initCharField:(CPTextField)aCharField
{
	[aCharField setBordered:NO];
	[aCharField setBezeled:NO];
	[aCharField setEditable:NO];
	[aCharField setEnabled:NO];
	[aCharField setSelectable:NO];
	[aCharField setAlignment: CPCenterTextAlignment];
	[aCharField setBackgroundColor:[CPColor clearColor]];
	[aCharField setDrawsBackground:YES];
	[aCharField setVerticalAlignment:CPCenterVerticalTextAlignment];
	[aCharField setFont:[PDQAbstractWidget getFont]];
}

When the text field is focused, compose and set its stringValue from the char-array. The TextField will be displayed over the char-array, masking it.

- (void)setFocusedDisplayFormat
{
	// Build the stringValue from the char-array

	var itsStringValue = @"";

	for (var index = 0; index < [chars count]; index++)
	{
		var aCharField = [chars objectAtIndex: index];
		var aChar = [aCharField stringValue];
		itsStringValue += aChar;
	}

	[[self attachedControl] setStringValue:itsStringValue];
}

When the text field loses focus, or is first created, unpack stringValue into the char-array, then clear stringValue. The equally spaced chars will be displayed, but the empty TextField covering it, will not.

- (void)setUnfocusedDisplayFormat
{
	// Set the chars from stringValue and then clear it.
	var itsStringValue = [[self attachedControl] stringValue];
	var count = [itsStringValue length];

	for (var index = 0; index < count; index++)
	{
		var aCharField = [chars objectAtIndex: index];
		[aCharField setStringValue: [itsStringValue characterAtIndex:index]];
	}

	[[self attachedControl] setStringValue:@""];
}

@end

After a moment of doubt whether my approach was simply wrong, I sucked it up and asked myself “What would Mike Ash do?”

So I jumped into the debugger, and after tracing the flow of execution – aided by liberal logging of intermediate results – I realized that I was seeing a cascading dependency problem.

I was adding a notifier for each cell reference in a formula, so when it had more than one reference to the same cell, I was creating duplicate notifiers. And if that cell was referenced more than once in another cell’s formula, there would be duplicated recalculations. This is what I was seeing*. And the problem could become arbitrarily worse than this, since there could be an indefinite coupling of such formulae. Ouch!

* Formula A, of cell a, has n references to cell b, who’s formula B contains m references to cell c. So when cell c changes, formula B would be recalculated m times and formula A would be recalculated m * n times.

The solution to this cascading dependency problem was to allow only one notifier for any cell reference in a formula, even if the cell was referenced more than once in that formula.

THE PATTERN

When a PDQ document is opened, its form widgets are “internalized.” One step in this process is, for widgets that have a formula, to add observers to cells referenced by that formula. This stack-trace depicts the widget internalization pattern.

-[PDQDocument windowControllerDidLoadNib:]
Code added here is executed when the windowController has loaded the document’s window.

  -[PDQDocument internalizeWidgets]
  This contains the widgets’ internalization logic.

    -[PDQDocument observeReferencedCells]
    This document method calls observeReferencedCells for each widget.

      -[PDQAbstractWidget observeReferencedCells]
      Adds notifications to observe each cell referenced by this widget.

        -[NSString coalesceObservers]
        Constructs the observer list and removes duplicates, before adding notifications.

THE CODE

Here is the add/coalesceObservers code associated with the widget internalization pattern.

observeReferencedCells creates an array of the referenced cell IDs. Then it finds the object referenced by each ID and adds an observer to it.

- (void) observeReferencedCells
{
    if ([self hasExpression])
    {
        NSMutableArray * observers = [[self expression] coalesceObservers];

        int index;
		
        for (index = 0; index < [observers count]; index++) // Work OK for empty array?
        {
            NSString * theToken =  [observers objectAtIndex:index];
            
            // iterate the document's widgets (a global variable)

            PDQAbstractWidget *referencedCell = [self findWidgetWithID:theToken];
            [self addObserverToReferencedCell:(PDQAbstractWidget *)referencedCell];
        }
    }
}

coalesceObservers constructs the observer list, avoiding duplicates, by copying one instance of each cellRef token into coalescedObservers before adding notifications

- (NSMutableArray *) coalesceObservers
{
    NSMutableArray * theTokens = [self createTokensForExpression];
    NSMutableArray * coalescedObservers = [NSMutableArray array];

    int index = 0;
    while (index < [theTokens count])
    {
        NSString * theToken = [theTokens objectAtIndex:index];

        if ([theToken tokenType] == eCellRefToken)
        {
            [coalescedObservers addObject:theToken];
			
            // Remove all occurrences of theToken from theTokens.
            [theTokens removeObject:theToken];
        }
        else
        {
            index++;
        }
    }

    return coalescedObservers;
}

When theReferencedCell changes value addObserverToReferencedCell tells the dependent cell to handleVariableChanged by sending the NSNotificationCenter a changed message.

The NSNotificationCenter then sends the observer a PDQReferencedCellChanged message with an object reference to the cell that changed.

- (void) addObserverToReferencedCell:(PDQAbstractWidget *)theReferencedCell
{
    NSNotificationCenter* nc = [NSNotificationCenter defaultCenter];

    [nc addObserver:self
           selector:@selector(handleReferencedCellChanged:)
           name    :@"PDQReferencedCellChanged"
           object  :theReferencedCell];
}

// Update the cell's value since a cell it depends on has changed.
- (void) handleReferencedCellChanged:(NSNotification *)notification
{
    [self recalculate];
	
    // Now say "changed" to tell the cells that depend on me to update also. 
    NSNotificationCenter* nc = [NSNotificationCenter defaultCenter];
    [nc postNotificationName:@"PDQReferencedCellChanged" object:self];
}

I found working with strings in Cappuccino to be more logical than in Cocoa, but I experienced some uncertainty about what methods and functions were available in JavaScript. So I thought this example and writeup might be useful to others, who are coming to Cappuccino from Cocoa, as many of us are.

One of the main differences between Cocoa and Cappuccino when working with strings, is that Cappuccino lacks a scanner class. So Cappuccino applications must handle scanning by themselves. I thought it would be useful and illustrative to implement a Category that performs scanning, similar to Cocoa’s NSScanner. And since JavaScript strings are toll-free bridged to Cappuccino’s CPString class that was not too difficult.

I’ve constructed my API as a Category, rather than as a Subclass, so it can be used with all CPStrings. It corresponds roughly to NSScanner, but doesn’t mirror it.

I’ve maintained a Cocoa-like style. This may change as time goes by, but for now it feels more readable, especially since I’m going back and forth between Cappuccino and Cocoa.

And I haven’t addressed performance issues in writing this. The code is adequate for my purposes. But it would be interesting to profile and optimize it somewhere down the line.

IMPLEMENTATION NOTE: I’m not currently supporting “skip characters.” That’s because the next scan position is determined by the length of the previously scanned string. If you skip characters there isn’t a simple way (that I could think of) to communicate this to the next use of the the scanner. Also all scans are case sensitive. An extended scanning category could add methods to support these. But for now, I’m avoiding that to keep things simple.

If you’re not familiar with NSScanner, it’s useful to note that the term “scan” means scanning from a particular starting point. That is, if you’re scanning for a particular string and it isn’t at the starting location of the string being scanned, then an empty string will be returned.

I’ll summarize the API here, but it will be much more instructive to view the source, which I’ve wrapped in a test program called cappscanner.

SCANNING METHODS

scanString – scans SELF, returning theString if a match is found.

    -(CPString)scanString:(CPString)theString startingAt:(int)startIndex

scanUpToString – scans SELF until a given string is encountered, accumulating characters into a string that’s returned. Scans to the end of SELF if stopString is not found.

- (CPString) scanUpToString:(CPString)stopString startingAt:(int)startIndex

scanUpToCharactersFromSet – scans SELF until a stopChar is encountered, accumulating characters into a string that’s returned. Scans to the end of SELF if no stopChars are found.

-(CPString)scanUpToCharactersFromSet:(CPString)stopChars startIndex:(int)index

scanCharactersFromSet – scans SELF as long as charsToScan are encountered, accumulating characters into a string that’s returned. Returns an empty string if no charsToScan are found.

-(CPString)scanCharactersFromSet:(CPString)charsToScan startIndex:(int)index

UTILITY METHODS

stringByReplacingString – replaces “target” with “replacement”, where “target” is a substring of SELF.

- (CPString)stringByReplacingString:(CPString)target withString:(CPString)replacement

setCharacterAtIndex – replaces the character at “index” in SELF.

-(CPString)setCharacterAtIndex:(unsigned)index theChar:(unichar)character

filterString – returns a copy of SELF filtering out the specified characters.

-(CPString)filterString:(CPString)charactersToRemove

stripPrefix – returns a copy of SELF without thePrefix. Does nothing if SELF doesn’t have thePrefix

-(CPString)stripPrefix:(CPString)thePrefix

stripSuffix – returns a copy of SELF without theSuffix. Does nothing if SELF doesn’t have theSuffix.

-(CPString)stripSuffix:(CPString)theSuffix

dropCharacters – drops numCharsToDrop from the end of SELF. Does nothing if charsToDrop > [string length]. Returns an empty string if numCharsToDrop == [string length]

-(CPString)dropCharacters:(int)numCharsToDrop

TEST RELATED METHODS

decimalTail – returns the tail of a decimal string.

-(CPString)decimalTail

formatNodecString – replaces the period in a formatted decimal string with a single space character.

-(CPString)formatNodecString

formatNosepString – removes commas and the period from a formatted decimal string.

-(CPString)formatNosepString

removeSurroundingParentheses – strips any leading or trailing spaces too. N.B. Won’t remove an odd parenthesis on one end!

-(CPString)removeSurroundingParentheses

parseScript – parses the if, then and else components of a script string. Notice how the scanner walks down the script using the cumulative offset of previously scanned components. This is illustrative of a repetitive scanning pattern.

-(void)parseScript

rectFromAnnot – converts the RECT string from a pdf annotation (e.g. RECT [432.97 580.92 441.86 589.95]) into a CGRect.

-(CGRect)rectFromAnnot

scanRect – scans the RECT string found in pdf annotations. Returns an array of strings for the left, bottom, right and top coordinates. Note that scanRect also employs a repetitive scanning pattern.

-(CPArray)scanRect

tokensSeparatedByCharactersFromSet – breaks the input string into an array of substrings.

-(CPArray)tokensSeparatedByCharactersFromSet:(CPString)separatorSet

SCANNING TESTS

When you double-click the index.html file and then click the “Perform Scan Tests” button in the Scan Tests window, a Cappuccino Run Log Window will appear that contains these statements:

  Performing scan tests.

  Testing Scanning Methods.

  Scan if-then-else script.

  script is =IF(L222<12000;3500*L106e;0)
  scriptIf = L222<12000
  scriptThen = 3500*L106e
  scriptElse = 0

  Scan pdf style Rect.

  Build CGRect.

  left = 432.97
  bottom = 580.92
  right = 441.86
  top = 589.95

  Testing Utility Methods.

  Test stringByReplacingString

  string A plus string B
  string A + string B

  Test setCharacterAtIndex

  1234567
  A2C4E6G

  Test stripPrefix

  Mr. Coffee
  Coffee

  Test stripSuffix

  String Jr.
  String

  Test dropCharacters

  123.45
  123

  Testing Test Related Methods.

  Test decimalTail

  1,099.87
  87

  Test formatNodecString

  1,099.87
  1,099 87

  Test formatNosepString

  1,099.87
  109987

  Scan tests complete.

“It works”

My thanks to the Cappuccino Community, and especially to the Core Team.

However, there is a change in behavior when setMaxSize is called.  The scroll bars persist at the maxSize position until both x and y are greater than maxSize.

With maxSize set, as you grow the window vertically, the horizontal scroll bar is fixed at the maxSize position and there is white space between the scroll bar and the bottom of the window.  Also, the vertical scroll bar is depicted as an empty, shaded, rect.

Once you make the window bigger than both maxWidth and maxHeight both scroll bars disappear and the window looks just like it would in the case where maxSize isn’t set.

In the case when maxSize isn’t set, as you grow the window vertically, the horizontal scroll bar is displayed at the window’s bottom edge with white space separating the bottom of the image and the scroll bar.  And if you make the window wider than the image’s width, the horizontal scroll bar disappears.

How do you constrain the window’s size? Do I need to do something in addition to setMaxSize? Is a different approach required to do this?

Here’s my AppController.j source code.

@import <Foundation/CPObject.j>
@import <Foundation/CPString.j>

@implementation AppController : CPObject
{

}

- (void)applicationDidFinishLaunching:(CPNotification)aNotification
{
    var kImageWidth  = 612.0,
        kImageHeight = 792.0,
            kMargin  = 16.0;

    // Create a window to take up the full screen

    var theWindow = [[CPWindow alloc] initWithContentRect:CGRectMakeZero() styleMask:CPBorderlessBridgeWindowMask],

        contentView = [theWindow contentView],

        bounds = [contentView bounds];

    // Create a scrollView to contain the pdf image

    var scrollView = [[CPScrollView alloc] initWithFrame:CGRectMake(0, 0, CGRectGetWidth(bounds), CGRectGetHeight(bounds))];

    [scrollView setAutoresizingMask: CPViewHeightSizable | CPViewWidthSizable];

    [scrollView setAutohidesScrollers:YES];

    // Create the image and imageView.

    var theImage = [[CPImage alloc] initWithContentsOfFile:[[CPBundle mainBundle] pathForResource:@"testImage.pdf"]];

    // Create the image view.

    var imageView = [[CPImageView alloc] initWithFrame:CGRectMake(0.0, 0.0, kImageWidth, kImageHeight)];

    // Put the image in the imageView.

    [imageView setImage: theImage];

    // We don't want the image to resize.

    // (Could have [imageView setAutoresizingMask:CPViewNotSizable | CPViewNotSizable] instead.)

    [imageView setImageScaling: CPScaleNone];

    // Put the imageView in the scroller.

    [scrollView setDocumentView:imageView];

    // Put the scroller in the window's view hierarchy.
    [contentView addSubview:scrollView];

    var maxWidth   = kImageWidth  + kMargin,

        maxHeight  = kImageHeight + kMargin,

        theMaxSize = CPMakeSize(maxWidth, maxHeight);

    [theWindow setMaxSize: theMaxSize];

    // Bring the window forward to display it.

    [theWindow orderFront:self];
}

@end


         ]]>
			http://frameworker.wordpress.com/2009/09/11/how-to-constrain-window-size-in-cappuccino/feed/
		0
	
		
			joely
		

		
			CPWindow
		
	
		
		
		http://frameworker.wordpress.com/2009/06/29/inside-pdqforms/
		http://frameworker.wordpress.com/2009/06/29/inside-pdqforms/#comments
		Mon, 29 Jun 2009 21:31:26 +0000
		frameworker
				

		http://frameworker.wordpress.com/?p=216
		]]>
			Overview

PDQForms is tax preparation software for State and Federal forms.  It integrates spreadsheet logic into pdf forms using PDFKit to combine form field information with labels and expressions.  The result is a spreadsheet-like application layer over the form.
Creating a PDQ Form
The idea was to automate

everything that could be.
The first step is to extract information for all the form’s fields, or “Annotations” in PDF lingo.
We need the type of Annotation: TEXT or CHECKBOX, and its PAGE, RECT and MAXLEN values.
This is accomplished with a PDFKit based program called PDQ Annotation Editor, which outputs a text file.
Next we must define expressions that contain the logic for each of the form’s fields.  This is just like programming a spreadsheet.
Adding this information to the Annotation meta-data completes our task.
We now have a text file containing the information PDQForms will need to automate the form.
We then “bake” this back into the original PDF file.
And the form can now be opened with PDQForms!

         ]]>
			http://frameworker.wordpress.com/2009/06/29/inside-pdqforms/feed/
		0
	
		
			joely
		
	
		
		
		http://frameworker.wordpress.com/2009/06/23/table-lookups-in-pdqforms/
		http://frameworker.wordpress.com/2009/06/23/table-lookups-in-pdqforms/#comments
		Tue, 23 Jun 2009 05:26:27 +0000
		frameworker
				

		http://frameworker.wordpress.com/?p=188
		]]>
			Since some tax forms use tables as well as formulae, I had to implement a tax table lookup algorithm.  Things were complicated by the fact that these tables were not always available in sorted format.

I first tried using the unsorted tax tables.  This required doing a comparison of each table entry until the proper tax bracket was found.  But tax lookup tends to occur whenever you change any numeric field on the form, since this usually affects taxable income.  So, doing a comparison for each entry, while easy, was way too slow!  Suddenly I was seeing a totally unacceptable delay.
The solution was to pre-sort the tables, shifting the performance burden completely out of the user’s work flow, and then to use an efficient, recursive binary search, algorithm to do the table lookup in PDQForms.
PREPARING A TABLE
Copy the table from the tax handbook into a text file and clean-out any patches of non-table data.  Fortunately, the topology of non-table data is amenable to doing this, and also, the table data consists of an integral number of tuples on each line.
Finally, filter-out commas, and prepend TUPLESIZE to the table.
The table we’re creating will have the same name as the form it applies to, but with a suffix that’s specified in the call to createTupleTable.  Here it’s “tax”.

    NSString * theTableContents = [self createTupleTable: theTableData named: @"tax"];


PRE-SORTING THE TABLES
1. Put the elements (NSStrings) of each tuple into an array (NSArray)
2. Put these tuples into an array so they can be sorted.
3. Sort the array of tuples, from smallest to largest, using “sortedArrayUsingFunction”

   and passing it the comparison function “sortByValue”:

    NSArray *sortedTuples = [tuples sortedArrayUsingFunction: sortByValue context: 0];

    NSInteger sortByValue(id tuple1, id tuple2, void *context)
    {
        double value1 = [[tuple1 objectAtIndex: 0] doubleValue];
        double value2 = [[tuple2 objectAtIndex: 0] doubleValue];
	
        if      (value1 > value2) return NSOrderedDescending;
        else if (value1 < value2) return NSOrderedAscending;
        else                      return NSOrderedSame;
    }


4. Convert the sorted tuples back into a single NSString.
5. Finally, “bake” the table data into the pdq file using PDFKit (10.5).
DOING TABLE LOOKUPS IN PDQFORMS
This stack-trace depicts the tax calculation mechanism:
[PDQAbstractWidget evaluateExpression: theTableLookup]

Table lookups are processed as a special case by evaluateExpression.

e.g. =TAXTABLE(“TAXTABLE”,”6″,INCOME,FILING_STATUS)

evaluateExpression calls doTableLookup. 
     [PDQAbstractWidget doTableLookup: theTableLookup]

     doTableLookup is analagous to evaluateFunction, but for tableLookups.

     doTableLookup packages the call’s parameters and calls “execute.”

     Note that quoted parameters are passed in as literal strings.
           [NSString+PDQFunctionAdditions execute: parameterArray]

           execute dispatches the call to taxTableLookup.
                   [NSString+PDQFunctionAdditions taxtablelookup: parameterArray]

                   taxTableLookup unpacks the parameters, finds the taxBracket

                   and uses it to determine the tax.
                         [NSArray+PDQTableAdditions taxBracket]

                         taxBracket is the recursive binary search algorithm,

                         initially called from taxTableLookup,

                         that does the “heavy lifting.”

                         taxBracket calls the helper routine taxInTuple
                     [NSArray+PDQTableAdditions taxInTuple]

                     taxInTuple tests to see if taxable income falls

                     within a bracket, to its left, or to its right.

                     If income isn’t in the current tax bracket

                     taxInTuple’s return value is then used

                     to seed recursive calls to taxBracket.
taxBracket and taxInTuple are shown below.

- (int) taxBracket: (double) income 
        tupleWidth: (int) tupleSize 
      startingWith: (int) firstTuple 
     andEndingWith: (int) lastTuple
{
    int tupleIndex = -1;

    int comparison;

    int middleTuple = firstTuple+(lastTuple-firstTuple)/2;

    comparison = [self taxInTuple: income 
                          atIndex: middleTuple 
                       tupleWidth: tupleSize];
	
    if (comparison == 0)
    {
        tupleIndex = middleTuple;
    }
    else 
    if (comparison == 1)
    {
        tupleIndex = [self taxBracket: income 
                           tupleWidth: tupleSize 
                         startingWith: middleTuple+1 
                        andEndingWith: lastTuple];
    }
    else 
    if (comparison == -1)
    {
        tupleIndex = [self taxBracket: income 
                           tupleWidth: tupleSize 
                         startingWith: firstTuple 
                        andEndingWith: middleTuple-1];
    }

    return tupleIndex;
}



// Tuples are laid out end to end as one long array.
// The first two items of a tuple are its income bracket.
// the trailing items are the tax for each filing status 
// in that tuple's income bracket.
- (int) taxInTuple: (double) income 
           atIndex: (int) tupleIndex 
        tupleWidth: (int) tupleSize
{
	int leftIndex  = tupleIndex*tupleSize;
	int rightIndex = leftIndex + 1;
	
	NSString * leftItem  = [self objectAtIndex:  leftIndex];
	NSString * rightItem = [self objectAtIndex: rightIndex];
	
	double leftValue  = [leftItem  doubleValue];
	double rightValue = [rightItem doubleValue];

	// Test if intervals overlap:
	// 
	// IF YES use <= for right value
	// IF NO  use <  for right value.

	// CA brackets don't overlap
	// they're [x,y] [y+1,z].
	// So when income is exactly "y"
	// we want to match the ONLY bracket containing "y",
	// not the higher of two brackets!
	
	// One even, one odd means the intervals shouldn't "overlap."
	if ((int)leftValue%2 != (int)rightValue%2)
	{
		if ((income >= leftValue) && (income <= rightValue))
		{
			return 0;
		}
	}
	else
	// IRS brackets are [x,y] [y,z] so when income is exactly "y"
	// we want to match the higher of the two brackets!
	{
		if ((income >= leftValue) && (income < rightValue))
		{
			return 0;
		}
	}

	if (income < leftValue)
	{
		return -1;
	}
	else
	{
		return 1;
	}
}



         ]]>
			http://frameworker.wordpress.com/2009/06/23/table-lookups-in-pdqforms/feed/
		0
	
		
			joely
		
	
		
		
		http://frameworker.wordpress.com/2009/06/23/how-i-test-forms/
		http://frameworker.wordpress.com/2009/06/23/how-i-test-forms/#comments
		Tue, 23 Jun 2009 04:58:31 +0000
		frameworker
				

		http://frameworker.wordpress.com/?p=184
		]]>
			OVERVIEW

The PDQForms Debug target contains a Debug menu with commands that are enabled if a PDQDocument is open.
  Read test file…

  Save test file…
The “Save test file…” command journals edited forms into test files.  The “Read test file…” command causes the test file to be read back into the current form, and verifies that values of the calculated fields are correct.  This allows for rapid regression testing of forms after making changes to the code base.
I TEST FILE
Test files have the same names as the forms they “exercise,” but with the suffix “test”.  
Test files are kept in the same folder as their corresponding “pdq” file.
The test file consists of FIELD_NAME, STRING_VALUE pairs, one pair per line.
II TEST COMMAND
Saving the test file writes out the form’s FIELD_NAME, STRING_VALUE data.
Reading the file back into the current form, populates each FIELD_NAME with its STRING_VALUE and causes that field’s dependents to update.
But if a STRING_VALUE read from the test file begins with an “=”, then it is an expected result and it will be compared to the calculated value of the form’s field, not stuffed into the form.
III TEST RESULTS
The test command logs descrepencies in calculated values:
“Unexpected value for calculated widget: ‘WidgetID’  shown: ‘itsValue’  expected: ‘itsExpectedValue’”
If there are no descrepencies, the test command logs the message:
“All calculated widgets have expected values  “
IV SUMMARY
Since the accuracy of calculations in forms is paramount, this simple but powerful approach solves an important problem.

         ]]>
			http://frameworker.wordpress.com/2009/06/23/how-i-test-forms/feed/
		0
	
		
			joely
		
	
		
		
		http://frameworker.wordpress.com/2009/06/23/expressions-in-pdqforms/
		http://frameworker.wordpress.com/2009/06/23/expressions-in-pdqforms/#comments
		Tue, 23 Jun 2009 04:50:30 +0000
		frameworker
				

		http://frameworker.wordpress.com/?p=178
		]]>
			I realize this document is pretty dry, but I needed to document this implementation to facilitate discussion with othere in the quest to improve it.  Without going into why I took the approach I did, I will say that I did become very proficient in using strings with Objective C  

I OVERVIEW OF EXPRESSION SYNTAX
Expressions may be FORMULAE (including BOOLEAN FORMULAE), FUNCTIONS, TABLE LOOKUPS or CONDITIONAL EXPRESSIONS.
Expressions are written in infix notation, just as you’d expect.  They consist of OPERATORS, OPERANDS, SEPARATORS and FUNCTION NAMES.
A. OPERATORS include BOOLEAN OPERATORS
==    <= or == or =>  != or   &&  ||  !
and ARITHMETIC OPERATORS
+  –  *  % (modulus)  ^ (exponentiation)
B. OPERANDS may be cell references or numbers.  Numbers are evaluated as double-precision floating point.
C. SEPARATORS include  (  )  ,  ;
The “=” character is prepended to all expressions, just like in VisiCalc.
D. All other tokens, those which are not OPERATORS, OPERANDS or SEPARATORS, are FUNCTION NAMES.
FUNCTION NAMES that end with “TABLE” are a special case.  They perform Table Lookups for forms that use Tax Tables.
II FORMULAE
Operands, within formulae, may be cell references or numbers.  Numbers are evaluated as double-precision floating point.
III BOOLEAN FORMULAE
Boolean Formulae, expressions that resolve to YES (1) or NO (0), are used in the scriptIf component of Conditional Expressions.  They aren’t used elsewhere at this time, but they could be.  Any positive number could be interpreted as YES, but we currently require “1″.
IV FUNCTIONS
Functions are snippets of code that get dispatched interpretively.
Function arguments may be formulae or can, themselves, be functions.
Quotes are used to transmit function (and table lookup) arguments as literals.
*Describe how a function gets added to PDQForms and the function dispatch mechanism.*

*Show the recursive function parsing routine.*
V TABLE LOOKUPS
Table Lookups are used to find income tax, for example, for Federal filers whose taxable income is less than $100,000.
See the blog post on TABLE LOOKUPS IN PDQFORMS for a more detailed description of how they’re implemented.
VI CONDITIONAL EXPRESSIONS
Conditional Expressions are of the form =IF(scriptIf;scriptThen;scriptElse)
(“IF” is a reserved word)
ScriptIf, a Boolean Formula, resolves to a value of zero or one.  If scriptIf resolves to 0, scriptThen is executed, otherwise scriptElse is executed.  ScriptThen and scriptElse can be Table Lookups, Functions or Formulae.
Conditional Expressions may not be “nested.”
VII LIMITATIONS
Expressions may not contain functions.  For now, if an expression needs an embedded function, an invisible widget, that calls the function, can be referenced from the expression.

         ]]>
			http://frameworker.wordpress.com/2009/06/23/expressions-in-pdqforms/feed/
		0
	
		
			joely
		
	
		
		
		http://frameworker.wordpress.com/2009/04/30/recommending-jordan-langille-iconographer/
		http://frameworker.wordpress.com/2009/04/30/recommending-jordan-langille-iconographer/#comments
		Thu, 30 Apr 2009 19:53:36 +0000
		frameworker
				

		http://frameworker.wordpress.com/?p=160
		]]>
			Jordan is an Artist and Iconographer at OneToad Design

He designed the icons for PDQForms  
I found Jordan through CIMGF; thanks guys!
Jordan responded to my initial query, worked with me and delivered my icons in a very reasonable amount of time!  
He communicates well, is easy to work with, and does EXCELLENT WORK!
And he’s very concerned with his customers’ satisfaction!
Thank you, Jordan!!

         ]]>
			http://frameworker.wordpress.com/2009/04/30/recommending-jordan-langille-iconographer/feed/
		0
	
		
			joely