 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PicoMite 5.07.00 - Bug Reports
  Page 4 of 4 |
|||||
| Author | Message | ||||
electricat Regular Member  Joined: 30/11/2020 Location: LithuaniaPosts: 74 |
Yes, I know program in flash is tokenised. If some day I will run out of free flash memory because of brackets, I will let you know :D |
||||
| Rodgerg Newbie  Joined: 13/10/2019 Location: New ZealandPosts: 12 |
RE: GUI Switch Touch Problem Some interesting info on this issue (first identified by Panky) that may be helpful in tracking down the bug for a two position toggle switch with an "ON" and "OFF" using GUI SWITCH #20,"OFF|ON",1,MM.VRES-30,MM.HRES/3,29,rgb(BLACK),rgb(cyan) With ArmmiteF407 V5.07.00RC1 - everything works as expected Picomite V5.07.00 - works, but touch areas are reversed (pushing OFF turns ON) Picomite V5.07.01b8 - doesn't work, touch areas not reversed, but only accepts push ON when already ON and push OFF when already OFF, so no switch action) (p.s. The display I am using on the Picomite is an ILI9341) |
||||
| Rodgerg Newbie Joined: 13/10/2019 Location: New ZealandPosts: 12 |
RE: GUI Switch Touch Problem - 5.01.01b9 Update I see matherp posted beta 9 in another post not long after my post above, so I gave this a try. The GUI switch now works again (compared with beta 8), but the touch areas still appear to be reversed as per 5.07.00. But at least it works  |
||||
| Rodgerg Newbie Joined: 13/10/2019 Location: New ZealandPosts: 12 |
RE: GUI Switch Touch Problem - 5.01.01b9 Update - Inspection of C File OK - I got brave and had a look at the C source files. In GUI.c, starting at Line 966 (sorry, I didn't know how to include line numbers) , the Switch touch areas are defined and stored in Ctrl[r].min Ctrl[r].max, with these based on Ctrl[r].value. on = (Ctrl[r].value == 0); if(on) shift = 0; else shift = BTN_CAPTION_SHIFT; if(twobtn) { half = Ctrl[r].x1 + (Ctrl[r].x2 - Ctrl[r].x1)/2; if(!(on)) { // use the min, max elements to store the active x area of the button Ctrl[r].min = half; Ctrl[r].max = Ctrl[r].x2; } else { Ctrl[r].min = Ctrl[r].x1; Ctrl[r].max = half; } } else { Ctrl[r].min = Ctrl[r].x1; Ctrl[r].max = half = Ctrl[r].x2; } From line 970, if "on" is not true, then the RHS of the button is enabled for touch, else the LHS. If "on" is the control state, then this makes sense, as the RHS of the button needs to be pushed to assert the control. If Ctrl[r].value == 1 when the control is asserted (say a button pushed), I would have thought that "on" would reflect this. However Line 966 seems to say that "on" is true when the control is de-asserted (Ctrl[r].value == 0), which seems counter-intuitive and could be the cause of the issue. As the variable is used several times later in the code, I was unsure of the impact of changing the definition of "on" to directly reflect the control state on = (Ctrl[r].value == 1); On the other hand, if "on" is meant to indicate the control is de-asserted , then the if(!(on)) test from line 970 seems to be reversed, in which case replacing that line with if(on) { might fix the issue.I am sure that matherp or geoffg will put me straight if am on the wrong track here  |
||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 8563 |
Please see this thread . The PicoMite behaves the same as the MM+ |
||||
| Page 4 of 4 |
|||||
 Print this page |
