ActiveX EXEs

[LegoPiece]

I have created an ActiveX Exe which instantiates an object, called 'plate', which behaves not unlike an 'oven'. Instead of cooking, it incubates for a specified duration. So, the client can call the 'incubate' method and go about its business. When the incubation period has elapsed, the plate object raises an event called "PlateReady". I've managed to implement this, and the PlateReady event gets received - however, it locks up the Client program, until it's ready - which to me defeats the purpose of having out-of-process components in the first place!

Here's what Incubate looks like

Public Sub Incubate()
'---------------------------------
Dim Units As Long
Dim Time As Integer
Dim TimeElapsed As Long

For Time = 0 To mlngIncubationTime Step 1000
'................................................................
DoEvents
Sleep (1000)
TimeElapsed = TimeElapsed + Time
RaiseEvent IncubationStatus(Str(TimeElapsed / 1000))
If TimeElapsed > mlngIncubationTime Then Exit For
'................................................................
Next Time

RaiseEvent PlateReady(mintIncubatorSlotIndex)
'---------------------------------
End Sub

The client program currently calls this method with a button click (which will be automated later) and it looks like this...

Private Sub cmdIncubate_Click()
'---------------------------------
DoEvents
Call TestPlate.Incubate
'---------------------------------
End Sub

Since The Plate object is formless, I have marked it for unattended execution, and I've tried both a thread pool and thread per object in its properties only to give the same result. The ultimate program will have to instantiate at least 30 of these plates as well as do a whole bunch of other stuff, which is why I'm doing this out-of-process.

Any ideas? (By the way, the Plate class' instancing property is set to Multi-Use).

Peace
Lego

"People have accused us of releasing the same album 16 times - that's simply not true. We've released the same album 17 times!" - Angus Young, AC/DC

 

[LPlates]

It locks up because you call a sub which doesnt finish executing (sits in a loop) until the incubation period is over. Use a timer and call the date function to determine when the period has finished, that way the sub will fire the timer and exit, and NOT LOCK. You can use the RaiseEvent ..

RaiseEvent PlateReady(mintIncubatorSlotIndex)

in your timer if the criteria is met

 

[LPlates]

Here's a quick example, it incubates chicken eggs for 21 days...

Switch the comment tag on SaveSetting lines to simulate 21 days expiring

[blue]Public Sub [/blue]Incubate()

[green]'SaveSetting App.EXEName, "Incubation", "Chickens", DateAdd("d", -22, Date)
[/green]SaveSetting App.EXEName, "Incubation", "Chickens", Date

Timer1.Interval = 30000 [green]' 30 seconds
[/green]Timer1 = [blue]True
End Sub
[/blue]

[blue]Private Sub [/blue]Timer1_Timer()
[blue]Dim [/blue]incStartTime [blue]As String
[/blue]incStartTime = GetSetting(App.EXEName, "Incubation", "Chickens", Date)

[blue]If [/blue]Date - [blue]CDate[/blue](incStartTime) > mlngIncubationTime [blue]Then
[/blue]Timer1 = [blue]False

RaiseEvent [/blue]PlateReady(mintIncubatorSlotIndex)

[blue]End If
End Sub
[/blue]

 

[LazyMe]

>>which to me defeats the purpose of having out-of-process components in the first place!

This is a slight misunderstanding of you, I guess. Events are synchronous, firing them will mean waiting for a response. Just as calling a sub, function or whatever....


Greetings,
Rick

 

[LegoPiece]

Hey Guys, thanks for the feedback...

It appears that I misunderstood a few concpets here. I was under the impression that I could instantiate objects which could be instructed to execute methods, without tying up the client application (which could go on to do other things). I was hoping to implement an 'Asynchronous Callback' scenario, whereby the out-of-process objects would run in their own process space, thus freeing up the client program - and upon completion of methods notify the calling client through an asynchronous event that it is done.

So my next question is - if my Client instantiates an object, then calls a method - will the client program then ALWAYS have to hang and wait for the object to complete, irrespective of whether its in-process or out-of-process?

Lazy - By saying 'events are synchronous', what would constitute an 'Asynhronous Callback'?

Thanks again for all the help - It is very much appreciated.


Peace
Lego

"People have accused us of releasing the same album 16 times - that's simply not true. We've released the same album 17 times!" - Angus Young, AC/DC

 

[LPlates]

>So my next question is - if my Client instantiates an object, then calls a method - will the client program then ALWAYS have to hang and wait for the object to complete, irrespective of whether its in-process or out-of-process?

No, have a look at the example I posted, it will fire the timer and exit the sub, leaving your app to run without 'Locking up'.

 

[strongm]

>Events are synchronous

Oh no, not necessarily...

 

[LegoPiece]

LPlates - Thanks, I'm trying that out as we speak - will let you know how it transpires!

Strong - That's what I thought. It was my belief that events were asynchonous like interrupts, as opposed to 'polls', which mandate monitoring. Am I wrong in this assumption?

Peace
Lego

"People have accused us of releasing the same album 16 times - that's simply not true. We've released the same album 17 times!" - Angus Young, AC/DC

 

[LazyMe]

strongm
>>>Events are synchronous

Oh no, not necessarily...


Would you like to elaborate on that one a bit more, please?

Aren't events just plain old method calls incoming instead of outgoing (from the COM server's point of view)? I have never heard of being able to return from a method, or for that matter any part of a program, while still executing the following code? So for that to be asynchronously handled, wouldn't you need some sort of construction as LPlates suggested, or spawning another thread to do the actual work and so returning immediately (maybe specifying a callback function to have the result of the event returned by you, if necessary)?

So maybe I'm missing all the point here, or maybe I've been fairly poor with my explanation (although that wasn't really necessary since LPlates already explained how to "fake" asynchronous events) showing that the method you actually call is handled synchronously.

But if it is the case that I'm completely wrong (or maybe even a bit....); please explain a bit more...



Greetings,
Rick

 

[LazyMe]

And now that I'm awake a bit better; incoming and outgoing should of course be reversed (or the point of view should be moved to the COM client )

Greetings,
Rick

 

[strongm]

http://msdn.microsoft.com/library/d...dllproc/base/asynchronous_procedure_calls.asp

 

[LazyMe]

Thanks, but these are the inter thread communications (or whatever you would call such a mechanism), they do not deal with the connection point mechanism used by COM to fire events into clients (which is what legoPiece hoped would be asynchronous by using out of proc components.

It could be implemented in a way that the receiving thread would be the one actually firing the event into the client, though couldn't it? Only this would be almost the same as using LPate's solution or spawing another thread to do just that (imo). And futhermore; firing that event (no matter which thread does this) would still be a sycnhronous action, wouldn't it?

Greetings,
Rick

 

[strongm]

Ah. We're at cross-purposes, then. I was really talking about Windows events, and you are talking about COM events. However:

http://msdn.microsoft.com/msdnmag/issues/0400/async/default.aspx

(although the above would be difficult to achieve in VB...)

 

[LazyMe]

Yes, I wouldn't know how to implement that one in VB.....

Greetings,
Rick