how to pass over events in stacked objects?

I have written a class clsFINDFILE (which collects filenames calling
FindFirstFile and so on), and a second class clsBACKUP which contains some
backup jobs doing something like that:

DIM FF as clsFindFile
SET FF = New clsFindFile
FF.FindFiles path, filemask    'collecting files
SET FF=Nothing

That works well. Now I want to show the increasing number of found files in
the parent form which holds the clsBACKUP object. But how can I do that
without knowing explicitly the parent form's controls in the clsFINDFILE
class?

I inserted a RaiseEvent FileFound(number,filename) in the clsFINDFILE class,
but how can I receive the event in clsBACKUP  to fire there a new event back
to the parent form?

clsBACKUP will not be able to receive events from an object FF declared 'as
New', and declaring FF not as new will not allow me to access FF's
properties and methods.

Chaining the events is not a 'must be', if possible I would prefer receiving
an event directly in the parent form fired by FF. But I have no idea how to
do that.

"Bruno Köller" <mydevicenull@onlinehome.de>'s wild thoughts
were released on Fri, 27 May 2005 16:59:43 +0200 bearing the
following fruit:

>I have written a class clsFINDFILE (which collects filenames calling
>FindFirstFile and so on), and a second class clsBACKUP which contains some
>backup jobs doing something like that:
>
>DIM FF as clsFindFile
>SET FF = New clsFindFile
>FF.FindFiles path, filemask    'collecting files
>SET FF=Nothing
>
>That works well. Now I want to show the increasing number of found files in
>the parent form which holds the clsBACKUP object. But how can I do that
>without knowing explicitly the parent form's controls in the clsFINDFILE
>class?
>
>I inserted a RaiseEvent FileFound(number,filename) in the clsFINDFILE class
,
>but how can I receive the event in clsBACKUP  to fire there a new event bac
k
>to the parent form?
>
>clsBACKUP will not be able to receive events from an object FF declared 'as
>New', and declaring FF not as new will not allow me to access FF's
>properties and methods.
>
>Chaining the events is not a 'must be', if possible I would prefer receivin
g
>an event directly in the parent form fired by FF. But I have no idea how to
>do that.
>

If FF is defined withevents in the form then the form can
recieve the event. Otherwise you will have to chain the
events.

btw you shouldn't be declaring anything 'as new' in any
case.







Jan Hyde (VB MVP)

--
Metallurgist: Someone who is allergic to iron.  (Leo Roston)

[Abolish the TV Licence - http://www.tvlicensing.biz/]

You'll need to bubble the event up from your clsFindFile through your
clsBackup which means you'll need to dimension your clsFindFile
variable (FF) at the module level using the WithEvents syntax.  If you
need a collection of your clsFindFile objects, you might want to have
a look at the Collection WithEvents example at
http://www.mvps.org/vbvision/  for a way in which to accomplish that.

HTH,
Bryan
 ________________________________________
____________________
New Vision Software                   "When the going gets weird,"
Bryan Stafford		              "the weird turn pro."
alpine_don'tsendspam@mvps.org     Hunter S. Thompson -
Microsoft MVP-Visual Basic     Fear and Loathing in LasVegas



On Fri, 27 May 2005 16:59:43 +0200, "Bruno Köller"
<mydevicenull@onlinehome.de> wrote:

>I have written a class clsFINDFILE (which collects filenames calling
>FindFirstFile and so on), and a second class clsBACKUP which contains some
>backup jobs doing something like that:
>
>DIM FF as clsFindFile
>SET FF = New clsFindFile
>FF.FindFiles path, filemask    'collecting files
>SET FF=Nothing
>
>That works well. Now I want to show the increasing number of found files in
>the parent form which holds the clsBACKUP object. But how can I do that
>without knowing explicitly the parent form's controls in the clsFINDFILE
>class?
>
>I inserted a RaiseEvent FileFound(number,filename) in the clsFINDFILE class
,
>but how can I receive the event in clsBACKUP  to fire there a new event bac
k
>to the parent form?
>
>clsBACKUP will not be able to receive events from an object FF declared 'as
>New', and declaring FF not as new will not allow me to access FF's
>properties and methods.
>
>Chaining the events is not a 'must be', if possible I would prefer receivin
g
>an event directly in the parent form fired by FF. But I have no idea how to
>do that.
>

On Fri, 27 May 2005 16:59:43 +0200, "Bruno Köller"
<mydevicenull@onlinehome.de> wrote:

>I have written a class clsFINDFILE (which collects filenames calling
>FindFirstFile and so on), and a second class clsBACKUP which contains some
>backup jobs doing something like that:
>
>DIM FF as clsFindFile

Dim WithEvents FF as clsFindFile

Actually: Private WithEvents FF as clsFindFile

Also you will need to Refresh the Label showing the progress

Ah, that will be in clsBACKUP

You'll need to raise another event in clsBACKUP to notify the parent
Form

BTW, good to see that you are tackling it in a nicely structured way

>SET FF = New clsFindFile
>FF.FindFiles path, filemask    'collecting files
>SET FF=Nothing
>
>That works well. Now I want to show the increasing number of found files in
>the parent form which holds the clsBACKUP object. But how can I do that
>without knowing explicitly the parent form's controls in the clsFINDFILE
>class?
>
>I inserted a RaiseEvent FileFound(number,filename) in the clsFINDFILE class
,
>but how can I receive the event in clsBACKUP  to fire there a new event bac
k
>to the parent form?
>
>clsBACKUP will not be able to receive events from an object FF declared 'as
>New', and declaring FF not as new will not allow me to access FF's
>properties and methods.
>
>Chaining the events is not a 'must be', if possible I would prefer receivin
g
>an event directly in the parent form fired by FF. But I have no idea how to
>do that.
>
>

> If FF is defined withevents in the form then the form can
> recieve the event. Otherwise you will have to chain the
> events.

That's why I asked...

> btw you shouldn't be declaring anything 'as new' in any
> case.

hmm, why not?