#include <IDocumentFieldOrder.h>

Inheritance diagram for IDocumentFieldOrder:

Classes
struct	ItemInstance

Public Types
enum	{ kDefaultIID = IID_IDOCUMENTFIELDORDER }

typedef K2Vector< ItemInstance >	FieldOrder

typedef K2Vector< ItemInstance >	CalculationOrder

Public Member Functions
virtual void	FieldWasAddedToHierarchy (const UID &inPageItem, const UID &inSpread=kInvalidUID)=0

virtual void	FieldWillBeRemovedFromHierarchy (const UID &inPageItem, const UID &inSpread=kInvalidUID)=0

virtual CalculationOrder	GetCalculationOrder ()=0

virtual void	SetCalculationOrder (const CalculationOrder &inPageItemList)=0

Public Member Functions inherited from IPMUnknown
virtual IPMUnknown *	QueryInterface (PMIID interfaceID) const =0

virtual void	AddRef () const =0

virtual void	Release () const =0

Detailed Description

This class tracks the calculation order for form fields... These orderings are written to generated PDF files.

A tricky issue:

What about the order for items that appear on multiple pages? (such as items on master pages and items that span pages)

Ideally, such items would have an ordering for each page that they appear on. Therefore we track not only the pageitem but the spread and page for each potential instance of the item on a page.

The calc order is just a single list (vector),because the the calculation order is supposed to be document-wide. Each item in the list is a spread/page/pageitem triplet to account for multiple appearances of the page item on different output pages.

But I think for a first attempt at all this, I'm not going to worry about master pages and multipage spanning form fields.

This means that for now,

fSpread and fPage in ItemInstance will be ignored (but read and written) Every instance in the PDF output of the master page items and page items that span multiple pages will be ordered together. This should be okay, since multiple instances of items should not depend on eachother.

I should be able to support any ordering of master page items, multipage spanning page items and normal page items later on without changing the file format.

Though this level of control might not be needed...

See Also: ISpreadFieldOrder

Member Function Documentation

virtual void IDocumentFieldOrder::FieldWasAddedToHierarchy	(	const UID &	inPageItem,
		const UID &	inSpread = `kInvalidUID`
	)

pure virtual

Called when a form field is added to a hierarchy in a document (really when it is added to a spread hierarchy, but it is smart enough to ignore the cases where its not in a spread).

Takes care of entering inPageItem (if it's a form field) into the Calculation Order, and Tab Order (by calling through to ISpreadFieldOrder

Parameters

inPageItem	Page item being added to hierarchy
inSpread	Spread the page item is being added to

virtual void IDocumentFieldOrder::FieldWillBeRemovedFromHierarchy	(	const UID &	inPageItem,
		const UID &	inSpread = `kInvalidUID`
	)

pure virtual

Called when a field is removed from a hierarchy in a document (really when it is removed to a spread hierarchy, but it is smart enough to ignore the cases where its not in a spread).

Takes care of removing inPageItem (if it's a form field) from the Calculation Order, and Tab Order (by calling through to ISpreadFieldOrder

Parameters

inPageItem	Page item being removed to hierarchy
inSpread	Spread the page item is being removed from

virtual CalculationOrder IDocumentFieldOrder::GetCalculationOrder ( )

pure virtual

Get Form Field Calculation Order for the document

virtual void IDocumentFieldOrder::SetCalculationOrder ( const CalculationOrder & inPageItemList )

pure virtual

Set Form Field Calculation Order for the document

Parameters

inPageItemList an ordered list of form field UID/page/spread triplets

Classes

Public Types

Public Member Functions

Detailed Description

Member Function Documentation