Touch Panel Keypad Handling...

sonny

I've always worked around some of the issues with keypad handling, but am curious as to any tips or techniques to better handle these...or maybe something I'm completely missing...

Typically I'll have multiple touch panels with the same (or close to the same) interface. Let's say I want to change a setpoint on a thermostat. I'll have a virtual device combined with the touch panels and will process a button event by showing the keypad (i.e. @AKP). Since I haven't found a way to know which panel produced the event, the keypad shows on all of them. When I process the input I send a remove keypad command to make sure they're gone. Question 1....any way to only show the keypad on the originator vs. all, using the virtual device method?

Second problem occurs when the data comes back. It would be nice if the KEYP event coming back from the panel came back on the port that was used in the send_command that called up the keypad. So basically I create an event for port 1 that re-transmits the data to all modules that need a keypad. I then have to setup flags and controls in those modules to determine if the event is for them. I guess I could create a keypad event handler that modules would pass their requests to vs. having them send out @AKP themselves. This handler could also manage other issues with keypads like range limits. Any thoughts?

Thanks...Sonny

jjames

Use a DEV array instead of combining your touch panels. Then you could do something like this:

DATA_EVENT[dv_TP]
{
	STRING:
	{
		STACK_VAR INTEGER nIND;
		
		// Now you know which panel it's coming from
		nIND = GET_LAST(dv_TP);
		
		// Process incoming keypad string here
	}
}

You can always set flags as to which module the data is needed for. Set up a button event something along the lines of:

BUTTON_EVENT[dv_TP_2,100]	// Touch panel array of port 2 panels
{
	PUSH:
	{
		STACK_VAR INTEGER nPNL;
		nPNL = GET_LAST(dv_TP_2);
		
		// Set flag - we know which port & panel we're dealing with
		MODULE_FLAG = 1
		
		// Send keypad command
		SEND_COMMAND dv_TP_2[nPNL],"'@KEYP'";
	}
}

And process the info coming back in the string event. You know which panel the data is coming back from, and if you monitor the button presses that open up the keypad, you will know which of your modules it's for.

Good luck!

sonny

Thanks....I've used device arrays when writing Duet drivers, but didn't think of that here. I guess it probably makes good sense to read from touch panels through DEVARRY, and write through virtual devices combined with actuals?

As far as the return data, I'm using a flag like the one you've shown, but my modules typically don't listen for port 1 events so I'm regenerating the events from a master touch panel handler module. Problem is this requires hard coding the regeneration to the appropriate ports, which means remembering to go to that module with each add or edit. The more I think about it, doing a GET_ME_SOME_KEYPAD_DATA message may be a cleaner method.