Ecere SDK/eC Forums https://ecere.org/community/ Print view |
|
Confused with code behaviour https://ecere.org/community/viewtopic.php?f=5&t=413 |
Page 1 of 1 |
Author: | shakeshuck [ Sun Dec 13, 2015 5:55 pm ] |
Post subject: | Confused with code behaviour |
Sorry Jerome, I'm here again... I know it's not your job to help me debug my programs, but I'm struggling to work out what's going on with some sample code I've created; I can only guess that it's my lack of knowledge about the underlying gui code that's the problem. Either that or I've made a simple and stupid error and I'm looking in the wrong place. Here's my sample code: Code: Select all
Stepping through with the debugger appears to follow the correct logic, but what is then displayed doesn't follow what should be shown. Also, removing the break statements from the 'case' results in different behaviour, even though the debugger follows the same steps as before. It's probably me, but I'd like to make sure... |
Author: | jerome [ Sun Dec 13, 2015 9:12 pm ] |
Post subject: | Re: Confused with code behaviour |
Hi shakeshuck, I'm not exactly sure of the behavior you're looking for, but I imagine the biggest problem in the code you pasted is the fact that you're missing 'break' statements for the higher level case statements of the switch(upDown) in selectionMovement(). Code: Select all
Note that you could use a common NotifyKeyDown method on all 4 list boxes if you set the 'id' property of each listBox to 1,2,3,4 respectively (and then pass that to selectionMovement()) Another thing that may also be useful is ensuring you return 'false' in NotifyKeyDown() if you do process the key, so that it does not end up doing something else as well in another input handler. Cheers, Jerome |
Author: | shakeshuck [ Mon Dec 14, 2015 6:25 am ] |
Post subject: | Re: Confused with code behaviour |
This fixed it. Ah, the quirks of different languages... I also notice the lack of brackets in your example which makes it more readable. In this case it was a small section I'd taken from a larger program, I'll make sure it's all there in the full one! This is a good tip, thanks. I was wondering if there was a tidier way of doing it. This is the thing I was worried about the most; me not understanding the underlying processes and the consequences of changing stuff. I'll make a note to remember, thanks. Cheers Jerome! |
Author: | jerome [ Mon Dec 14, 2015 12:46 pm ] |
Post subject: | Re: Confused with code behaviour |
Yes You have to be careful to always have a 'break;' after each case in most C derived languages, unless you really intend for the code of the next case statement to be executed as well. Note that there is also the CycleChildren() method that you could invoke to do something similar (instead of calling MakeActive() on the controls)... You could handle that e.g. in the OnKeyHit() of the parent form: Code: Select all
|
Author: | shakeshuck [ Mon Dec 14, 2015 4:26 pm ] |
Post subject: | Re: Confused with code behaviour |
Following on from my original code posting, I've found another 'funny'. With this Button code: Code: Select all
Pressing the up key, for example, works as advertised as long as the key is not held down. Holding the key down seems to allow the behaviour to jump out of the requested flow. I am assuming it is some sort of timing issue (I guess the UI is threaded?). Is there someplace I need to add a 'pause' to stop this happening? |
Author: | jerome [ Tue Dec 15, 2015 1:12 am ] |
Post subject: | Re: Confused with code behaviour |
Hi shakeshuck, Holding the key down will generate additional OnKeyHit events. The first key down generates both an OnKeyDown, and if the input is allowed to continue (return true), an OnKeyHit. Try overriding OnKeyHit as well and returning false? Buttons by default have up/down selecting the next/previous control. (The ListBox or EditBox do not have that behavior because up/down is useful within those controls) You probably want to pass down input to the base Button class most of the times though (I see you're doing it specifically here for 'space'). You should also not return 'false' by default, because that will block a lot of things. You should only return 'false' if you're doing something for this control as a result of the specific key message. The keyboard input model is also so that the parent window has greater control over the child controls. So if a parent form processes a key and returns false (it will receive the message first), then the children controls will not receive the keys. All events are processed in the main thread, the implementation of managing them could either use additional threads or not based on the UI driver implementation. Another note, if you're processing many keys you may want to use a 'switch' statement rather than multiple ifs |
Author: | shakeshuck [ Wed Dec 16, 2015 9:14 am ] |
Post subject: | Re: Confused with code behaviour |
Yup, that does it. I get what you're saying. Changed. Thanks. |
All times are UTC-05:00 | Page 1 of 1 |
Powered by phpBB® Forum Software © phpBB Limited |