TheBackShed.com

Forum Index : Microcontroller and PC projects : Possible bug with Touch(LASTREF)

Author

Message

Greg Fordyce
Senior Member

Joined: 16/09/2011
Location: United Kingdom
Posts: 153

Posted: 12:50am 01 Oct 2015

Copy link to clipboard

Print this post

I'm bumping a question I asked in another thread a few days ago.

The example code below illustrates the problem. The code is intended to allow a ghost hint in a TEXTBOX without the hint being used inadvertently in a program. When you touch the textbox the value typed in gets saved to name$. If you touch the textbox and immediately press enter the textbox goes back to showing the ghost hint and name$ is set to "". So far so good. But if you then touch the screen outside of a control then "Enter Name" gets saved to name$. This is because Touch(LASTREF) is still pointing to TEXTBOX.

CLS
Font 5
name$ = "" 'Name initialized to ""
GUI textbox 1, 0, 0, 250, 50, RGB(blue), RGB(gray)
CtrlVal(1) = "Enter Name" 'Ghost hint
GUI interrupt pendown, penup
Text 0, 60, name$ ' Show value of name$
Do : Loop

Sub pendown
End Sub

Sub penup
Select Case Touch(LASTREF)
Case 1
If CtrlVal(1) = "" Then
CtrlVal(1) = "Enter Name" 'invalid entry, set ghost hint
GUI bcolour RGB(gray), 1
name$ = ""
Text 0, 60, " "
Text 0, 60, name$
Else
name$ = CtrlVal(1) 'Valid textbox entry now set to name$
GUI bcolour RGB(white), 1 'change background colour to show value entered correctly
Text 0, 60, name$ 'show value of name
EndIf
End Select
End Sub

This code was tested with beta 31 on a 7" ssd1963 display, I haven't had time to try the latest beta.

So the question is should Touch(LASTREF) clear it's pointer to the last valid control touched once the GUI interrupt command is executed?

Or should we have a command like TOUCH(LASTREF)=0 to allow the program to clear the pointer at a specified point?

If the answer to the last question is yes, would there be any reason to make a Touch(LASTREF)= command have a valid range of 0 to 100?

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3303

Posted: 06:10am 01 Oct 2015

Copy link to clipboard

Print this post

Greg Fordyce said So the question is should Touch(LASTREF) clear it's pointer to the last valid control touched once the GUI interrupt command is executed?

Or should we have a command like TOUCH(LASTREF)=0 to allow the program to clear the pointer at a specified point?

If the answer to the last question is yes, would there be any reason to make a Touch(LASTREF)= command have a valid range of 0 to 100?

To my mind they are all good questions. For a start, I believe that it is valid for Touch(LASTREF)to keep pointing to the last control - although I can see your point. Using Touch(LASTREF) = 0 sounds like a messy kludge and I cannot think why you would ever want to set it to some arbitrary control ref.

Essentially, Touch(LASTREF) is intended for use when the touch has been just lifted from the screen so that you can do something appropriate on pen up. I guess that it could be reset to zero once the Touch(LASTREF) value has been read or it could be set to zero when the next touch down is detected (even if it was not in a control). The latter sounds the more sensible approach - would that help with your issue?

Geoff

Geoff Graham - http://geoffg.net

Greg Fordyce
Senior Member

Joined: 16/09/2011
Location: United Kingdom
Posts: 153

Posted: 09:28am 01 Oct 2015

Copy link to clipboard

Print this post

To me it makes more sense to reset after the Touch(LASTREF) has been read. If you decide to do the second option you need to make sure virtual keyboard/keypad presses don't inadvertently clear the Touch(LASTREF) value before you get the chance to read it.

Either solution would be fine though.

Greg

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3303

Posted: 02:39pm 01 Oct 2015

Copy link to clipboard

Print this post

Thanks, I will look into it.

Geoff Graham - http://geoffg.net

Greg Fordyce
Senior Member

Joined: 16/09/2011
Location: United Kingdom
Posts: 153

Posted: 08:45am 18 Oct 2015

Copy link to clipboard

Print this post

I have just tried this with beta 37 on a E64 and ssd1963 7 inch display. The original problem with the Touch(LASTREF) still seems to be in beta 37.

A quick recap, it appears that after the program has called the GUI interrupt penup subroutine the pointer stays pointing to that control so that if you touch the screen outside of a valid control it will run the penup subroutine again even though that control wasn't touched the second time.

Also when I run this I get an error "CPU exception #7 (bus error on load or store) at 0x9D02EDC0" The problem is with GUI bcolour commands. If I comment them out this error goes away.

The code I am running is below, the only change from the original code in the first post is to change the font from 5 to 4. Originally I wrote the code to try and do ghost hints in a basic program, so while the original purpose of the program is now redundant it still shows a potential bug (or 2?) in mmbasic.

CLS
Font 4
name$ = "" 'Name initialized to ""
GUI textbox 1, 0, 0, 250, 50, RGB(blue), RGB(gray)
CtrlVal(1) = "Enter Name" 'Ghost hint
GUI interrupt pendown, penup
Text 0, 60, name$ ' Show value of name$
Do : Loop

Sub pendown
End Sub

Sub penup
Select Case Touch(LASTREF)
Case 1
If CtrlVal(1) = "" Then
CtrlVal(1) = "Enter Name" 'invalid entry, set ghost hint
GUI bcolour RGB(gray), 1
name$ = ""
Text 0, 60, " "
Text 0, 60, name$
Else
name$ = CtrlVal(1) 'Valid textbox entry now set to name$
GUI bcolour RGB(white), 1 'change background colour to show value entered correctly
Text 0, 60, name$ 'show value of name
EndIf
End Select
End Sub

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3303

Posted: 04:57pm 18 Oct 2015

Copy link to clipboard

Print this post

Something strange is going on here. I tried your program on B37 and it worked as I expected. Touching outside of the text box had no effect while touching in the box popped up the keyboard. Repeating this after entering something in the text box worked exactly the same. Entering an empty string on the keyboard restored the ghost text.

Your second issue is definitely a bug. I made a silly mistake in both GUI FCOLOUR and GUI BCOLOUR and I will have it fixed in the next beta.

Geoff

Geoff Graham - http://geoffg.net

WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2948

Posted: 08:40pm 18 Oct 2015

Copy link to clipboard

Print this post

Geoff,

With the error messages of the following format:
CPU exception #7 (bus error on load or store) at 0x9D02EDC0

does the number at the end tell you what the issue is? OR does that number vary depending on the length of the user program, and hence is 'meaningless'?

The reason for asking is that I am still having issues with LOAD IMAGE on a 2.4" SPI (ILI9341) TFT. Yet every time afterwards (and after varying times) I seem to somehow trigger a CPU exception message with a consistent number.

Thanks,
WW

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3303

Posted: 11:23pm 18 Oct 2015

Copy link to clipboard

Print this post

The number is the address of the instruction in flash memory that caused the error. The message "exception #7 (bus error on load or store)" indicates that the instruction was accessing an invalid address. This can be caused by a bug in MMBasic but it can also be caused by flaky power supply, CPU speed too high, bad Vcap, etc. When an exception occurs the processor is forced into a reboot... there is nothing that MMBasic can do about it.

If the address is always the same that is a good sign because I might be able to trace what was causing the error. I will email you a version of the firmware that you can test and with the identical version at my end I might be able to find the offending instruction. The trick then will be to work out why it affects you but not others.

Geoff

Geoff Graham - http://geoffg.net

WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2948

Posted: 11:42pm 18 Oct 2015

Copy link to clipboard

Print this post

I am having some more issues with the ILI9341 2.4" TFT. I just can't find what triggers the issue which makes me think there may be a 'timing' issue somewhere (Power supply seems to be ok - tried four different set-ups now from USB to 2.1A PSUs).

I have some LIBRARY code, part of which sets the FONT and COLOUR f,b. (I am using font 5, white on blue).
In my program, my first line is CLS, and then a few lines down I draw some TEXT.

The issue is that sometimes the screen will CLS to Blue (as expected), and other times it CLS's to black.
And sometimes the font is sized as that set in the LIBRARY, and other times it sets it to a smaller font; and in the incorrect colours. I say the 'INcorrect colours' as I am not specifying anything in the TEXT command, and accordingly it should be as set in the Library's COLOUR command.

I have tried the FONT and COLOUR in Library STARTUP and just as a line of code (i.e. not in a sub)

Any ideas please . . . .

WW

SORRY- THIS MAY BE THE WRONG THREAD

Edited by WhiteWizzard 2015-10-20

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3303

Posted: 11:51pm 18 Oct 2015

Copy link to clipboard

Print this post

The random nature of the problem sounds like a hardware related issue. Have you tried a slower CPU speed?

Geoff Graham - http://geoffg.net

WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2948

Posted: 11:53pm 18 Oct 2015

Copy link to clipboard

Print this post

Geoffg said . . .Have you tried a slower CPU speed?

Yes - but at least I'm back home now with some test gear. Am isolating TOUCH next . . . .

Greg Fordyce
Senior Member

Joined: 16/09/2011
Location: United Kingdom
Posts: 153

Posted: 03:11am 19 Oct 2015

Copy link to clipboard

Print this post

Thanks for looking at this Geoff.

Geoffg said Something strange is going on here. I tried your program on B37 and it worked as I expected. Touching outside of the text box had no effect while touching in the box popped up the keyboard. Repeating this after entering something in the text box worked exactly the same. Entering an empty string on the keyboard restored the ghost text.

Did you try touching outside of the textbox after doing the above steps? That is when I get the strange behaviour. If you still can't replicate it I will do a quick video of the problem.

Cheers,

Greg

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3303

Posted: 04:13am 19 Oct 2015

Copy link to clipboard

Print this post

Greg Fordyce said Did you try touching outside of the textbox after doing the above steps? That is when I get the strange behaviour. If you still can't replicate it I will do a quick video of the problem

Yes I did and it ran fine.

I'm not sure that a video would help as I don't disbelieve you. There must be something different with your setup. For example, are you sure that you are running the latest firmware?

Geoff

Geoff Graham - http://geoffg.net

Greg Fordyce
Senior Member

Joined: 16/09/2011
Location: United Kingdom
Posts: 153

Posted: 09:56am 19 Oct 2015

Copy link to clipboard

Print this post

Geoffg said I'm not sure that a video would help as I don't disbelieve you. There must be something different with your setup. For example, are you sure that you are running the latest firmware?

Geoff

Here's a video showing my setup and the problem with name$ being set to "Enter Name" when it shouldn't be.

https://youtu.be/dVPaUk6FQaA

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3303

Posted: 03:36pm 19 Oct 2015

Copy link to clipboard

Print this post

Thanks, your video did help. The problem only occurs when you hit the enter key with a blank entry, then touch outside the box. A sequence that I did not test.

I have found the bug and will fix it in the next beta.

Thanks again.

Geoff Graham - http://geoffg.net

Print this page

To reply to this topic, you need to log in.