|
|
Post by BeeTrap on Jan 21, 2019 12:46:45 GMT -5
Hello, this is going to be a NOVICE question so that is why it is in this section....... I have been playing around with several LBASIC code segments/programs from this forum and from the emails from the Yahoo Users Group. Rod, tsh73 and Stefan Pendl have posted several items that have me curious. I have used the WAIT command myself and have just accepted what it does. But, especially after running Stefan's 2nd "REPLY" on the Yahoo Users Group about "Timer_Clock on menu bar" with the RESIZEHANDLER, I wonder, is there a way to TRACK where or what is in control at the moment during a WAIT? Is there a way to follow WAIT better than what I see in Debug? I just found it interesting to Step Through the code and watch the actual movement through the code. I know that there is a "handler" assigned that is "IN CHARGE", but how to KNOW? This may seem simple to most, but is bugging the heck out of me. Please forgive me, I have too much time on my hands and so.............. Oh and thanks for all the code, everyone!!! Mr. Gundel, hope that you are feeling better!
|
|
|
|
Post by Rod on Jan 21, 2019 13:25:05 GMT -5
We are discussing program flow. You could PRINT where you are prior to entering the WAIT state.
Don’t over think it, WAIT, any WAIT, just halts the program until an event diverts it elsewhere.
|
|
|
|
Post by Carl Gundel on Jan 21, 2019 16:30:28 GMT -5
We are discussing program flow. You could PRINT where you are prior to entering the WAIT state. Don’t over think it, WAIT, any WAIT, just halts the program until an event diverts it elsewhere. That's right. There is no assigned handler for a WAIT. The handler is either from a TIMER or from an event that comes from a window or button, listbox, etc. |
|
|
|
Post by BeeTrap on Jan 21, 2019 22:35:02 GMT -5
Thanks guys. Yes Rod, I probably am overthinking it. I always want to know "what is going on under the hood", so to speak. And Mr. Gundel, I have noticed that what I consider curious behavior is usually after a TIMER statement that jumps to a Branch Label and a loop begins in that Branch. Thanks again, to all!
Edit: Ok, I just searched through the sample code files and lines 74-94 of SC3sol.bas pretty well define what I had expected was happening. Just wanted some verification.
|
|
|
|
Post by Carl Gundel on Jan 21, 2019 23:10:45 GMT -5
And Mr. Gundel, I have noticed that what I consider curious behavior is usually after a TIMER statement that jumps to a Branch Label and a loop begins in that Branch.
Do you have any more detailed information about this?  |
|
|
|
Post by BeeTrap on Jan 22, 2019 6:46:54 GMT -5
No I don't. I was just noticing that when running any of this code in Debug, that the Highlight that shows current location, never gets back to "Timer" line. That is why I assumed that what was currently running was under the control of, or initiated by, the "TIMER". I understand having the TIMER in control, but there can be other controls, belonging to a window, or the keyboard or other in control. I was just curious as to how to know WHAT has control of, or initiated by, the current process. What Rod stated would at least let me know which POSSIBLE CONTROL was seen last. This is not a problem, just a curiosity on my part. Thanks.
|
|
|
|
Post by Rod on Jan 22, 2019 8:32:44 GMT -5
This isn't the best way to think about it. At a WAIT statement the program has stopped, Any WAIT statement anywhere in the code will stop the program. At that point NOTHING is in control. The program just sits idle "waiting" for an event to appear. Either from the TIMER or from Mouse or Keyboard input. So the first event takes control and the program continues to that events handler either a [branch] or a Sub handler.
|
|
|
|
Post by BeeTrap on Jan 22, 2019 13:01:57 GMT -5
Ok, thanks Rod. That makes much more sense to me now.  |
|
