Registry Problem...

The StartPOS hook should fire, then the InitializeTransaction hook should fire as soon as StartPOS completes.

Glenn Adams Tiber Creek C> Hi...

Currently when I start my POS the InitializeTransaction hook gets fired and Immediately after that the StartPOS hook is fired. But don't you think that only the StartPOS hook should get fired on starting the POS application and when I complete my tender then only the InitializeTransaction Hook should get fired...?? Currently both the hooks are fired on starting the application.... :-(

Waiting for ur reply....

Vicky... :-)

"Glenn Adams [MVP - Retail Mgmt]" wrote:

If you have the customization guide, there's a flow chart included that shows the expected order of hook calls. It's imperfect. RefreshDisplay gets called repeatedly and is not listed in the flow nearly enough.

I entered this as an incident with MS a few months ago. Here's a clip of the traffic in that incident - I've trimmed out some extraneous stuff...

8/5/2005 11:05:00 AM EDT -- Glenn Adams There seems to be a discrepency in the order of hook events as documented in the Customization guide vs. the order they are actually called in. I'm using SP 3 - 1.2.0185

The customization guide shows the following order of events at startup:

1)StartPOSHook 2)InitializeTransactionHook 3)RefreshDisplayHook

Testing Shows this order:

1)POS Login Screen displays - no hooks are called until after login 2)InitializeTransactionHook 3)RefreshDisplayHook 4)RefreshDisplayHook again 5)StartPOSHook 6)RefreshDisplayHook

Customization Guide Shows QuitPOSHook as being the last event before POS Shutdown.

Testing Shows that RefreshDisplayHook is again called after QuitPOSHook.

-------------------------------------------------------------------------- VOID CALL

8/5/2005 1:59:00 PM EDT -- Good afternoon Glenn,

I checked the version of Customization Guide I am using and in the diagram it does show multiple RefreshDisplayHook, remember anytime there is a change within the form or transaction screen this hook would get fired. Also in many situations the hooks could differ based on functionality requirements at a specific site I am encclosing this version of the Customization Guide.

Thanks and have a great day,

--------------------------------------------------------------------------

8/5/2005 3:10:00 PM EDT -- Glenn Adams I got my order of events from a test system that has every hook enabled with a stub function that displays a message box with the name of the hook that called it.

What I wanted to point out was that StartPOSHook is not the first function called - it is called after InitializeTransactionHook and one or more RefreshDisplays.

Also, there is another RefreshDisplay After QuitPOSHook.

Understanding the Order of Events is critical in designing Add Ins. If the tested order is intended by the designers, that's fine, but the CG should be updated to reflect the true order of events. If the CG acurately represents the designers intent (which I think it does) then the tested order is a bug and should be fixed.

Logically, I think that StartPOSHook should really occur BEFORE the user's first login, but that's beyond the scope of what's in the CG.

-------------------------------------------------------------------------- VOID CALL

9/6/2005 11:22:00 AM EDT -- Good morning Glenn,

I apologize for getting back to you so late. This documentation issue has been entered into a issue tracking DB and is under review. Thank you for bringing this to our attention.

Glenn Adams Tiber Creek C> Currently when I start my POS the InitializeTransaction hook gets fired and

Hi Glenn

Thx a lot.... This is really a serious problem for me.... I wanted to make some changes after the transaction is completed. Do you some some other idea with which I can implement this...?? Currently I'm using InitializeTransaction and StartPOS both of my code executes at the POS start. I want to execute only StartPOS at POS start and execute some piece of code after the transaction is completed....

Vicky... :-)

"Glenn Adams [MVP - Retail Mgmt]" wrote:

PrintReceipt is the usual event for executing code at the end of a transaction. This is the first event where the Transaction Number is available...

If you are really trying to do something AFTER a transaction completes, InitializeTransaction is the wrong place to do it anyway, but: You could write a flag value somewhere - either a static variable or possibly the database - that indicates that StartPOS has completed. On InitializeTransaction, check your flag and if it hasn't been set just exit...

Glenn Adams Tiber Creek C> Hi Glenn

Hi Glenn..

Thx a lot....It worked fine... U r really a Genius..... :-)

Thanks a t> PrintReceipt is the usual event for executing code at the end of a