DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 4 of 4 FirstFirst ... 234
Results 46 to 55 of 55

Thread: Determining a file extension

  1. #46
    Karl E. Peterson Guest

    Re: Determining a file extension

    Hi Michael --

    > Slowest in terms of CPU cycles, yes. However, probably the fastest in terms
    > of development time. Also more reliable than reinventing the wheel
    > yourself. There's always a trade off.


    Hmmm, could be, for some. Me, I just drop in a routine I wrote (updated, actually)
    in 1994 for "VB4HT". Takes a coupla seconds, tops. :-)

    Later... Karl
    --
    http://www.mvps.org/vb



  2. #47
    Karl E. Peterson Guest

    Re: Determining a file extension

    Hi Michael --

    > Slowest in terms of CPU cycles, yes. However, probably the fastest in terms
    > of development time. Also more reliable than reinventing the wheel
    > yourself. There's always a trade off.


    Hmmm, could be, for some. Me, I just drop in a routine I wrote (updated, actually)
    in 1994 for "VB4HT". Takes a coupla seconds, tops. :-)

    Later... Karl
    --
    http://www.mvps.org/vb



  3. #48
    Michael Shutt Guest

    Re: Determining a file extension

    Yes, but at some point in time you had to write that routine, test and debug
    it. And, apparently, occassionally you have to update it. That was not a
    coupla seconds of effort.

    You wrote that before the Scripting library was available, so at the time
    you didn't have much of a choice. Now that you have it, you can certainly
    justify using it, especially if it is faster. But, if you haven't already
    written something like that, I think it makes more sense to use something
    that is already written (namely the Scripting library), unless you have some
    requirement for making faster routines. Just my 2 cents.

    --
    Michael Shutt

    Please respond to newsgroup as I will not return direct emails.

    "Karl E. Peterson" <karl@mvps.org> wrote in message
    news:3b682746$1@news.devx.com...
    > Hi Michael --
    >
    > > Slowest in terms of CPU cycles, yes. However, probably the fastest in

    terms
    > > of development time. Also more reliable than reinventing the wheel
    > > yourself. There's always a trade off.

    >
    > Hmmm, could be, for some. Me, I just drop in a routine I wrote (updated,

    actually)
    > in 1994 for "VB4HT". Takes a coupla seconds, tops. :-)
    >
    > Later... Karl
    > --
    > http://www.mvps.org/vb
    >
    >




  4. #49
    Michael Shutt Guest

    Re: Determining a file extension

    Yes, but at some point in time you had to write that routine, test and debug
    it. And, apparently, occassionally you have to update it. That was not a
    coupla seconds of effort.

    You wrote that before the Scripting library was available, so at the time
    you didn't have much of a choice. Now that you have it, you can certainly
    justify using it, especially if it is faster. But, if you haven't already
    written something like that, I think it makes more sense to use something
    that is already written (namely the Scripting library), unless you have some
    requirement for making faster routines. Just my 2 cents.

    --
    Michael Shutt

    Please respond to newsgroup as I will not return direct emails.

    "Karl E. Peterson" <karl@mvps.org> wrote in message
    news:3b682746$1@news.devx.com...
    > Hi Michael --
    >
    > > Slowest in terms of CPU cycles, yes. However, probably the fastest in

    terms
    > > of development time. Also more reliable than reinventing the wheel
    > > yourself. There's always a trade off.

    >
    > Hmmm, could be, for some. Me, I just drop in a routine I wrote (updated,

    actually)
    > in 1994 for "VB4HT". Takes a coupla seconds, tops. :-)
    >
    > Later... Karl
    > --
    > http://www.mvps.org/vb
    >
    >




  5. #50
    Karl E. Peterson Guest

    Re: Determining a file extension

    Hi Michael --

    I hear what you're saying, and I agree there are elements of sanity to it. Where it
    all breaks down for me, in this case, is the *external* dependency. If I have a
    simple and effective solution in native code, why would I want to risk the
    embarrassment of a missing or incompatible dependency? Just doesn't pencil out for
    me.

    Thanks... Karl
    --
    http://www.mvps.org/vb

    "Michael Shutt" <mshutt_nospam@mediaone.net> wrote in message
    news:3b69314b$1@news.devx.com...
    > Yes, but at some point in time you had to write that routine, test and debug
    > it. And, apparently, occassionally you have to update it. That was not a
    > coupla seconds of effort.
    >
    > You wrote that before the Scripting library was available, so at the time
    > you didn't have much of a choice. Now that you have it, you can certainly
    > justify using it, especially if it is faster. But, if you haven't already
    > written something like that, I think it makes more sense to use something
    > that is already written (namely the Scripting library), unless you have some
    > requirement for making faster routines. Just my 2 cents.
    >
    > --
    > Michael Shutt
    >
    > Please respond to newsgroup as I will not return direct emails.
    >
    > "Karl E. Peterson" <karl@mvps.org> wrote in message
    > news:3b682746$1@news.devx.com...
    > > Hi Michael --
    > >
    > > > Slowest in terms of CPU cycles, yes. However, probably the fastest in

    > terms
    > > > of development time. Also more reliable than reinventing the wheel
    > > > yourself. There's always a trade off.

    > >
    > > Hmmm, could be, for some. Me, I just drop in a routine I wrote (updated,

    > actually)
    > > in 1994 for "VB4HT". Takes a coupla seconds, tops. :-)
    > >
    > > Later... Karl
    > > --
    > > http://www.mvps.org/vb
    > >
    > >

    >
    >



  6. #51
    Karl E. Peterson Guest

    Re: Determining a file extension

    Hi Michael --

    I hear what you're saying, and I agree there are elements of sanity to it. Where it
    all breaks down for me, in this case, is the *external* dependency. If I have a
    simple and effective solution in native code, why would I want to risk the
    embarrassment of a missing or incompatible dependency? Just doesn't pencil out for
    me.

    Thanks... Karl
    --
    http://www.mvps.org/vb

    "Michael Shutt" <mshutt_nospam@mediaone.net> wrote in message
    news:3b69314b$1@news.devx.com...
    > Yes, but at some point in time you had to write that routine, test and debug
    > it. And, apparently, occassionally you have to update it. That was not a
    > coupla seconds of effort.
    >
    > You wrote that before the Scripting library was available, so at the time
    > you didn't have much of a choice. Now that you have it, you can certainly
    > justify using it, especially if it is faster. But, if you haven't already
    > written something like that, I think it makes more sense to use something
    > that is already written (namely the Scripting library), unless you have some
    > requirement for making faster routines. Just my 2 cents.
    >
    > --
    > Michael Shutt
    >
    > Please respond to newsgroup as I will not return direct emails.
    >
    > "Karl E. Peterson" <karl@mvps.org> wrote in message
    > news:3b682746$1@news.devx.com...
    > > Hi Michael --
    > >
    > > > Slowest in terms of CPU cycles, yes. However, probably the fastest in

    > terms
    > > > of development time. Also more reliable than reinventing the wheel
    > > > yourself. There's always a trade off.

    > >
    > > Hmmm, could be, for some. Me, I just drop in a routine I wrote (updated,

    > actually)
    > > in 1994 for "VB4HT". Takes a coupla seconds, tops. :-)
    > >
    > > Later... Karl
    > > --
    > > http://www.mvps.org/vb
    > >
    > >

    >
    >



  7. #52
    Michael Shutt Guest

    Re: Determining a file extension

    I hear what you're saying, but your argument breaks down for me for just the
    opposite reason. If I were to write the routines myself, I would put them
    into a shared dll rather than cut and paste them to the projects that need
    them. Therefore, I would still end up with an external dependency.

    Different strokes, eh?

    --
    Michael Shutt

    Please respond to newsgroup as I will not return direct emails.

    "Karl E. Peterson" <karl@mvps.org> wrote in message
    news:3b6974a0$1@news.devx.com...
    > Hi Michael --
    >
    > I hear what you're saying, and I agree there are elements of sanity to it.

    Where it
    > all breaks down for me, in this case, is the *external* dependency. If I

    have a
    > simple and effective solution in native code, why would I want to risk the
    > embarrassment of a missing or incompatible dependency? Just doesn't

    pencil out for
    > me.
    >
    > Thanks... Karl
    > --
    > http://www.mvps.org/vb
    >

    <snip>



  8. #53
    Michael Shutt Guest

    Re: Determining a file extension

    I hear what you're saying, but your argument breaks down for me for just the
    opposite reason. If I were to write the routines myself, I would put them
    into a shared dll rather than cut and paste them to the projects that need
    them. Therefore, I would still end up with an external dependency.

    Different strokes, eh?

    --
    Michael Shutt

    Please respond to newsgroup as I will not return direct emails.

    "Karl E. Peterson" <karl@mvps.org> wrote in message
    news:3b6974a0$1@news.devx.com...
    > Hi Michael --
    >
    > I hear what you're saying, and I agree there are elements of sanity to it.

    Where it
    > all breaks down for me, in this case, is the *external* dependency. If I

    have a
    > simple and effective solution in native code, why would I want to risk the
    > embarrassment of a missing or incompatible dependency? Just doesn't

    pencil out for
    > me.
    >
    > Thanks... Karl
    > --
    > http://www.mvps.org/vb
    >

    <snip>



  9. #54
    Karl E. Peterson Guest

    Re: Determining a file extension

    Heheheheh... Well, at least with your approach, *you* are in charge of the behavior.
    That's what counts, in the end. :-)
    --
    http://www.mvps.org/vb


    "Michael Shutt" <mshutt_nospam@mediaone.net> wrote in message
    news:3b69a213$1@news.devx.com...
    > I hear what you're saying, but your argument breaks down for me for just the
    > opposite reason. If I were to write the routines myself, I would put them
    > into a shared dll rather than cut and paste them to the projects that need
    > them. Therefore, I would still end up with an external dependency.
    >
    > Different strokes, eh?
    >
    > --
    > Michael Shutt
    >
    > Please respond to newsgroup as I will not return direct emails.
    >
    > "Karl E. Peterson" <karl@mvps.org> wrote in message
    > news:3b6974a0$1@news.devx.com...
    > > Hi Michael --
    > >
    > > I hear what you're saying, and I agree there are elements of sanity to it.

    > Where it
    > > all breaks down for me, in this case, is the *external* dependency. If I

    > have a
    > > simple and effective solution in native code, why would I want to risk the
    > > embarrassment of a missing or incompatible dependency? Just doesn't

    > pencil out for
    > > me.
    > >
    > > Thanks... Karl
    > > --
    > > http://www.mvps.org/vb
    > >

    > <snip>
    >
    >



  10. #55
    Karl E. Peterson Guest

    Re: Determining a file extension

    Heheheheh... Well, at least with your approach, *you* are in charge of the behavior.
    That's what counts, in the end. :-)
    --
    http://www.mvps.org/vb


    "Michael Shutt" <mshutt_nospam@mediaone.net> wrote in message
    news:3b69a213$1@news.devx.com...
    > I hear what you're saying, but your argument breaks down for me for just the
    > opposite reason. If I were to write the routines myself, I would put them
    > into a shared dll rather than cut and paste them to the projects that need
    > them. Therefore, I would still end up with an external dependency.
    >
    > Different strokes, eh?
    >
    > --
    > Michael Shutt
    >
    > Please respond to newsgroup as I will not return direct emails.
    >
    > "Karl E. Peterson" <karl@mvps.org> wrote in message
    > news:3b6974a0$1@news.devx.com...
    > > Hi Michael --
    > >
    > > I hear what you're saying, and I agree there are elements of sanity to it.

    > Where it
    > > all breaks down for me, in this case, is the *external* dependency. If I

    > have a
    > > simple and effective solution in native code, why would I want to risk the
    > > embarrassment of a missing or incompatible dependency? Just doesn't

    > pencil out for
    > > me.
    > >
    > > Thanks... Karl
    > > --
    > > http://www.mvps.org/vb
    > >

    > <snip>
    >
    >



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