A DLL question


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 7 of 7

Thread: A DLL question

  1. #1
    Laurence Hunter Guest

    A DLL question

    Hi -

    I am designing a dll to handle a number of different tasks and I am thinking
    about how to let the Users know the progress of DLL in processing their
    requests. I initially put together an event that would be fired at regular
    intervals and figured that the program could then respond to the event.

    I am thinking that there might be a better way to do this.

    What I am wondering is whether or not its a good thing to include a form
    within the DLL. That way, when the progress bar needs to be displayed, the
    DLL takes care of all of the work ... and the client can be left ignorant of
    it all.

    Is this a good thing to do? Or, am I openning up a whole can of worms that
    should really be left untouched?

    Larry



  2. #2
    Tom Esh Guest

    Re: A DLL question

    That's the sort of decision you may not want to hard-code into the
    component, but rather allow yourself a choice when using it. For
    example you could expose both a "Progress" event and a "ShowProgress"
    property.

    On Tue, 5 Jun 2001 13:19:32 -0400, "Laurence Hunter"
    <hunterlmc@hotmail.com> wrote:
    >I am designing a dll to handle a number of different tasks and I am thinking
    >about how to let the Users know the progress of DLL in processing their
    >requests. I initially put together an event that would be fired at regular
    >intervals and figured that the program could then respond to the event.
    >
    >I am thinking that there might be a better way to do this.
    >
    >What I am wondering is whether or not its a good thing to include a form
    >within the DLL. That way, when the progress bar needs to be displayed, the
    >DLL takes care of all of the work ... and the client can be left ignorant of
    >it all.
    >
    >Is this a good thing to do? Or, am I openning up a whole can of worms that
    >should really be left untouched?
    >
    >Larry
    >
    >



    -Tom
    (please post replies to the newsgroup)

  3. #3
    Laurence Hunter Guest

    Re: A DLL question

    So, what you are saying is that, to be very flexible, I should encompass
    both within the DLL and then let the User/Programmers decide which they
    would prefer to work with. Is that right?

    Larry




    "Tom Esh" <tjeshGibberish@earthlink.net> wrote in message
    news:3b1d1d0f.19210539@news.devx.com...
    > That's the sort of decision you may not want to hard-code into the
    > component, but rather allow yourself a choice when using it. For
    > example you could expose both a "Progress" event and a "ShowProgress"
    > property.
    >
    > On Tue, 5 Jun 2001 13:19:32 -0400, "Laurence Hunter"
    > <hunterlmc@hotmail.com> wrote:
    > >I am designing a dll to handle a number of different tasks and I am

    thinking
    > >about how to let the Users know the progress of DLL in processing their
    > >requests. I initially put together an event that would be fired at

    regular
    > >intervals and figured that the program could then respond to the event.
    > >
    > >I am thinking that there might be a better way to do this.
    > >
    > >What I am wondering is whether or not its a good thing to include a form
    > >within the DLL. That way, when the progress bar needs to be displayed,

    the
    > >DLL takes care of all of the work ... and the client can be left ignorant

    of
    > >it all.
    > >
    > >Is this a good thing to do? Or, am I openning up a whole can of worms

    that
    > >should really be left untouched?
    > >
    > >Larry
    > >
    > >

    >
    >
    > -Tom
    > (please post replies to the newsgroup)




  4. #4
    Tom Esh Guest

    Re: A DLL question

    On Tue, 5 Jun 2001 16:22:58 -0400, "Laurence Hunter"
    <hunterlmc@hotmail.com> wrote:
    >So, what you are saying is that, to be very flexible, I should encompass
    >both within the DLL and then let the User/Programmers decide which they
    >would prefer to work with. Is that right?

    Yep. Plus that way it can be your idea to begin with, rather than
    someone else's later on <g>.

    -Tom
    (please post replies to the newsgroup)

  5. #5
    Willy Van den Driessche Guest

    Re: A DLL question


    "Laurence Hunter" <hunterlmc@hotmail.com> wrote:
    >Hi -
    >
    >I am designing a dll to handle a number of different tasks and I am thinking
    >about how to let the Users know the progress of DLL in processing their
    >requests. I initially put together an event that would be fired at regular
    >intervals and figured that the program could then respond to the event.
    >
    >I am thinking that there might be a better way to do this.
    >
    >What I am wondering is whether or not its a good thing to include a form
    >within the DLL. That way, when the progress bar needs to be displayed,

    the
    >DLL takes care of all of the work ... and the client can be left ignorant

    of
    >it all.
    >
    >Is this a good thing to do? Or, am I openning up a whole can of worms that
    >should really be left untouched?
    >
    >Larry
    >
    >


    Larry,
    Generally when you want to report progress, it has something of a looplike
    behavior. You have a working class which is doing something lengthy (from
    1 to N) and you typically want to show a progressbar. Additionally you might
    want to be able to cancel the operation in the middle.
    If this is the case, then you might want to introduce the concept of an iWorker.
    The interface goes like this :

    Public Property Get ProgressEvents() As cProgressEvents
    Public Sub StartTask()
    Public Property Get CanCancel () as boolean
    Public Sub Cancel() ' never called if canCancel is False


    You need the additional cProgressEvents class to be able to emit events from
    an interface. The class is rather straightforward and goes like this :
    Public Event Start(nCountValues As Long, strLabel As String)
    Public Event Progress(nCurrentPos As Long)
    Public Event Complete()

    Public Sub Start(Byval nCountValues As Long, Byval strLabel As String)
    RaiseEvent Start(nCountValues, strLabel)
    End Sub

    Public Sub Progress(Byval nCurrentPos As Long)
    RaiseEvent Progress(nCurrentPos)
    End Sub

    Public Sub Complete()
    RaiseEvent Complete
    End Sub

    You worker will be calling the methods. Any visual component will be catching
    the events.
    You could then write a method :
    StartWorker (byval objWorker as iWorker)

    This is the method that will retrieve the progress events objects from your
    worker and call start on your worker. If your worker decides it can cancel,
    the visual handler of the worker should display something like a Cancel button
    somewhere and call the iWorker.Cancel method when this is clicked.

    If one way to handle the progress of a worker is not enough, you could introduce
    the concept of a WorkerHandler. A singleton of this is installed and this
    thing will handle the call of StartWorker. This way the client code (which
    can be yours), just calls StartWorker. The handler will define how it shows
    up visually. We actually use this thing so that during startup of the application
    workers show as a progressbar on the splashscreen. Afterwards they just
    show in a dedicated form.

    Iff you're interested in this solution, I'll send you some code.


  6. #6
    Laurence Hunter Guest

    Re: A DLL question

    Ok -

    I think that I have it. It seems that I would be designing two separate
    class objects. The first "Working" object is the one that will do all of
    the work and will have the procedures that are called to transfer the files
    (this is an ftp class object that I am designing and I put/get files in
    chunks). However, in order to inform the outside world of the status of the
    transfer (and give them the opportunity to cancel the action) I would create
    a second class dedicated to raising the necessary events. This "Event"
    class object is instantiated as part of the "Working" object. Then, to make
    the events of the this object visible to the outside work, I would create a
    public property that returns a reference to the "Event" object.

    Is that about right? This type of programming work is somewhat new to me.

    Now, the next step for me is make the event visible to a status bar type of
    form that is an aspect of the dll itself but is not createable by the
    outside world. Only the internal workings of the dll can create or display
    this form. What I was originally thinking to do was create a reference to
    and display the form from within the "working" class. And then, if the User
    should click the cancel button an event is raised from within the form that
    the DLL responds to (probably switching a boolean "Cancel" variable from
    false to true. So, that when the next time that a chunk of data is
    transferred the ftp object would evaluate the "Cancel" variable; see that it
    was now true and then break out of the routine.

    Does this seem workable ... ? Or, have I just muddied the waters?

    Larry


    "Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote in
    message news:3b1e0fd9$1@news.devx.com...
    >
    > "Laurence Hunter" <hunterlmc@hotmail.com> wrote:
    > >Hi -
    > >
    > >I am designing a dll to handle a number of different tasks and I am

    thinking
    > >about how to let the Users know the progress of DLL in processing their
    > >requests. I initially put together an event that would be fired at regul

    ar
    > >intervals and figured that the program could then respond to the event.
    > >
    > >I am thinking that there might be a better way to do this.
    > >
    > >What I am wondering is whether or not its a good thing to include a form
    > >within the DLL. That way, when the progress bar needs to be displayed,

    > the
    > >DLL takes care of all of the work ... and the client can be left ignorant

    > of
    > >it all.
    > >
    > >Is this a good thing to do? Or, am I openning up a whole can of worms

    that
    > >should really be left untouched?
    > >
    > >Larry
    > >
    > >

    >
    > Larry,
    > Generally when you want to report progress, it has something of a looplike
    > behavior. You have a working class which is doing something lengthy (from
    > 1 to N) and you typically want to show a progressbar. Additionally you

    might
    > want to be able to cancel the operation in the middle.
    > If this is the case, then you might want to introduce the concept of an

    iWorker.
    > The interface goes like this :
    >
    > Public Property Get ProgressEvents() As cProgressEvents
    > Public Sub StartTask()
    > Public Property Get CanCancel () as boolean
    > Public Sub Cancel() ' never called if canCancel is False
    >
    >
    > You need the additional cProgressEvents class to be able to emit events

    from
    > an interface. The class is rather straightforward and goes like this :
    > Public Event Start(nCountValues As Long, strLabel As String)
    > Public Event Progress(nCurrentPos As Long)
    > Public Event Complete()
    >
    > Public Sub Start(Byval nCountValues As Long, Byval strLabel As String)
    > RaiseEvent Start(nCountValues, strLabel)
    > End Sub
    >
    > Public Sub Progress(Byval nCurrentPos As Long)
    > RaiseEvent Progress(nCurrentPos)
    > End Sub
    >
    > Public Sub Complete()
    > RaiseEvent Complete
    > End Sub
    >
    > You worker will be calling the methods. Any visual component will be

    catching
    > the events.
    > You could then write a method :
    > StartWorker (byval objWorker as iWorker)
    >
    > This is the method that will retrieve the progress events objects from

    your
    > worker and call start on your worker. If your worker decides it can

    cancel,
    > the visual handler of the worker should display something like a Cancel

    button
    > somewhere and call the iWorker.Cancel method when this is clicked.
    >
    > If one way to handle the progress of a worker is not enough, you could

    introduce
    > the concept of a WorkerHandler. A singleton of this is installed and this
    > thing will handle the call of StartWorker. This way the client code

    (which
    > can be yours), just calls StartWorker. The handler will define how it

    shows
    > up visually. We actually use this thing so that during startup of the

    application
    > workers show as a progressbar on the splashscreen. Afterwards they just
    > show in a dedicated form.
    >
    > Iff you're interested in this solution, I'll send you some code.
    >




  7. #7
    Willy Van den Driessche Guest

    Re: A DLL question


    "Laurence Hunter" <hunterlmc@hotmail.com> wrote:
    >Ok -
    >
    >I think that I have it. It seems that I would be designing two separate
    >class objects. The first "Working" object is the one that will do all of
    >the work and will have the procedures that are called to transfer the files
    >(this is an ftp class object that I am designing and I put/get files in
    >chunks). However, in order to inform the outside world of the status of

    the
    >transfer (and give them the opportunity to cancel the action) I would create
    >a second class dedicated to raising the necessary events. This "Event"
    >class object is instantiated as part of the "Working" object. Then, to

    make
    >the events of the this object visible to the outside work, I would create

    a
    >public property that returns a reference to the "Event" object.
    >
    >Is that about right? This type of programming work is somewhat new to me.
    >


    So far so good

    >Now, the next step for me is make the event visible to a status bar type

    of
    >form that is an aspect of the dll itself but is not createable by the
    >outside world. Only the internal workings of the dll can create or display
    >this form. What I was originally thinking to do was create a reference

    to
    >and display the form from within the "working" class. And then, if the

    User
    >should click the cancel button an event is raised from within the form that
    >the DLL responds to (probably switching a boolean "Cancel" variable from
    >false to true. So, that when the next time that a chunk of data is
    >transferred the ftp object would evaluate the "Cancel" variable; see that

    it
    >was now true and then break out of the routine.
    >
    >Does this seem workable ... ? Or, have I just muddied the waters?
    >
    >Larry
    >

    Completely correct too.
    The main thing I am trying to say, however is that
    1) the interface IWorker is constant. Specify it once an never ever change
    it again.
    2) the class cProgressEvents is constant. Implement it once and forget about
    it. (It is only necessary because you want events to come out of an interface
    - DOT Net (as far as we've been able to see it) allows interfaces to define
    their own events and thus doesn't require this separate class)
    3) The form (or component or whatever that listens to the worker) is constant.

    The only variant thing is the implementation of the worker. So if you have
    multiple workers you only need to implement the interface and call StartWorker
    new myClass. In my own implementation, the definition of the stable things
    in this design are encapsulated into a separate component. There are many
    (I believe currently 40 or so) implementations of the iWorker interface.
    But using the interface mechanism makes sure that everything is consistent.

    >
    >"Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote in
    >message news:3b1e0fd9$1@news.devx.com...
    >>
    >> "Laurence Hunter" <hunterlmc@hotmail.com> wrote:
    >> >Hi -
    >> >
    >> >I am designing a dll to handle a number of different tasks and I am

    >thinking
    >> >about how to let the Users know the progress of DLL in processing their
    >> >requests. I initially put together an event that would be fired at regul

    >ar
    >> >intervals and figured that the program could then respond to the event.
    >> >
    >> >I am thinking that there might be a better way to do this.
    >> >
    >> >What I am wondering is whether or not its a good thing to include a form
    >> >within the DLL. That way, when the progress bar needs to be displayed,

    >> the
    >> >DLL takes care of all of the work ... and the client can be left ignorant

    >> of
    >> >it all.
    >> >
    >> >Is this a good thing to do? Or, am I openning up a whole can of worms

    >that
    >> >should really be left untouched?
    >> >
    >> >Larry
    >> >
    >> >

    >>
    >> Larry,
    >> Generally when you want to report progress, it has something of a looplike
    >> behavior. You have a working class which is doing something lengthy (from
    >> 1 to N) and you typically want to show a progressbar. Additionally you

    >might
    >> want to be able to cancel the operation in the middle.
    >> If this is the case, then you might want to introduce the concept of an

    >iWorker.
    >> The interface goes like this :
    >>
    >> Public Property Get ProgressEvents() As cProgressEvents
    >> Public Sub StartTask()
    >> Public Property Get CanCancel () as boolean
    >> Public Sub Cancel() ' never called if canCancel is False
    >>
    >>
    >> You need the additional cProgressEvents class to be able to emit events

    >from
    >> an interface. The class is rather straightforward and goes like this

    :
    >> Public Event Start(nCountValues As Long, strLabel As String)
    >> Public Event Progress(nCurrentPos As Long)
    >> Public Event Complete()
    >>
    >> Public Sub Start(Byval nCountValues As Long, Byval strLabel As String)
    >> RaiseEvent Start(nCountValues, strLabel)
    >> End Sub
    >>
    >> Public Sub Progress(Byval nCurrentPos As Long)
    >> RaiseEvent Progress(nCurrentPos)
    >> End Sub
    >>
    >> Public Sub Complete()
    >> RaiseEvent Complete
    >> End Sub
    >>
    >> You worker will be calling the methods. Any visual component will be

    >catching
    >> the events.
    >> You could then write a method :
    >> StartWorker (byval objWorker as iWorker)
    >>
    >> This is the method that will retrieve the progress events objects from

    >your
    >> worker and call start on your worker. If your worker decides it can

    >cancel,
    >> the visual handler of the worker should display something like a Cancel

    >button
    >> somewhere and call the iWorker.Cancel method when this is clicked.
    >>
    >> If one way to handle the progress of a worker is not enough, you could

    >introduce
    >> the concept of a WorkerHandler. A singleton of this is installed and

    this
    >> thing will handle the call of StartWorker. This way the client code

    >(which
    >> can be yours), just calls StartWorker. The handler will define how it

    >shows
    >> up visually. We actually use this thing so that during startup of the

    >application
    >> workers show as a progressbar on the splashscreen. Afterwards they just
    >> show in a dedicated form.
    >>
    >> Iff you're interested in this solution, I'll send you some code.
    >>

    >
    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center