#12495 - 02/06/03 06:33 PM
Touch grid location to var. (2.00d)
|
Guy Lavoie
Beyond All Hope
Registered: 12/21/02
Posts: 6401
Loc: Montreal, QC, Canada
|
This one is a bit on the wierd side but just in case someone ever needs to do this...
In experimenting with the new ability to capture the touch button object number in a variable, I was originally getting what looked like random button press object numbers along with the real ones. That is when Dan Smith suggested I set parameter 26 to 0. It was at 1 and he mentioned something about getting a grid location value when this was happening. So I reset variable 26 to 1 and experimented by creating buttons all over the screen and sure enough, after the button object number, I was getting a number that was consistent with whatever touch square position I was touching. The numbering is a bit akward so I spent some time making up a routine to first capture the touch object number, then the grid location number and scaled to it being a value from 0 to 59 for the squares from top left corner to bottom right.
Here is the routine:
[CODE] 0001 - IF Touch Anywhere Button #0, Button Leopard is pressed // Access the touch button queue
0002 - THEN Load Data to: V99-touch-queue-vlaue- // save in variable #99
0003 - ELSE Load Data to: V99-touch-queue-vlaue- // save in variable #99
0004 - IF V95-button-queue-flag is = 3 // if queue flag was set to "last pass"
0005 - THEN V95-button-queue-flag = 0 // then reset flag for next touch queue event
0006 - THEN V97-grid-location-no. = 65535 // and show "empty queue" for griid location
0007 - IF V95-button-queue-flag is = 2 // if flag = grid location
0008 - ELSE Skip to line 18 // else skip routine
0009 - THEN V95-button-queue-flag = 3 // then set raw queue flag to "last pass"
0010 - THEN V96-button-object-saved = V98-button-object-no. // save button number to allow matching with grid loc.
0011 - THEN V98-button-object-no. = 65535 // show "empty queue" for button number
0012 - THEN V97-grid-location-no. = V99-touch-queue-vlaue- // then save grid location in var 97
0013 - THEN V97-grid-location-no. - 208 // subtract 208
0014 - IF V97-grid-location-no. is = 65327 // if value rolled over from 65535
0015 - THEN V97-grid-location-no. - 65279 // then subtract offset
0016 - IF V97-grid-location-no. is > 65327 // if value rolled over
0017 - THEN V97-grid-location-no. - 65280 // then subtract offset
0018 - IF V95-button-queue-flag is = 1 // if flag = "object number" pass
0019 - THEN V95-button-queue-flag = 2 // then flag is set for grid location
0020 - THEN V98-button-object-no. = V99-touch-queue-vlaue- // save button object # in var 98
0021 - IF V99-touch-queue-vlaue- is = 0 // if touch anywhere in raw queue
0022 - THEN V95-button-queue-flag = 1 // then set flag for object number
0023 - THEN V98-button-object-no. = 0 // and store 0 for object number [/CODE]What the routine does is look for the "touch anywhere" event to occur first and reports it as "V98-button-object-no." that can be used by code in the program for that pass, then it sets a flag so that the next pass will take the next item in the queue (which will be the actual button object number) and also report it as "V98-button-object-no.", and usable for tests in that pass. The flag is then set to have the following pass capture the grid location number and do the scaling operation on it (lines 7 to 17) to give the 0-59 grid location that was pressed. A copy of the last touch button object that was pressed is also saved in "V96-button-object-saved" so that someone could always look for which button was pressed AND which actual touch square was pressed. The touch button queue only returns data if there is a button defined on the grid location you touched or if you're on screen 0 (more about screen 0 below).
There might be a few practical applications for this, such as:
- If you've run out of touch objects or you're getting close to 255 (with only 10 screen objects of any kind per screen on all 24 screens you're already close to this). This way, you can define just a few large buttons (I used Jim Beersman's TSE 2.0 editor to create a screen with two giant buttons covering the whole screen) with icons to show where the hot spots are, and then distinguish which part of the button was pressed by interpreting the grid location number.
Remember that the grid location is the same no matter which screen you're on so you might want to look for the grid location number AND the value of variable #63 to determine if you're decoding the touch event on the right screen. But at the cost of as little as two screen objects, you can decode up to 60 more distinct touch events.
- If you want to use screen 0 as an additionnal screen. Screen 0 acts differently in that it behaves a one large button. Touching it gives you the standard "touch anywhere" event even though there is no button defined (and you can't define one) on it and you also get a button object #255 event (so you can use this to distinguish a touch anywhere on screen 0 from a touch anywhere on other screens). By defining icon #0 to look like a screen with buttons or with hot spots shown in the screen bitmap design, you can now distinguish which grid location was touched on screen 0 too.
- Any other tricks like treating a text object or a status light like a button by looking for it's grid location plus screen number as generating a touch event.
_________________________
"If you don't know what you're doing, do it neatly..."
|
|
Top
|
|
|
|
|
#12496 - 04/25/03 08:22 AM
Re: Touch grid location to var. (2.00d)
|
Brian Raynor
addict
Registered: 01/09/03
Posts: 454
Loc: Columbia, SC
|
Guy,
After you linked back to this one, I looked over it again.
I guess I had missed the part about being able to check for the touch object number and THEN for the grid location. This really adds to the usefulness (since I don't have to check screen number, nor do I have to reject things that weren't on a button I care about).
This way I can redo my keypad to be one large button. When it is pressed, I'll know it (and not even have to check screen number) and then find out where it was pressed. This would save me 11 touch screen objects (12-1). I'm not close yet, (around 60 now), but probably will be before I'm done.
One question though. It appears that from your example that simply copying doing a Load causes the next numbers to be put into thhe queue before the next pass. Is this correct?
If so, I wonder if there are any other cases where this happens in other instances, ie: with things like X10 received, etc? Just wondering if there's any other useful info/functionality out there we didn't know about?
|
|
Top
|
|
|
|
|
#12497 - 04/25/03 10:43 AM
Re: Touch grid location to var. (2.00d)
|
Guy Lavoie
Beyond All Hope
Registered: 12/21/02
Posts: 6401
Loc: Montreal, QC, Canada
|
No, anything coming into one of the input queues, whether its X10, buttons presses, IR, etc. are always constant for one full pass through the program. What might be confusing you is the way I set the "button queue flag" in reverse order (3,2,1,0) in the code lines. This is more due to a habit of doing this back in the pre-2.0 days when the "Skip To" statement was still just a wish! An easier-to-read way would be to put them in progressively increasing order and use a "Skip To" at the end of each section to avoid testing the button queue flag I just set in that pass.
Old habits... 
_________________________
"If you don't know what you're doing, do it neatly..."
|
|
Top
|
|
|
|
|
#12499 - 04/25/03 06:14 PM
Re: Touch grid location to var. (2.00d)
|
Guy Lavoie
Beyond All Hope
Registered: 12/21/02
Posts: 6401
Loc: Montreal, QC, Canada
|
That's right, as soon as an input event is complete, it is "made available" for one complete pass of the program, beginning with the next pass (ie: line #1 always sees a new event first). This is true for all queued and cached data (data obtained by the bus routine from modules). So this goes for Touch button presses, recognized IR codes, incoming X10, slave or module parameters and data, I/O points turning on or off.
Concerning button presses, as I explained in the other thread about grid location; if parameter 26 = 0, then a button press will put in the queue:
- a press anywhere event (button 0)
- the actual object number
If parameter 26 = 1 then it becomes:
- a press anywhere event (button 0)
- the actual object number
- the grid location number
When there is nothing in the queue, the value returned is 65535
For slave button presses (detected by the master), you don't get the touch anywhere or the grid location number, only the object number. It will be encoded as the module # in the high byte and the object number in the low byte. For example, pressing button #3 on slave leopard #2 will return (256*2) + 3 = 515. You could use this scheme to save program lines if you have several slave Leopards all running the same screen files: get the button queue value and use modulo 256 to get just the button number regardless of module #. Since module numbers can only go as high as 127, the highest possible returned value is 32767; so 65535 is still a unique code for "nothing in the queue".
For your second question: yes, all other events only return single queued values.
_________________________
"If you don't know what you're doing, do it neatly..."
|
|
Top
|
|
|
|
|
#12500 - 05/02/03 11:42 AM
Re: Touch grid location to var. (2.00d)
|
Venu
journeyman
Registered: 03/06/03
Posts: 73
|
Guy,
So, grid location numbers cannot be made use of when master is taking all the actions based on button presses on slaves.
Why do you have 4 passes in the code above. I can understand 2nd and 3rd passes but not the 1st and 4th passes.
From what you said above, is it true that I cannot have the check for touch anywhere slave button on a master. Button 0 is available on master. Does it always fail if I check it?
|
|
Top
|
|
|
|
|
#12501 - 05/02/03 01:20 PM
Re: Touch grid location to var. (2.00d)
|
Guy Lavoie
Beyond All Hope
Registered: 12/21/02
Posts: 6401
Loc: Montreal, QC, Canada
|
The idea behind this code is to always have the routine at the beginning of the program and have your routines look to match the "button object number" variable to detect the button presses.
What happens is the following:
- If the touch object in the queue is = 0, then this means a "touch anywhere" occurred on the master. This is what lines 21 to 23 do. The "button object number" for that pass will be 0. If this occurs, then the button queue flag is set to 1 because...
- The next thing in the queue will be the actual object number as defined in the touch screen file. The object number is put in the "button object number" for that pass and the flag is now set to 2 because...
- The next thing in the queue will be the grid location number, which will be put in the "grid location number" variable for the reaminder of that pass and can be interpreted by your code. Lines 12 to 17 do a bit of math on the grid location muber so that it ranges smoothly from 0 to 59. This routine also saves the touch object number fromt he previous pass in the "button object saved" variable. Why? To give the program code creator (that's you!) a chance to test for a combination of a touch button number and a grid location number together, like:
IF button object saved = 23
AND grid location number = 35
THEN (code for that "part" of the button being pressed)
Without saving it, you would have to do that in your own routine because both numbers are obtained in two seperate, consecutive passes. Once that is done, we add a step 4 to...
- Clear the object number by setting it to 65535. Don't forget, the "button object number" variable is simulating a direct read of the touch button queue, and button presses are only true for one pass, so I'm clearing it here on the next pass.
This routine cannot be used to interpret button presses coming from a slave because the only thing sent across the bus is the object number and nothing else. This means that your routine for slaves should simply do either "IF Touch button" commands or maybe look for any button press and capture the queue contents in a variable, if you want to do the thing about looking for a given button number on any slave.
_________________________
"If you don't know what you're doing, do it neatly..."
|
|
Top
|
|
|
|
|
#12502 - 05/02/03 04:36 PM
Re: Touch grid location to var. (2.00d)
|
Venu
journeyman
Registered: 03/06/03
Posts: 73
|
For each button press, there are 3 items on the queue but you are reading the queue 4 times. How does that work?
My real question was if I can use the grid numbers of slave screen on the master so that I can use some of the icons published on this message board.
In my case all button actions (except the screen changes) are performed by the master.
|
|
Top
|
|
|
|
|
#12504 - 05/03/03 11:53 AM
Re: Touch grid location to var. (2.00d)
|
Venu
journeyman
Registered: 03/06/03
Posts: 73
|
I meant that I cannot use combo icons.
There are, for example, icons that contain Vol UP and Down and Mute together in one button which I could have used following the above logic on a leopard. But I cannot do it on the master in my setup.
|
|
Top
|
|
|
|
|
#12506 - 05/05/03 08:52 AM
Re: Touch grid location to var. (2.00d)
|
Venu
journeyman
Registered: 03/06/03
Posts: 73
|
The idea is not to use few icons but to use few buttons since I may run out of them once I have security system integrated.
|
|
Top
|
|
|
|
|
#12507 - 05/05/03 10:17 AM
Re: Touch grid location to var. (2.00d)
|
Guy Lavoie
Beyond All Hope
Registered: 12/21/02
Posts: 6401
Loc: Montreal, QC, Canada
|
Ok, sure you're trying to use this to get around the 255 object limit (as I suggested in the original post about this). Well logically, you will not be able to exceed 255 buttons as far as getting a master to see slave button presses, since there are only 8 bits for the button number in the button input queue anyways. This means that you would have to do some preprocessing logic in the slave itself, and convert the "grid located" button presses to slave variables that the master can read and look for "becomes =" events. You would want to do this for seldom used functions or for triggering macros, since this will be slower by nature. You could use a slave variable and set it to values like 256, 257, etc. to help you remember that this is an expansion on slave button events.
_________________________
"If you don't know what you're doing, do it neatly..."
|
|
Top
|
|
|
|
Moderator: Dan Smith, Monte G, ADI Tech Support, Guy Lavoie
|
0 registered
and 26 anonymous users online.
|
|
2747 Members
19 Forums
3835 Topics
22711 Posts
Max Online: 67 @ 08/16/11 03:08 PM
|
|
|
|
|
|
1
|
2
|
3
|
4
|
|
5
|
6
|
7
|
8
|
9
|
10
|
11
|
|
12
|
13
|
14
|
15
|
16
|
17
|
18
|
|
19
|
20
|
21
|
22
|
23
|
24
|
25
|
|
26
|
27
|
28
|
29
|
|
|
|
|
|
