Micros 3700 Sim - transitioning to “next” touchscreen

[POSADM]

For those with sim experience, I have a problem transitioning to the “next” touchscreen after the event has completed. The task was to consolidate the pickup check process. We have both active checks and future order checks and Micros separates the pickup check functionality based on the status.

- Micros 3700 v5.2
- Touchscreen Button triggering event has “next” screen defined
- Have also tried displaying specific touchscreen and calling a dummy event at various points.

Any guidance is appreciated.

 

[hosehead78]

Can you post the section of SIM script that is setup to change to the next touchscreen?

 

[Bogg3r]

I just use the DisplayTouchScreen xxxxx function (where xxxxx is the micros.ts_scrn_def.obj_num) just before the EndEvent. I don't think I've had to define Next Screen in the ts design.

 

[POSADM]

The event is included below. I have tried adding the display touchscreen function but didn't help. Is it how I have event formatted? Do I need to separate into additional subs? Also tried suggestions from previous posts of calling this as an event or sub from another inq event.

//------------------------------------------------------------------------------------------------------//
// Pickup check by Check #  (Future order or Active)

event inq: 22

	//Window 3, 40" "
	//Display 1, 13, "Enter Check #:"
	//Display 2, 5, ""
	
	ReferenceNum = ""
	While Len(ReferenceNum) = 0 
		
		touchscreen 312
		input orderRef, "Enter Guest Check Number"

		If Len(orderRef) > 0 Then		
			ReferenceNum = orderRef
			checknum = ReferenceNum
		Else		
			ErrorMessage "Invalid Entry.  Check # must be 1 to 4 digits."			
		EndIf

	EndWhile

	Call Load_SimODBC_dll	
	
	Format sql_Status as "SELECT autofire_time FROM micros.chk_dtl where (order_type_seq = 5 or order_type_seq = 6) and chk_open = 'T' and chk_num = ", checkNum, ";"	
	DLLCALL_CDECL hODBCDLL, sqlGetRecordSet(sql_Status)
	DLLCALL_CDECL hODBCDLL, sqlGetFirst(ref sql_Status)
	sql_Status = Mid(sql_Status, 1, (Len(sql_Status) - 1))

		if sql_Status = ""
			Chk_is_Future_order = 0		//not future order - active check
		else
			Chk_is_Future_order = 1		//furture order check
		endif
		
	if Chk_is_Future_order = 0
		LoadKybdMacro Key(1,327684), MakeKeys(checkNum), @Key_Enter
	else 
		LoadKybdMacro Key(1,327706), MakeKeys(checkNum), @Key_Enter
	endif

EndEvent

 

[hosehead78]

You are calling it correctly. However, you are missing the correct Screen for Micros to go to. 3700 has a touch screen designer, where these screens are created. You have to use the Touchscreen designer to create the new touchscreen, when you do make note of the screen number, that is the number you want to call/refer to.

Grab this, and read through Pages 66, 94 and 97. Those pages reference information for Touch Screens.

 

[POSADM]

Thanks @hosehead78 for the response. I'm very familiar with creating touchscreens(EM) and have tried calling the desired touchscreen (as also noted above by Bogg3r) but doesn't change screen. Since it didn't seem to have any affect that line was not included in code above. I haven't needed to call a touchscreen in this way, generally if a screen is needed it has either been created by the sim or load menu item screen(SLU). I can load a SLU but that wasn't the preferred route.(extra button to press to get to Payscreen)

 

[POSADM]

It appears that by moving the last 5 lines of my code to a separate event and then adding the function to display touchscreen, the desired screen is now displayed... Order maybe backwards - more testing... Thanks for the responses guys.

... Event Inq: 22 continued....
		
	LoadKyBdMacro key(24,((16384*23) + @PMSSeqNum))

endevent

event inq: 23

	if Chk_is_Future_order = 0
		LoadKybdMacro Key(1,327684), MakeKeys(checkNum), @Key_Enter
	else 
		LoadKybdMacro Key(1,327706), MakeKeys(checkNum), @Key_Enter
	endif
	
	displaytouchscreen 303

endevent

 

[Moregelen]

The issue is that calling a macro within a SIM can be thought of as an interrupting process. While it doesn't ALWAYS interrupt the flow of steps, it usually does. You also technically aren't supposed to be able to call multiple separate macros (not multi step, but separate macros altogether) from a single event, though I can't remember if I've ever gotten away with that before. By basically telling it to process another inquiry that way, it allows anything part of the original inquiry (such as the next screen) to process FIRST, then it does that new inquiry. This is a useful technique, especially when trying to do something simple like, say, display a popup window with the change due, but not until after the cash drawer has actually opened. You'd want to hook into the cash event, but not actually display anything until it has managed to finish.. but anything you do within the event occurs before Micros finishes processing the cash. You can get around that by calling another inquiry from the event.

That make sense?