|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
A Question of VB6 Asynchronicityprocessing, my first instinct would be to use a Timer control. Simply set Timer.Enabled = True, processing continues but when the Timer ticks, perhaps 5 milliseconds later, the desired code will begin to execute asynchronously. It may be simpler after all to just use a Command Button for this purpose. Setting CommandButton.Value = 1 in code causes the CommandButton_Click event to fire asynchronously. The difference between these approaches is that the Timer allows you to control the timing for the asynchronous event. However, since in most cases we want this to occur immediately, this is actually an unnecessary complexity. The Button click will occur immediately in any case without having to explicitly set a low Interval value. The only question I have is, to what degree is the 'threading model' of the Timer different than that of the Command Button? If there is a significant difference, than one of these approaches might yield a smoother asynchronous operation than the other. If you've had occasion to compare these two approaches, I'd be grateful for any guidance which you can provide. Thanks! - Joe Geretz - "Joseph Geretz" <jgeretz@nospam.com> wrote in message Bad news there Joseph..... you'll need to use an ActiveX EXE if you want news:OaoqWs0yFHA.1856@TK2MSFTNGP12.phx.gbl... > > The only question I have is, to what degree is the 'threading model' of > the Timer different than that of the Command Button? If there is a > significant difference, than one of these approaches might yield a > smoother asynchronous operation than the other. > async processing. Snipped from an earlier post... '============== Just so you're fully aware.... Timer's that run on the current thread are not asynchronous. When an event fires, the programs instruction pointer is saved and then moved to the top of the event handler procedure and will be returned to the saved address when the End Sub runs in that event handler procedure. Example.... Private Sub ABC() 1 code here 2 code here 3 code here 'timer event fires after running line 3 'code in timer's event handler starts 4 code here 5 code here 6 code here End Sub Private Sub Timer1_Timer() 'This entire procedure runs before 'returning to line 4 above 'it will never return until the line below runs End Sub '============== -- Ken Halter - MS-MVP-VB - http://www.vbsight.com DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm Please keep all discussions in the groups.. A Timer runs on the same thread as your App, so it's not async. Also, Timer
event will not fire in the middle of a procedure unless you where using DoEvents. To solve this problem in one case without ActiveX. I had to avoid lengthy operations and code that halts execution like MsgBox and Show vbModal. I made a MsgBox equivalent, so every routine takes only a fraction of a second, simulating multi threading. Obviously this is not suitable for all cases, so your only other option is to make an ActiveX Link to relevant documentation in MSDN: Scalability and Multithreading: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconprojectoptionsforcodecomponents.asp See the subtopics too. Show quoteHide quote "Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message news:OTacdw0yFHA.916@TK2MSFTNGP10.phx.gbl... > "Joseph Geretz" <jgeretz@nospam.com> wrote in message > news:OaoqWs0yFHA.1856@TK2MSFTNGP12.phx.gbl... >> >> The only question I have is, to what degree is the 'threading model' of >> the Timer different than that of the Command Button? If there is a >> significant difference, than one of these approaches might yield a >> smoother asynchronous operation than the other. >> > > Bad news there Joseph..... you'll need to use an ActiveX EXE if you want > async processing. > > Snipped from an earlier post... > '============== > Just so you're fully aware.... Timer's that run on the current thread are > not asynchronous. > When an event fires, the programs instruction pointer is saved and then > moved to the top of the event handler procedure and will be returned to > the saved address when the End Sub runs in that event handler procedure. > > Example.... > > > Private Sub ABC() > 1 code here > 2 code here > 3 code here > 'timer event fires after running line 3 > 'code in timer's event handler starts > 4 code here > 5 code here > 6 code here > End Sub > > > Private Sub Timer1_Timer() > 'This entire procedure runs before > 'returning to line 4 above > 'it will never return until the line below runs > End Sub > > > '============== > > -- > Ken Halter - MS-MVP-VB - http://www.vbsight.com > DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm > Please keep all discussions in the groups.. > > Opps. I incorrectly suggested that Timer event will not fire if you use
"Show vbModal", however it does. I also found that a MsgBox in Form2 will block Timer event in Form1, so MsgBoxes would create problems for you. "Someone" <nob***@cox.net> wrote in message news:S%v1f.1958$MN6.1273@fed1read04...Show quoteHide quote >A Timer runs on the same thread as your App, so it's not async. Also, Timer >event will not fire in the middle of a procedure unless you where using >DoEvents. > > To solve this problem in one case without ActiveX. I had to avoid lengthy > operations and code that halts execution like MsgBox and Show vbModal. I > made a MsgBox equivalent, so every routine takes only a fraction of a > second, simulating multi threading. Obviously this is not suitable for all > cases, so your only other option is to make an ActiveX > > Link to relevant documentation in MSDN: > > Scalability and Multithreading: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconprojectoptionsforcodecomponents.asp > > See the subtopics too. > > > > "Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message > news:OTacdw0yFHA.916@TK2MSFTNGP10.phx.gbl... >> "Joseph Geretz" <jgeretz@nospam.com> wrote in message >> news:OaoqWs0yFHA.1856@TK2MSFTNGP12.phx.gbl... >>> >>> The only question I have is, to what degree is the 'threading model' of >>> the Timer different than that of the Command Button? If there is a >>> significant difference, than one of these approaches might yield a >>> smoother asynchronous operation than the other. >>> >> >> Bad news there Joseph..... you'll need to use an ActiveX EXE if you want >> async processing. >> >> Snipped from an earlier post... >> '============== >> Just so you're fully aware.... Timer's that run on the current thread are >> not asynchronous. >> When an event fires, the programs instruction pointer is saved and then >> moved to the top of the event handler procedure and will be returned to >> the saved address when the End Sub runs in that event handler procedure. >> >> Example.... >> >> >> Private Sub ABC() >> 1 code here >> 2 code here >> 3 code here >> 'timer event fires after running line 3 >> 'code in timer's event handler starts >> 4 code here >> 5 code here >> 6 code here >> End Sub >> >> >> Private Sub Timer1_Timer() >> 'This entire procedure runs before >> 'returning to line 4 above >> 'it will never return until the line below runs >> End Sub >> >> >> '============== >> >> -- >> Ken Halter - MS-MVP-VB - http://www.vbsight.com >> DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm >> Please keep all discussions in the groups.. >> >> > > Maybe I'm using the term 'asynchronous' incorrectly (or maybe I am not). I
suspect that this term may mean different things at different levels. If there is a precise definition of asynchronicity which requires multiple threads (or for that matter multiple CPU's) to provide true asynchronicity, I am not aware of it. (But I'm eager to be educated.) What synchronicity means to me is that code statements operate in linear sequence. From the project attached: txtStatus = "Begin Synchronous Execution" frmModal.Show vbModal, Me txtStatus = "Finished Synchronous Execution" The statements above operate synchronously, in linear sequence. (Of course, I'm using modality, rather than a blocking method call in order to 'halt execution' on the second statement. (Perhaps If I were to use a VB6 blocking method in order to impose a block, I'd see different results. But that's not my scenario.) txtStatus = "Begin Asynchronous Execution" tmrAsync.Enabled = True txtStatus = "Finished Asynchronous Execution" In this second code sample, The second and third statements do not complete in sequence. That is, the processing kicked off in tmrAsync_Timer (frmModal.Show vbModal, Me) does not need to complete before the next statement executes. (See attached project for complete details and demonstration.) Again, the argument that true intra-process asynchronicity cannot be acheived with pure VB may be correct from a purely technical standpoint. However the point is largely moot since a significant amount of processing within a VB app takes place beneath our own VB6 code statements. I didn't write the code which imposes modality, but however it works it doesn't seem to block the thread on which my own code statements (e.g. txtStatus = "Finished Asynchronous Execution") executes. Is it true that VB applications, including developer code statements and window functions execute entirely on a single thread? So if it looks like asynchronicity and behaves like asynchronicity, why not call it asynchronicity? - Joe Geretz - "Someone" <nob***@cox.net> wrote in message news:fCw1f.1971$MN6.702@fed1read04...Show quoteHide quote > Opps. I incorrectly suggested that Timer event will not fire if you use [attached file: TestAsync.zip]> "Show vbModal", however it does. I also found that a MsgBox in Form2 will > block Timer event in Form1, so MsgBoxes would create problems for you. > > > "Someone" <nob***@cox.net> wrote in message > news:S%v1f.1958$MN6.1273@fed1read04... >>A Timer runs on the same thread as your App, so it's not async. Also, >>Timer >>event will not fire in the middle of a procedure unless you where using >>DoEvents. >> >> To solve this problem in one case without ActiveX. I had to avoid lengthy >> operations and code that halts execution like MsgBox and Show vbModal. I >> made a MsgBox equivalent, so every routine takes only a fraction of a >> second, simulating multi threading. Obviously this is not suitable for >> all >> cases, so your only other option is to make an ActiveX >> >> Link to relevant documentation in MSDN: >> >> Scalability and Multithreading: >> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconprojectoptionsforcodecomponents.asp >> >> See the subtopics too. >> >> >> >> "Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message >> news:OTacdw0yFHA.916@TK2MSFTNGP10.phx.gbl... >>> "Joseph Geretz" <jgeretz@nospam.com> wrote in message >>> news:OaoqWs0yFHA.1856@TK2MSFTNGP12.phx.gbl... >>>> >>>> The only question I have is, to what degree is the 'threading model' of >>>> the Timer different than that of the Command Button? If there is a >>>> significant difference, than one of these approaches might yield a >>>> smoother asynchronous operation than the other. >>>> >>> >>> Bad news there Joseph..... you'll need to use an ActiveX EXE if you want >>> async processing. >>> >>> Snipped from an earlier post... >>> '============== >>> Just so you're fully aware.... Timer's that run on the current thread >>> are >>> not asynchronous. >>> When an event fires, the programs instruction pointer is saved and then >>> moved to the top of the event handler procedure and will be returned to >>> the saved address when the End Sub runs in that event handler procedure. >>> >>> Example.... >>> >>> >>> Private Sub ABC() >>> 1 code here >>> 2 code here >>> 3 code here >>> 'timer event fires after running line 3 >>> 'code in timer's event handler starts >>> 4 code here >>> 5 code here >>> 6 code here >>> End Sub >>> >>> >>> Private Sub Timer1_Timer() >>> 'This entire procedure runs before >>> 'returning to line 4 above >>> 'it will never return until the line below runs >>> End Sub >>> >>> >>> '============== >>> >>> -- >>> Ken Halter - MS-MVP-VB - http://www.vbsight.com >>> DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm >>> Please keep all discussions in the groups.. >>> >>> >> >> > > My apologies for the attachments. They are quite small and I hope that they
don't inconvenience anyone. This second project attachment is an elaboration on the first in that it includes a sample *attempt* to use a Command Button to produce the same type of 'asynchronicity' as I can engineer using the Timer. It doesn't work! Very interesting. Clearly, Timer event execution is somehow engineered differently than Button Click event execution. I'm still interested in why multi-threading is a requisite feature for supporting asynchronicity. If this is indeed the case, how do we differentiate between the way the Timer_Timer event fires and the way Command_Click event fires? Or is the Timer actually operating on a separate thread from the main application? In which case it is after all possible to deliver some form of (limited) asynchronicity within a VB6 application? Thanks, - Joe Geretz - Show quoteHide quote "Joseph Geretz" <jgeretz@nospam.com> wrote in message [attached file: TestAsync.zip]news:%23o6Non1yFHA.2152@TK2MSFTNGP10.phx.gbl... > Maybe I'm using the term 'asynchronous' incorrectly (or maybe I am not). I > suspect that this term may mean different things at different levels. If > there is a precise definition of asynchronicity which requires multiple > threads (or for that matter multiple CPU's) to provide true > asynchronicity, > I am not aware of it. (But I'm eager to be educated.) > > What synchronicity means to me is that code statements operate in linear > sequence. From the project attached: > > txtStatus = "Begin Synchronous Execution" > frmModal.Show vbModal, Me > txtStatus = "Finished Synchronous Execution" > > The statements above operate synchronously, in linear sequence. (Of > course, > I'm using modality, rather than a blocking method call in order to 'halt > execution' on the second statement. (Perhaps If I were to use a VB6 > blocking > method in order to impose a block, I'd see different results. But that's > not > my scenario.) > > txtStatus = "Begin Asynchronous Execution" > tmrAsync.Enabled = True > txtStatus = "Finished Asynchronous Execution" > > In this second code sample, The second and third statements do not > complete > in sequence. That is, the processing kicked off in tmrAsync_Timer > (frmModal.Show vbModal, Me) does not need to complete before the next > statement executes. (See attached project for complete details and > demonstration.) > > Again, the argument that true intra-process asynchronicity cannot be > acheived with pure VB may be correct from a purely technical standpoint. > However the point is largely moot since a significant amount of processing > within a VB app takes place beneath our own VB6 code statements. I didn't > write the code which imposes modality, but however it works it doesn't > seem > to block the thread on which my own code statements (e.g. txtStatus = > "Finished Asynchronous Execution") executes. Is it true that VB > applications, including developer code statements and window functions > execute entirely on a single thread? > > So if it looks like asynchronicity and behaves like asynchronicity, why > not > call it asynchronicity? > > - Joe Geretz - > > "Someone" <nob***@cox.net> wrote in message > news:fCw1f.1971$MN6.702@fed1read04... >> Opps. I incorrectly suggested that Timer event will not fire if you use >> "Show vbModal", however it does. I also found that a MsgBox in Form2 will >> block Timer event in Form1, so MsgBoxes would create problems for you. >> >> >> "Someone" <nob***@cox.net> wrote in message >> news:S%v1f.1958$MN6.1273@fed1read04... >>>A Timer runs on the same thread as your App, so it's not async. Also, >>>Timer >>>event will not fire in the middle of a procedure unless you where using >>>DoEvents. >>> >>> To solve this problem in one case without ActiveX. I had to avoid >>> lengthy >>> operations and code that halts execution like MsgBox and Show vbModal. I >>> made a MsgBox equivalent, so every routine takes only a fraction of a >>> second, simulating multi threading. Obviously this is not suitable for >>> all >>> cases, so your only other option is to make an ActiveX >>> >>> Link to relevant documentation in MSDN: >>> >>> Scalability and Multithreading: >>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconprojectoptionsforcodecomponents.asp >>> >>> See the subtopics too. >>> >>> >>> >>> "Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message >>> news:OTacdw0yFHA.916@TK2MSFTNGP10.phx.gbl... >>>> "Joseph Geretz" <jgeretz@nospam.com> wrote in message >>>> news:OaoqWs0yFHA.1856@TK2MSFTNGP12.phx.gbl... >>>>> >>>>> The only question I have is, to what degree is the 'threading model' >>>>> of >>>>> the Timer different than that of the Command Button? If there is a >>>>> significant difference, than one of these approaches might yield a >>>>> smoother asynchronous operation than the other. >>>>> >>>> >>>> Bad news there Joseph..... you'll need to use an ActiveX EXE if you >>>> want >>>> async processing. >>>> >>>> Snipped from an earlier post... >>>> '============== >>>> Just so you're fully aware.... Timer's that run on the current thread >>>> are >>>> not asynchronous. >>>> When an event fires, the programs instruction pointer is saved and then >>>> moved to the top of the event handler procedure and will be returned to >>>> the saved address when the End Sub runs in that event handler >>>> procedure. >>>> >>>> Example.... >>>> >>>> >>>> Private Sub ABC() >>>> 1 code here >>>> 2 code here >>>> 3 code here >>>> 'timer event fires after running line 3 >>>> 'code in timer's event handler starts >>>> 4 code here >>>> 5 code here >>>> 6 code here >>>> End Sub >>>> >>>> >>>> Private Sub Timer1_Timer() >>>> 'This entire procedure runs before >>>> 'returning to line 4 above >>>> 'it will never return until the line below runs >>>> End Sub >>>> >>>> >>>> '============== >>>> >>>> -- >>>> Ken Halter - MS-MVP-VB - http://www.vbsight.com >>>> DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm >>>> Please keep all discussions in the groups.. >>>> >>>> >>> >>> >> >> > > > "Joseph Geretz" <jgeretz@nospam.com> wrote in message The reason the timer seems to work and the button doesn't is.....news:ulhzVx1yFHA.3812@TK2MSFTNGP09.phx.gbl... > My apologies for the attachments. They are quite small and I hope that > they don't inconvenience anyone. > Your code is simply enabling the timer before updating the "finished" box. The timer hasn't actually fired yet. When you set a button's value = True, that fires an event immediately (as opposed to waiting for the event queue to be processed like the timer's doing) This modified source shows that they are working the same.... once the code starts running anyway. '========= Option Explicit Private Sub DoTheWork() tmrAsync.Enabled = False frmModal.Show vbModal, Me txtStatus = "Finished Synchronous Execution" End Sub Private Sub cmdRaiseModalSync_Click() txtStatus = "Begin Synchronous Execution" frmModal.Show vbModal, Me txtStatus = "Finished Synchronous Execution" End Sub Private Sub cmdRaiseModalAsync_Click() txtStatus = "Begin Asynchronous Execution" If optTimer.Value = True Then tmrAsync.Enabled = True Else cmdAsync.Value = True End If End Sub Private Sub tmrAsync_Timer() Call DoTheWork End Sub Private Sub cmdAsync_Click() Call DoTheWork End Sub '========= VB code always runs from the beginning of a procedure to the end of a procedure. The only way to interrupt that flow is to use events. As previously mentioned, once the code in the event handler fires, it's going to run from the beginning of the procedure to the end of the procedure..... unless another event fires. That rule also applies to ActiveX exe's. They're not "automatically" async. You have to add code that stores any info you'd need to carry out the desired task, enable a timer and allow the code to return to the caller. When the timer fires, code in the timer event (inside the ax-exe) starts and performs the task. Basically the same as your attached project does with its timer. -- Ken Halter - MS-MVP-VB - http://www.vbsight.com DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm Please keep all discussions in the groups.. OK, if I understand this correctly, I guess the proper terminology for using
the Timer in this manner would be 'deferred' rather than 'asynchronous' execution. With asynchronous execution the server method begins to execute immediately; the execution of the server method is simultaneous asynchronous to the execution of the client method. With deferred execution, the client method requests a server method (the Timer event) but this method doesn't begin to execute until the client event completes. A subtle difference. I have found this type of deferred execution to be valuable in many scenarios. Thanks for your feedback! - Joe Geretz - P.S. What's with Command.Value = True anyway? Why not just call Command1_Click? Sometimes I have to wonder what the VB6 language developers had in mind. Maybe it's just a lazy man's way of exposing an otherwise Private event outside of its Form? :-( Show quoteHide quote "Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message news:%23FIYD02yFHA.3756@tk2msftngp13.phx.gbl... > "Joseph Geretz" <jgeretz@nospam.com> wrote in message > news:ulhzVx1yFHA.3812@TK2MSFTNGP09.phx.gbl... >> My apologies for the attachments. They are quite small and I hope that >> they don't inconvenience anyone. >> > > The reason the timer seems to work and the button doesn't is..... > > Your code is simply enabling the timer before updating the "finished" box. > The timer hasn't actually fired yet. > > When you set a button's value = True, that fires an event immediately (as > opposed to waiting for the event queue to be processed like the timer's > doing) > > This modified source shows that they are working the same.... once the > code starts running anyway. > '========= > Option Explicit > > Private Sub DoTheWork() > tmrAsync.Enabled = False > frmModal.Show vbModal, Me > txtStatus = "Finished Synchronous Execution" > End Sub > > Private Sub cmdRaiseModalSync_Click() > txtStatus = "Begin Synchronous Execution" > frmModal.Show vbModal, Me > txtStatus = "Finished Synchronous Execution" > End Sub > > Private Sub cmdRaiseModalAsync_Click() > txtStatus = "Begin Asynchronous Execution" > > If optTimer.Value = True Then > tmrAsync.Enabled = True > Else > cmdAsync.Value = True > End If > > End Sub > > Private Sub tmrAsync_Timer() > Call DoTheWork > End Sub > > Private Sub cmdAsync_Click() > Call DoTheWork > End Sub > '========= > > VB code always runs from the beginning of a procedure to the end of a > procedure. The only way to interrupt that flow is to use events. As > previously mentioned, once the code in the event handler fires, it's going > to run from the beginning of the procedure to the end of the > procedure..... unless another event fires. > > That rule also applies to ActiveX exe's. They're not "automatically" > async. You have to add code that stores any info you'd need to carry out > the desired task, enable a timer and allow the code to return to the > caller. When the timer fires, code in the timer event (inside the ax-exe) > starts and performs the task. Basically the same as your attached project > does with its timer. > > -- > Ken Halter - MS-MVP-VB - http://www.vbsight.com > DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm > Please keep all discussions in the groups.. > "Someone" <nob***@cox.net> wrote in message news:fCw1f.1971$MN6.702@fed1read04...> Opps. I incorrectly suggested that Timer event will not fire if you use Timers are blocked only in the IDE. Compiled timer events aren't blocked by > "Show vbModal", however it does. I also found that a MsgBox in Form2 will > block Timer event in Form1, so MsgBoxes would create problems for you. msgbox's starting with VB5/SP? (2 iirc) -- Ken Halter - MS-MVP-VB - http://www.vbsight.com DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm Please keep all discussions in the groups.. Hi Ken,
So are you saying that this advice which I received is incorrect? ------------------------------ If a context menu invokes a modal form, the context menu event queue is held until the modal form closes. Since an application can only have one context menu, attempts to show the second menu fail. This is normal. Either don't use modal windows invoked from a context menu, or if this is a requirement, have the context menu invoke a timer instead with an interval of about 500. In the timer event place the code to show the modal window, remembering to set the timer.enabled false before doing anything else. ------------------------------ The proposal is to invoke a Modal dialog from a Timer, rather than directly from a Pop-Up Menu to allow a) The original pop-up menu to close b) so that the Modal form can raise its own pop-up menu, under appropriate circumstances Doesn't this imply that the event invoked from the Timer runs asynchronously to the event raised by the Pop-Up menu? From thread 'Can't Raise Nested Context (pop-up) Menu' started 8/10/2005. Thanks for your help, - Joe Geretz - Show quoteHide quote "Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message news:OTacdw0yFHA.916@TK2MSFTNGP10.phx.gbl... > "Joseph Geretz" <jgeretz@nospam.com> wrote in message > news:OaoqWs0yFHA.1856@TK2MSFTNGP12.phx.gbl... >> >> The only question I have is, to what degree is the 'threading model' of >> the Timer different than that of the Command Button? If there is a >> significant difference, than one of these approaches might yield a >> smoother asynchronous operation than the other. >> > > Bad news there Joseph..... you'll need to use an ActiveX EXE if you want > async processing. > > Snipped from an earlier post... > '============== > Just so you're fully aware.... Timer's that run on the current thread are > not asynchronous. > When an event fires, the programs instruction pointer is saved and then > moved to the top of the event handler procedure and will be returned to > the saved address when the End Sub runs in that event handler procedure. > > Example.... > > > Private Sub ABC() > 1 code here > 2 code here > 3 code here > 'timer event fires after running line 3 > 'code in timer's event handler starts > 4 code here > 5 code here > 6 code here > End Sub > > > Private Sub Timer1_Timer() > 'This entire procedure runs before > 'returning to line 4 above > 'it will never return until the line below runs > End Sub > > > '============== > > -- > Ken Halter - MS-MVP-VB - http://www.vbsight.com > DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm > Please keep all discussions in the groups.. > > On Fri, 7 Oct 2005 10:26:30 -0400, "Joseph Geretz"
<jgeretz@nospam.com> wrote: >... The OS uses a worker thread to place (post) WM_TIMER messages in your>The only question I have is, to what degree is the 'threading model' of the >Timer different than that of the Command Button? If there is a significant >difference, than one of these approaches might yield a smoother asynchronous >operation than the other. app's msg queue. The timer event fires when your app (specifically the VB runtime) plucks WM_TIMER off the queue and processes it, which is why you won't get timer events during other code processing without a DoEvents. So in a nutshell, the only thing truly asychronous (or multi-threaded) about it is the placement of that WM_TIMER msg in the queue. -Tom MVP - Visual Basic (please post replies to the newsgroup) |
|||||||||||||||||||||||
Other interesting topics