 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 : MMBasic and Buttons
| Author | Message | ||||
| Andrew_G Guru  Joined: 18/10/2016 Location: AustraliaPosts: 872 |
Hi All, I've been experimenting with "Buttons", based on the sample code on pages 84/85 of Geoff's "Getting Started With the Micromite". I want to be able to use buttons to call subroutines which then call other subroutines to set up other "screens" of options with different buttons (and actions). I'm finding that: 1. if I InitBtn x to n in one subroutine then in subsequent screens any buttons that have been re-initialised work OK but any that have not been reinitialised remain active (ie if I initialise say 5 buttons, eg 0 to 4, in the first subroutine, and only 2, say 0 to 1 in the second subroutine then the original buttons, 2 to 5 are still active - am I doing something wrong or is there a workaround (eg to InitBtns 2 to 5 to a small area coloured Black, Black?) 2. in Geoff's example one does "<do whatever button x needed done>" before WaitBtnUp(x). Is there an argument for it to be done after?, and possibly with a short PAUSE? 3. I'm also confused as to where to test for CheckBtnDown, ie in the subroutine or in the main loop? 4. if I use "InitBtn n, -10, -10 . . ." the test for Touch(x) and Touch(y) seems to get confused (I'm not surprised). My workaround is to Initialise to 0,0 and to set the colour to Black, Black and then draw an RBOX where I want it. (I want the -10, -10 so the radii aren't obvious). Any comments and suggestions welcome? (PS I DO understand that Geoff's examples are just that, examples) Andrew |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
I think that the core issue is that you are trying to develop a complex program with nested screens straight off without understanding the code and what it is doing. It might be better to start simple with a single screen and some buttons (eg, your main screen) and play with that to see how it works. Then add the more complex features bit by bit and see how it goes. Your question 1: The best approach would be to clear the screen (CLS) when you start a new screen in your subroutine, initialise all buttons (InitBtn) then enter your loop where you handle button presses. When you exit back to the main screen (from where you originally came) you will need to repeat the whole process for the main screen (CLS, InitBtn then loop). Ie, treat each screen separately as a unit. It might sound inefficient repeatedly initialising the buttons every time you change screens but it will happen so fast it will not be noticeable. Question 2: Normally what happens is that the action that you want done is carried out immediately the button is pressed then you wait (in WaitBtnUp) for the user to release the button so that you can redraw the button and carry on (Windows generally works this way). If you have transferred control to another screen the best practice is to clear the screen, initialise the new buttons but then wait for the user to lift the touch before entering the new screen's loop (with CheckBtnDown, WaitBtnUp, etc). You can if you wish immediately wait for the user to release the button then, after WaitBtnUp, do the requested action - this would work if you were going to transfer to another screen. I don't know what you mean by "Is there an argument for it to be done after?" but you certainly should not put a PAUSE in there as that would just slow down the button's visible response. Question 3: As in the example, CheckBtnDown should be in the loop and used to check each button. Question 4: I'm also confused. If you do not want rounded corners why don't you use a simple BOX with square corners? Hopefully this fragment gives you a clue. Note that it uses a GOTO which is generally considered bad programming but in this is case it is the only thing that will work. Note also that the main screen also waits for any touch to be removed. This is needed as control might have returned from the second screen (via the EXIT button) and the user's finger might still be touching the screen. Geoff ' main screen JumpBack: CLS ' jump back to here when we return to this screen InitBtn 0, 204, 0, 116, 28, RGB(cyan), RGB(black), "SCREEN 2" InitBtn 1, 204, 62, 116, 28, RGB(cyan) , RGB(black), "CHANGE" ' etc DO WHILE TOUCH(x) <> -1 : LOOP ' wait for any touch to be removed DO IF CheckBtnDown(0) THEN Screen2Sub GOTO JumpBack ' re init the screen ENDIF IF CheckBtnDown(1) THEN ' < do whatever button 1 needed done> WaitBtnUp(1) ENDIF 'etc LOOP ' subsidiary screen SUB Screen2Sub CLS InitBtn 0, 0, 206, 195, 36, RGB(red) , RGB(black), "ACTION" InitBtn 1, 207, 206, 112, 36, RGB(white) , RGB(black), "EXIT" ' etc DO WHILE TOUCH(x) <> -1 : LOOP ' wait for touch to be removed DO IF CheckBtnDown(0) THEN ' < do whatever button 0 needed done> WaitBtnUp(0) ENDIF IF CheckBtnDown(1) THEN EXIT SUB ENDIF 'etc LOOP END SUB Edited 2020-06-17 22:05 by Geoffg Geoff Graham - http://geoffg.net |
||||
Chopperp Guru Joined: 03/01/2018 Location: AustraliaPosts: 1106 |
I started playing with pages myself a few weeks ago. Bit of a learning curve especially trying to integrate them into an existing rats-nest. Still nowhere proficient. One thing I found you can't do is jump to another page while still in a loop. To go to another page, I had cleared the screen but unwanted data was still coming up although I had flagged the operating loop to stop. I eventually realised that I had to use the page button to not only flag the loop to stop but also at the end of the loop, to then clear the screen & then go to the desired page. The loop flag gets reset on returning to the original page allowing the loop to continue. Good stuff when you can get it to work. There's so much to learn.. Brian ChopperP |
||||
| Andrew_G Guru Joined: 18/10/2016 Location: AustraliaPosts: 872 |
Geoff and Brian, Many thanks for your quick replies (Geoff in particular because you must be busy with the "launch" of CMM2 shortly - Good Luck!). I've copied Geoff's code into a mini program and (of course) I can't replicate what I had seen in my spaghetti (which I thought was doing similarly - clearly not). I think it may have been my workaround of Touch for -ve coordinates - definitely binned. I have seen in others' code a say 200ms PAUSE before Waitup to accentuate the reverse video - is that a no-no? The main thing is that you have shown that it should not be doing what I thought it was, and that I should simplify the code before building up to the more complex version. Thanks again and cheers, Andrew |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
I'm not sure that it is needed but give it a try, you will not hurt anything. Geoff Geoff Graham - http://geoffg.net |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1646 |
Geoff, Thank you for the paging demo program above. I think it would be a worthy addition to your Getting Started With the Micromite document. One question though please, if there were (say) one or more extra buttons on the main page, than on the secondary page(s) they should be disabled to prevent strange results. What would be the preferred method of disabling them? Perhaps calling a SUB to use InitBtn to zero all of the parameters of all of the available buttons (NbrBtn) in a FOR-NEXT loop before initialising the buttons on that page. Probably answered my own question. Bill Keep safe. Live long and prosper. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
I think that the first question is: What Micromite are you using? How many pins does it have? Perhaps you are confused by the Advanced Controls on the Micromite Plus. They are completely different... they are managed by MMBasic for you and yes, you do need to enable/disable them. However, the code in that part of the manual is intended for the standard 28 or 44-pin Micromite. The buttons are not "enabled" or "disabled" they are just drawn on the screen by InitBtn which also stores the details of each button in the arrays. Then CheckBtnDown and WaitBtnUp redraws them depending on the what is in the arrays and the touch - if you don't call CheckBtnDown and WaitBtnUp then nothing will happen. There is nothing secret happening here, your program is in charge of everything. You can use this code on the Micromite Plus if you wish but you should not confuse it with the Advanced Controls. Geoff Geoff Graham - http://geoffg.net |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1646 |
Sorry for the confusion. I'm just referring to the Micromite 170 backpack. In your example program above, you reuse buttons 0 and 1 on the sub page. If there was a third button on the main (first) page then it would still be able to be 'pushed' accidentally on the sub page even though you cannot see it because of the CLS. Unless I'm wrong. I thought it was best to 'disable' it by setting the parameters for that button to zero so the touch area is not detected. I do realise that if you don't check for button 2 down on the sub page there won't be an issue. I just thought it would be 'untidy' to leave it there. That's why I was waffling on about 'disabling' all of the buttons by setting their various array elements to zero before defining new ones. Sorry if I'm wasting your time. Bill Keep safe. Live long and prosper. |
||||
| Andrew_G Guru Joined: 18/10/2016 Location: AustraliaPosts: 872 |
Bill, If I may help clarify (Geoff is of course the font and can better explain why it works - but he may be distracted by CMM2 at present). I'm using a MM170 Backpack too (Mk3) and my original post asked the same questions. Having used Geoff's example above in a small test program - it works! That is, if you InitBtn say 5 buttons but in a subsequent screen (ie after you have CLS 'ed) you only InitBtn say 2 buttons ONLY those 2 buttons are active (in that subroutine (or portion of code)) - the other, previously InitBtns are no longer active. (There is no need (or mechanism?) to deactivate them?) Indeed, if you return and want to reuse them, then they must be InitBtn ed again. So you can have multiple Btn0, Btn1 . . .Btnx in a program (but only one of each in each screen). Brian's point about leaving DO-LOOPs cleanly also seems to help (so if you ARE having strange effects set a flag, then after you've left the loop test for the flag and then act on it (but I have found occasions when you can go straight to another portion of code). I've also built on Geoff's example to show (to myself) that: - there may be occasions when you want to execute code before WaitBtnUp(x) and others when you execute code after WaitBtnUp. - a short (say 200ms) PAUSE after the IF CheckBtnDown(x) slightly enhances the look of it all, but does delay proceedings (in my case this it not mission critical). I also note that Geoff has used several subtly different examples over several projects and they all work - this just proves that there is no one "right" way. Does that help? Cheers, Andrew |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1646 |
But surely after you have CLS'd the extra buttons are still defined. Their touch areas are still defined. If you touch the area that is defined by them and test for that touch you will get a positive result. Of course if you only have two buttons defined on the sub screen and only test for two there will not be a problem but if you touch the area defined for the third button and test for it you will get a positive result even though you have not defined it on the sub screen. I'm sorry but I don't think I am making myself clear. I just think it would be good practice to clear the definitions of unused buttons on sub screens. Bill Keep safe. Live long and prosper. |
||||
| Andrew_G Guru Joined: 18/10/2016 Location: AustraliaPosts: 872 |
Hi Bill, I don't know the innards of Geoff's MMBasic to explain the "why/how" but add some buttons to Geoff's code above then call a subroutine with fewer buttons (and which starts with a CLS) and you will see that the "unused" buttons are not active. Andrew |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1646 |
Andrew, It looks like I will have to setup a system tomorrow to prove this but in the following excerpt from Geoff's code above: ' main screen JumpBack: CLS ' jump back to here when we return to this screen InitBtn 0, 204, 0, 116, 28, RGB(cyan), RGB(black), "SCREEN 2" InitBtn 1, 204, 62, 116, 28, RGB(cyan) , RGB(black), "CHANGE" ' etc If you insert a CLS after the 'etc and leave the rest of the code as is you will have a blank screen but the initialised buttons will surely still work? Just because the buttons are not visible doesn't that they won't work. If you touch the area defined by the InitBtn SUB they will stll do their job. Does this explain what I am trying to say? Bill Keep safe. Live long and prosper. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
