Talk to Fieldpine Events

Goto: Talk To Fieldpine Home Page

The POS generates a number of events at various stages of processing. You are able to handle these events to control precise behaviour. For simple changes, you can handle the events in PosScript. However, larger and more complex handling is sometimes better handled in a high level language. For example, PosScript cannot easily read external databases or create network links, while the TTF interface can.

Registering to Receive Events

In your INIT call, encode the event numbers you wish to receive.

	// ************* Build my registration call
	FieldpinePacket Reg = Fdl.NewPacket("INIT");

	// Set overview information about this program
	Fdl.SetString(Reg, FIELDPINE_REGISTER_COMPANYNAME, "Your Company Name");
	Fdl.SetString(Reg, FIELDPINE_REGISTER_VERSION, __DATE__ " " __TIME__);

	// Set that we are capable of talking to multiple processes, not just one
	Fdl.SetInt(Reg, FIELDPINE_REGISTER_APP_TYPE, MULTIPLE_USERS);

	// Set the parameter saying we are wanting to do pricing for everything
	// This will be called a lot, every modification, however small, to the items being purchased
	Fdl.SetInt(Reg, FIELDPINE_REGISTER_HANDLE_EVENTS_SYNC, FIELDPINE_EVENT_PRICE_ALL_SALE);

	// Change the above to list the events you are interested in.
	// You can register for multiple events but you must explicitly name each event you want

	// Send it to the POS and release the memory
	Fdl.SimpleSend(Reg);
	Fdl.FreePacket(Reg);

Sending and Processing Events

When the POS calls your event handler your code needs to respond quickly. You are being called while a retail sale is in progress and the operator will be scanning and weighing items rapidly, often without watching the screen.

When an event is sent to TTF applications, the following logic is used.

The POS reaches a point where an event can be sent. It checks to see which TTF interfaces are online and builds a list of those interested in the event.
It creates an EVNT packet and sends this, in parallel, to all handlers wishing to receive it
Handlers can register as sync or async, and include a wait timer.
The POS will wait up to "wait timer" for each sync registered event. Your code is expected to respond inside the timer window you specified.
If you do not respond, the POS will continue processing. If you are not going to respond, such as ignoring this event, you should send an empty response (for sync handlers) to stop the POS from waiting.
If you are an async handler, the POS will not wait.

A sync handler is one that requests the POS pause while this processing is undertaken. Or where the handler will always be responding. The event "can I add xyz to this sale?" would typically be a sync handled event as the POS needs to know the answer now.

An async handler is one that can allow the POS to continue internal processing. The event "Set line price" can be async if you wish. Prices on lines can be changed by your interface at any time so you can respond later.

When an event is sent to a handler it includes reference information (request id and request RVV). This information allows the POS to know when and where the event was sent to you. You can respond later than your timeout window and the POS will check to see if this response is still acceptable or it conditions have changed. Consider the following flow

The teller scans product 123 and adds it to the sale with price $2 each.
TTF fires an event to your code, but for some reason your code does not respond immediately
The teller scans product 456 and adds it to the sale.
Your event handler now responds saying "price of 123 should be $1.50 each"

The POS is able to determine that the event you are responding too is still valid for the first saleline (product 123) and so applies it.

Do not assume that you will receive all events, you should but do not design around requiring it. Treat each event as standalone. Do not cache information from one event to another, there is no guarantee that the overall state of the system has not changed between seperate event calls.

Packet Structure

Request Packet

An event packet has the packet type "EVNT" and has a standard talk to Fieldpine header.

FieldNo	Name	Details
f110	RequestId	A unique token identifying this request
f111	Request RVV	A sequence identificaiton value that is used to mark the state of the system when this event was generated
f120	EventNo	The event number being sent in this packet

Reply Packet

A reply packet has the packet type "REEV" (REply to EVent)

FieldNo	Name	Details
f200	Command	A reply status indicating main action to be taken. Events that allow a handler to specify yes/no operation return the overall command in this field. 1=Yes, 0=No

Event List