VB6 to VB.NET, comments please

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Galen Somerville

    #1

    VB6 to VB.NET, comments please

    My application receives and displays Heart sounds and ECG's in real time.
    This data comes from a proprietary USB 2.0 device. Unlike most USB devices,
    this data comes in short bursts of about 24 bytes. These bursts could come
    as fast as every millisecond.

    The display of the sound and ECG traces is similar to an oscilloscope
    display except a blank space of about 5 pixels is shown as it sweeps across
    the screen. This means that not only is six horizontal lines drawn for each
    trace, for each data burst, but the next six existing horizontal lines have
    to be blanked.

    The above equates to around 300 Heart Beats per Minute (BPM). This is easily
    handled by my VB6 application.

    Using VB2005 Pro I have attempted to convert this VB6 app. As of now I use
    shared memory, an in process thread to capture data from the USB and an
    ActiveX thread to interface with the USB. I have attempted to do the drawing
    with GDI, DirectX, etc.

    The best I can get is a 15 BPM heart rate.

    I am contemplating doing the drawing in my ActiveX thread. The idea being
    that all of the data capture and drawing is, in effect, being done via VB6.
    But if I do this then the VB2005 portion becomes one of just showing forms
    with Command buttons and Text boxes etc. But my VB6 app already does this.

    So my question is, what's the benefit of converting this app to VB.NET?

    Apparently I can use the Interop Toolkit on my VB6 app instead of converting
    to VB2005. What's the benefit in doing that?

    As an aside, 99% of the customers have us buy a computer and install the
    software at the factory. Then the computer is shipped to them. So no
    installation problems.

    I would appreciate any comments pro or con.

    Thanks

    Galen



  • Mr. Arnold

    #2
    Re: VB6 to VB.NET, comments please

    >
    I am contemplating doing the drawing in my ActiveX thread. The idea being
    that all of the data capture and drawing is, in effect, being done via
    VB6. But if I do this then the VB2005 portion becomes one of just showing
    forms with Command buttons and Text boxes etc. But my VB6 app already does
    this.
    >
    So my question is, what's the benefit of converting this app to VB.NET?
    There is nothing saying that you have to convert the VB6 legacy application
    to VB.Net. If it works better as being a VB6 application, then keep it as
    such, until you are forced to convert it. There will still be plenty of VB6
    solutions still running out there for various reasons for a long time to
    come that will have no need to be converted to .Net.

    The old saying goes like this. If it's not broke, then you don't fix it.

    However, if you need to deploy this solution to a Vista machine, then you
    might need to go to VB.Net with its ability to produce a .Net manifest for
    Vista's UAC.


    Comment

    • Henning Krause [MVP - Exchange]

      #3
      Re: VB6 to VB.NET, comments please

      Hello,

      have you tried to track down the performance bottleneck in the VB.NET
      application?

      If you cut away the visualization part, do you get a decent performance? The
      performance degration might come from the way you perform the visualization.
      Or it may be on the side of data acquisition.

      Best regards,
      Henning Krause


      "Galen Somerville" <galen@communit y.nospamwrote in message
      news:%23GCNSUpt HHA.736@TK2MSFT NGP06.phx.gbl.. .
      My application receives and displays Heart sounds and ECG's in real time.
      This data comes from a proprietary USB 2.0 device. Unlike most USB
      devices, this data comes in short bursts of about 24 bytes. These bursts
      could come as fast as every millisecond.
      >
      The display of the sound and ECG traces is similar to an oscilloscope
      display except a blank space of about 5 pixels is shown as it sweeps
      across the screen. This means that not only is six horizontal lines drawn
      for each trace, for each data burst, but the next six existing horizontal
      lines have to be blanked.
      >
      The above equates to around 300 Heart Beats per Minute (BPM). This is
      easily handled by my VB6 application.
      >
      Using VB2005 Pro I have attempted to convert this VB6 app. As of now I use
      shared memory, an in process thread to capture data from the USB and an
      ActiveX thread to interface with the USB. I have attempted to do the
      drawing with GDI, DirectX, etc.
      >
      The best I can get is a 15 BPM heart rate.
      >
      I am contemplating doing the drawing in my ActiveX thread. The idea being
      that all of the data capture and drawing is, in effect, being done via
      VB6. But if I do this then the VB2005 portion becomes one of just showing
      forms with Command buttons and Text boxes etc. But my VB6 app already does
      this.
      >
      So my question is, what's the benefit of converting this app to VB.NET?
      >
      Apparently I can use the Interop Toolkit on my VB6 app instead of
      converting to VB2005. What's the benefit in doing that?
      >
      As an aside, 99% of the customers have us buy a computer and install the
      software at the factory. Then the computer is shipped to them. So no
      installation problems.
      >
      I would appreciate any comments pro or con.
      >
      Thanks
      >
      Galen
      >
      >
      >

      Comment

      • Galen Somerville

        #4
        Re: VB6 to VB.NET, comments please


        "Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
        news:uLJ6oOqtHH A.3544@TK2MSFTN GP03.phx.gbl...

        >I am contemplating doing the drawing in my ActiveX thread. The idea being
        >that all of the data capture and drawing is, in effect, being done via
        >VB6. But if I do this then the VB2005 portion becomes one of just showing
        >forms with Command buttons and Text boxes etc. But my VB6 app already
        >does this.
        >
        >>
        >So my question is, what's the benefit of converting this app to VB.NET?
        >
        There is nothing saying that you have to convert the VB6 legacy
        application to VB.Net. If it works better as being a VB6 application,
        then keep it as such, until you are forced to convert it. There will still
        be plenty of VB6 solutions still running out there for various reasons for
        a long time to come that will have no need to be converted to .Net.
        >
        The old saying goes like this. If it's not broke, then you don't fix it.
        >
        However, if you need to deploy this solution to a Vista machine, then you
        might need to go to VB.Net with its ability to produce a .Net manifest for
        Vista's UAC.
        >
        >
        I split the data files, written to, into a separate folder. Added a manifest
        file and the VB6 app runs fine on Vista

        Galen


        Comment

        • Number 11950 - GPEMC! Replace number with 11950

          #5
          Re: VB6 to VB.NET, comments please

          "Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
          news:uLJ6oOqtHH A.3544@TK2MSFTN GP03.phx.gbl...

          I am contemplating doing the drawing in my ActiveX thread. The idea
          being
          that all of the data capture and drawing is, in effect, being done via
          VB6. But if I do this then the VB2005 portion becomes one of just
          showing
          forms with Command buttons and Text boxes etc. But my VB6 app already
          does
          this.
          >

          So my question is, what's the benefit of converting this app to VB.NET?
          >
          There is nothing saying that you have to convert the VB6 legacy
          application
          to VB.Net. If it works better as being a VB6 application, then keep it as
          such, until you are forced to convert it. There will still be plenty of
          VB6
          solutions still running out there for various reasons for a long time to
          come that will have no need to be converted to .Net.
          >
          The old saying goes like this. If it's not broke, then you don't fix it.
          >
          However, if you need to deploy this solution to a Vista machine, then you
          might need to go to VB.Net with its ability to produce a .Net manifest for
          Vista's UAC.
          So if I want to "weld the hood shut" as the open-sourcers so aptly put it,
          then would compiling a control in VB6 that I add and compile through VB2005
          be a more effective way of protecting my secrets than using an obfuscator to
          reduce programatic rendering of code to mathematical rendering of code?

          Would a VB6 ActiveX wrapped up in a VB2005 package retain forward
          compatibility for as long as VB2005 does?

          TIA

          --
          Timothy Casey GPEMC! >11950 is the number@fieldcra ft.com.au 2email
          Terms & conditions apply. See www.fieldcraft.biz/GPEMC
          Discover valid interoperable web menus, IE security, TSR Control,
          & the most advanced speed reading application @ www.fieldcraft.biz


          Comment

          • Galen Somerville

            #6
            Re: VB6 to VB.NET, comments please

            I used QueryPerformanc eCounter entries many times as I worked through the
            problems.

            The visualization is by far the poorest performer. But even the data
            acquisition side was not that great. The shared memory saved the day but
            still too much marshaling.

            Galen

            "Henning Krause [MVP - Exchange]" <newsgroups_rem ove@this.infini tec.de>
            wrote in message news:eYrZtWqtHH A.488@TK2MSFTNG P04.phx.gbl...
            Hello,
            >
            have you tried to track down the performance bottleneck in the VB.NET
            application?
            >
            If you cut away the visualization part, do you get a decent performance?
            The performance degration might come from the way you perform the
            visualization. Or it may be on the side of data acquisition.
            >
            Best regards,
            Henning Krause
            >
            >
            "Galen Somerville" <galen@communit y.nospamwrote in message
            news:%23GCNSUpt HHA.736@TK2MSFT NGP06.phx.gbl.. .
            >My application receives and displays Heart sounds and ECG's in real time.
            >This data comes from a proprietary USB 2.0 device. Unlike most USB
            >devices, this data comes in short bursts of about 24 bytes. These bursts
            >could come as fast as every millisecond.
            >>
            >The display of the sound and ECG traces is similar to an oscilloscope
            >display except a blank space of about 5 pixels is shown as it sweeps
            >across the screen. This means that not only is six horizontal lines drawn
            >for each trace, for each data burst, but the next six existing horizontal
            >lines have to be blanked.
            >>
            >The above equates to around 300 Heart Beats per Minute (BPM). This is
            >easily handled by my VB6 application.
            >>
            >Using VB2005 Pro I have attempted to convert this VB6 app. As of now I
            >use shared memory, an in process thread to capture data from the USB and
            >an ActiveX thread to interface with the USB. I have attempted to do the
            >drawing with GDI, DirectX, etc.
            >>
            >The best I can get is a 15 BPM heart rate.
            >>
            >I am contemplating doing the drawing in my ActiveX thread. The idea being
            >that all of the data capture and drawing is, in effect, being done via
            >VB6. But if I do this then the VB2005 portion becomes one of just showing
            >forms with Command buttons and Text boxes etc. But my VB6 app already
            >does this.
            >>
            >So my question is, what's the benefit of converting this app to VB.NET?
            >>
            >Apparently I can use the Interop Toolkit on my VB6 app instead of
            >converting to VB2005. What's the benefit in doing that?
            >>
            >As an aside, 99% of the customers have us buy a computer and install the
            >software at the factory. Then the computer is shipped to them. So no
            >installation problems.
            >>
            >I would appreciate any comments pro or con.
            >>
            >Thanks
            >>
            >Galen
            >>
            >>
            >>
            >

            Comment

            • Galen Somerville

              #7
              Re: VB6 to VB.NET, comments please


              "Number 11950 - GPEMC! Replace number with 11950" <number@fieldcr aft.biz>
              wrote in message
              news:467f1674$0 $67427$c30e37c6 @lon-reader.news.tel stra.net...
              "Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
              news:uLJ6oOqtHH A.3544@TK2MSFTN GP03.phx.gbl...
              >
              I am contemplating doing the drawing in my ActiveX thread. The idea
              being
              that all of the data capture and drawing is, in effect, being done via
              VB6. But if I do this then the VB2005 portion becomes one of just
              showing
              forms with Command buttons and Text boxes etc. But my VB6 app already
              does
              this.
              >>
              >
              So my question is, what's the benefit of converting this app to VB.NET?
              >>
              >There is nothing saying that you have to convert the VB6 legacy
              application
              >to VB.Net. If it works better as being a VB6 application, then keep it
              >as
              >such, until you are forced to convert it. There will still be plenty of
              VB6
              >solutions still running out there for various reasons for a long time to
              >come that will have no need to be converted to .Net.
              >>
              >The old saying goes like this. If it's not broke, then you don't fix it.
              >>
              >However, if you need to deploy this solution to a Vista machine, then you
              >might need to go to VB.Net with its ability to produce a .Net manifest
              >for
              >Vista's UAC.
              >
              So if I want to "weld the hood shut" as the open-sourcers so aptly put it,
              then would compiling a control in VB6 that I add and compile through
              VB2005
              be a more effective way of protecting my secrets than using an obfuscator
              to
              reduce programatic rendering of code to mathematical rendering of code?
              >
              Would a VB6 ActiveX wrapped up in a VB2005 package retain forward
              compatibility for as long as VB2005 does?
              >
              TIA
              >
              --
              Timothy Casey GPEMC! >11950 is the number@fieldcra ft.com.au 2email
              Terms & conditions apply. See www.fieldcraft.biz/GPEMC
              Discover valid interoperable web menus, IE security, TSR Control,
              & the most advanced speed reading application @ www.fieldcraft.biz
              >
              >
              My initial reason for trying this VB6 to VB2005 conversion was "to do the
              right thing". But the aheader I go, the behinder I get.

              Galen


              Comment

              • Mr. Arnold

                #8
                Re: VB6 to VB.NET, comments please


                "Number 11950 - GPEMC! Replace number with 11950" <number@fieldcr aft.biz>
                wrote in message
                news:467f1674$0 $67427$c30e37c6 @lon-reader.news.tel stra.net...
                "Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
                news:uLJ6oOqtHH A.3544@TK2MSFTN GP03.phx.gbl...
                >
                I am contemplating doing the drawing in my ActiveX thread. The idea
                being
                that all of the data capture and drawing is, in effect, being done via
                VB6. But if I do this then the VB2005 portion becomes one of just
                showing
                forms with Command buttons and Text boxes etc. But my VB6 app already
                does
                this.
                >>
                >
                So my question is, what's the benefit of converting this app to VB.NET?
                >>
                >There is nothing saying that you have to convert the VB6 legacy
                application
                >to VB.Net. If it works better as being a VB6 application, then keep it
                >as
                >such, until you are forced to convert it. There will still be plenty of
                VB6
                >solutions still running out there for various reasons for a long time to
                >come that will have no need to be converted to .Net.
                >>
                >The old saying goes like this. If it's not broke, then you don't fix it.
                >>
                >However, if you need to deploy this solution to a Vista machine, then you
                >might need to go to VB.Net with its ability to produce a .Net manifest
                >for
                >Vista's UAC.
                >
                So if I want to "weld the hood shut" as the open-sourcers so aptly put it,
                then would compiling a control in VB6 that I add and compile through
                VB2005
                be a more effective way of protecting my secrets than using an obfuscator
                to
                reduce programatic rendering of code to mathematical rendering of code?
                >
                Would a VB6 ActiveX wrapped up in a VB2005 package retain forward
                compatibility for as long as VB2005 does?
                Many COM components will still be running on the Windows O/S for various
                reasons. MS with a .NET solution has to give the ability to incorporate COM
                solutions in into a .NET application.


                Comment

                • Mr. Arnold

                  #9
                  Re: VB6 to VB.NET, comments please


                  "Galen Somerville" <galen@communit y.nospamwrote in message
                  news:e7G2sRstHH A.4972@TK2MSFTN GP05.phx.gbl...
                  >
                  "Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
                  news:uLJ6oOqtHH A.3544@TK2MSFTN GP03.phx.gbl...
                  >
                  >>I am contemplating doing the drawing in my ActiveX thread. The idea
                  >>being that all of the data capture and drawing is, in effect, being done
                  >>via VB6. But if I do this then the VB2005 portion becomes one of just
                  >>showing forms with Command buttons and Text boxes etc. But my VB6 app
                  >>already does this.
                  >>
                  >>>
                  >>So my question is, what's the benefit of converting this app to VB.NET?
                  >>
                  >There is nothing saying that you have to convert the VB6 legacy
                  >application to VB.Net. If it works better as being a VB6 application,
                  >then keep it as such, until you are forced to convert it. There will
                  >still be plenty of VB6 solutions still running out there for various
                  >reasons for a long time to come that will have no need to be converted to
                  >.Net.
                  >>
                  >The old saying goes like this. If it's not broke, then you don't fix it.
                  >>
                  >However, if you need to deploy this solution to a Vista machine, then you
                  >might need to go to VB.Net with its ability to produce a .Net manifest
                  >for Vista's UAC.
                  >>
                  >>
                  I split the data files, written to, into a separate folder. Added a
                  manifest file and the VB6 app runs fine on Vista
                  That VB6 program running on Vista and that VB6 program running on Vista
                  using escalated privileges when needed are two different things.

                  Can you show some kind of proof here that in fact what you have done is
                  going to allow a VB6 program to run and is not going to be stopped when it
                  needs escalated privileges for said VB6 program, because you have a
                  manifest file setting there?

                  Is the manifest file really being used in this case with the VB6 solution to
                  present credentials to Vista?

                  The only way of know about to date for a non .Net solution to escalate its
                  privileges during execution for a program is set the Run as Administrator on
                  the properties of the exe or the short-cut pointing to the exe.




                  Comment

                  • Galen Somerville

                    #10
                    Re: VB6 to VB.NET, comments please


                    "Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
                    news:eZPGXEutHH A.3640@TK2MSFTN GP05.phx.gbl...
                    >
                    "Galen Somerville" <galen@communit y.nospamwrote in message
                    news:e7G2sRstHH A.4972@TK2MSFTN GP05.phx.gbl...
                    >>
                    >"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
                    >news:uLJ6oOqtH HA.3544@TK2MSFT NGP03.phx.gbl.. .
                    >>
                    >>>I am contemplating doing the drawing in my ActiveX thread. The idea
                    >>>being that all of the data capture and drawing is, in effect, being
                    >>>done via VB6. But if I do this then the VB2005 portion becomes one of
                    >>>just showing forms with Command buttons and Text boxes etc. But my VB6
                    >>>app already does this.
                    >>>
                    >>>>
                    >>>So my question is, what's the benefit of converting this app to VB.NET?
                    >>>
                    >>There is nothing saying that you have to convert the VB6 legacy
                    >>application to VB.Net. If it works better as being a VB6 application,
                    >>then keep it as such, until you are forced to convert it. There will
                    >>still be plenty of VB6 solutions still running out there for various
                    >>reasons for a long time to come that will have no need to be converted
                    >>to .Net.
                    >>>
                    >>The old saying goes like this. If it's not broke, then you don't fix it.
                    >>>
                    >>However, if you need to deploy this solution to a Vista machine, then
                    >>you might need to go to VB.Net with its ability to produce a .Net
                    >>manifest for Vista's UAC.
                    >>>
                    >>>
                    >I split the data files, written to, into a separate folder. Added a
                    >manifest file and the VB6 app runs fine on Vista
                    >
                    That VB6 program running on Vista and that VB6 program running on Vista
                    using escalated privileges when needed are two different things.
                    >
                    Can you show some kind of proof here that in fact what you have done is
                    going to allow a VB6 program to run and is not going to be stopped when it
                    needs escalated privileges for said VB6 program, because you have a
                    manifest file setting there?
                    >
                    Is the manifest file really being used in this case with the VB6 solution
                    to present credentials to Vista?
                    >
                    The only way of know about to date for a non .Net solution to escalate its
                    privileges during execution for a program is set the Run as Administrator
                    on the properties of the exe or the short-cut pointing to the exe.
                    >
                    This is the Cardio74.exe.ma nifest I am using.

                    <?xml version="1.0" encoding="UTF-8" standalone="yes "?>
                    <assembly xmlns="urn:sche mas-microsoft-com:asm.v1" manifestVersion ="1.0">
                    <assemblyIdenti ty version="7.0.4. 0"
                    processorArchit ecture="X86"
                    name="Cardio74"
                    type="win32"/>
                    <description>el evate execution level</description>
                    <trustInfo xmlns="urn:sche mas-microsoft-com:asm.v2">
                    <security>
                    <requestedPrivi leges>
                    <requestedExecu tionLevel level="requireA dministrator"
                    uiAccess="false "/>
                    </requestedPrivil eges>
                    </security>
                    </trustInfo>
                    </assembly>

                    Galen


                    Comment

                    • Mr. Arnold

                      #11
                      Re: VB6 to VB.NET, comments please


                      "Galen Somerville" <galen@communit y.nospamwrote in message
                      news:u3VW3MztHH A.3476@TK2MSFTN GP02.phx.gbl...
                      >
                      "Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
                      news:eZPGXEutHH A.3640@TK2MSFTN GP05.phx.gbl...
                      >>
                      >"Galen Somerville" <galen@communit y.nospamwrote in message
                      >news:e7G2sRstH HA.4972@TK2MSFT NGP05.phx.gbl.. .
                      >>>
                      >>"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
                      >>news:uLJ6oOqt HHA.3544@TK2MSF TNGP03.phx.gbl. ..
                      >>>
                      >>>>I am contemplating doing the drawing in my ActiveX thread. The idea
                      >>>>being that all of the data capture and drawing is, in effect, being
                      >>>>done via VB6. But if I do this then the VB2005 portion becomes one of
                      >>>>just showing forms with Command buttons and Text boxes etc. But my VB6
                      >>>>app already does this.
                      >>>>
                      >>>>>
                      >>>>So my question is, what's the benefit of converting this app to
                      >>>>VB.NET?
                      >>>>
                      >>>There is nothing saying that you have to convert the VB6 legacy
                      >>>applicatio n to VB.Net. If it works better as being a VB6 application,
                      >>>then keep it as such, until you are forced to convert it. There will
                      >>>still be plenty of VB6 solutions still running out there for various
                      >>>reasons for a long time to come that will have no need to be converted
                      >>>to .Net.
                      >>>>
                      >>>The old saying goes like this. If it's not broke, then you don't fix
                      >>>it.
                      >>>>
                      >>>However, if you need to deploy this solution to a Vista machine, then
                      >>>you might need to go to VB.Net with its ability to produce a .Net
                      >>>manifest for Vista's UAC.
                      >>>>
                      >>>>
                      >>I split the data files, written to, into a separate folder. Added a
                      >>manifest file and the VB6 app runs fine on Vista
                      >>
                      >That VB6 program running on Vista and that VB6 program running on Vista
                      >using escalated privileges when needed are two different things.
                      >>
                      >Can you show some kind of proof here that in fact what you have done is
                      >going to allow a VB6 program to run and is not going to be stopped when
                      >it needs escalated privileges for said VB6 program, because you have a
                      >manifest file setting there?
                      >>
                      >Is the manifest file really being used in this case with the VB6 solution
                      >to present credentials to Vista?
                      >>
                      >The only way of know about to date for a non .Net solution to escalate
                      >its privileges during execution for a program is set the Run as
                      >Administrato r on the properties of the exe or the short-cut pointing to
                      >the exe.
                      >>
                      This is the Cardio74.exe.ma nifest I am using.
                      >
                      I cannot see the .dof files in this link, because I don't have MS Word on
                      this Vista computer.

                      Can you tell me if you're in compliacne with the information on how to
                      implement a program/application that's using or needs to interface with
                      Vista's UAC?

                      http://preview.tinyurl.com/27harb

                      You may find this link of interests to you.





                      Comment

                      • Galen Somerville

                        #12
                        Re: VB6 to VB.NET, comments please


                        "Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
                        news:uoAWli0tHH A.2752@TK2MSFTN GP06.phx.gbl...
                        >
                        "Galen Somerville" <galen@communit y.nospamwrote in message
                        news:u3VW3MztHH A.3476@TK2MSFTN GP02.phx.gbl...
                        >>
                        >"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
                        >news:eZPGXEutH HA.3640@TK2MSFT NGP05.phx.gbl.. .
                        >>>
                        >>"Galen Somerville" <galen@communit y.nospamwrote in message
                        >>news:e7G2sRst HHA.4972@TK2MSF TNGP05.phx.gbl. ..
                        >>>>
                        >>>"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
                        >>>news:uLJ6oOq tHHA.3544@TK2MS FTNGP03.phx.gbl ...
                        >>>>
                        >>>>>I am contemplating doing the drawing in my ActiveX thread. The idea
                        >>>>>being that all of the data capture and drawing is, in effect, being
                        >>>>>done via VB6. But if I do this then the VB2005 portion becomes one of
                        >>>>>just showing forms with Command buttons and Text boxes etc. But my
                        >>>>>VB6 app already does this.
                        >>>>>
                        >>>>>>
                        >>>>>So my question is, what's the benefit of converting this app to
                        >>>>>VB.NET?
                        >>>>>
                        >>>>There is nothing saying that you have to convert the VB6 legacy
                        >>>>applicati on to VB.Net. If it works better as being a VB6 application,
                        >>>>then keep it as such, until you are forced to convert it. There will
                        >>>>still be plenty of VB6 solutions still running out there for various
                        >>>>reasons for a long time to come that will have no need to be converted
                        >>>>to .Net.
                        >>>>>
                        >>>>The old saying goes like this. If it's not broke, then you don't fix
                        >>>>it.
                        >>>>>
                        >>>>However, if you need to deploy this solution to a Vista machine, then
                        >>>>you might need to go to VB.Net with its ability to produce a .Net
                        >>>>manifest for Vista's UAC.
                        >>>>>
                        >>>>>
                        >>>I split the data files, written to, into a separate folder. Added a
                        >>>manifest file and the VB6 app runs fine on Vista
                        >>>
                        >>That VB6 program running on Vista and that VB6 program running on Vista
                        >>using escalated privileges when needed are two different things.
                        >>>
                        >>Can you show some kind of proof here that in fact what you have done is
                        >>going to allow a VB6 program to run and is not going to be stopped when
                        >>it needs escalated privileges for said VB6 program, because you have a
                        >>manifest file setting there?
                        >>>
                        >>Is the manifest file really being used in this case with the VB6
                        >>solution to present credentials to Vista?
                        >>>
                        >>The only way of know about to date for a non .Net solution to escalate
                        >>its privileges during execution for a program is set the Run as
                        >>Administrat or on the properties of the exe or the short-cut pointing to
                        >>the exe.
                        >>>
                        >This is the Cardio74.exe.ma nifest I am using.
                        >>
                        >
                        I cannot see the .dof files in this link, because I don't have MS Word on
                        this Vista computer.
                        >
                        I didn't include any .doc files

                        Can you tell me if you're in compliacne with the information on how to
                        implement a program/application that's using or needs to interface with
                        Vista's UAC?
                        >
                        http://preview.tinyurl.com/27harb
                        >
                        Way too much to read. My program runs on a standard user, no admin, so I'm
                        happy.

                        That was one of my questions. Why should I use the Interop Toolkit. VB6 runs
                        fine.

                        Galen


                        Comment

                        • Mr. Arnold

                          #13
                          Re: VB6 to VB.NET, comments please

                          >>
                          >
                          Way too much to read. My program runs on a standard user, no admin, so I'm
                          happy.
                          Obviously, the program can run on Vista as is. Any type of program should be
                          able to run with Vista's compatibility mode settings, if need be, along with
                          the ability to set the exe's or short-cut's property to Run as
                          Administrator.

                          And because it runs under Standard User and doesn't need escalated
                          privileges, then Vista's UAC is not going to check its credentials and
                          challenge it. I don't think the manifest will every come into play in this
                          situation and is not needed, and things in the program may not be in the
                          program to use the manifest.


                          Comment

                          • Walter Wang [MSFT]

                            #14
                            RE: VB6 to VB.NET, comments please

                            Hi Galen,

                            Glad to see you again here. I'm the one who suggested you to use shared
                            memory to pass data from VB6 to VB2005. The reason I suggested this
                            workaround is that COM interop between unmanaged and managed code is slow,
                            this is the price we have to pay for combining two different world. For the
                            data visualization part, yes WinForm does have some performance issue here.

                            Depending on your requirement, using Interop Toolkit might help but it will
                            certainly not help much on the real-time data processing part.

                            VB6 runtime will still be supported on Vista.

                            Regards,
                            Walter Wang (wawang@online. microsoft.com, remove 'online.')
                            Microsoft Online Community Support

                            =============== =============== =============== =====
                            When responding to posts, please "Reply to Group" via your newsreader so
                            that others may learn and benefit from your issue.
                            =============== =============== =============== =====

                            This posting is provided "AS IS" with no warranties, and confers no rights.


                            Comment

                            • Dick Grier

                              #15
                              Re: VB6 to VB.NET, comments please

                              Hi,
                              >>
                              It's interesting to note that I develope on a Pent D 940 dual-core at
                              3.2GHz. But our program runs at high BMP rates on older Win98 machines with
                              way less power and speed.
                              <<

                              You have to really work hard with threading to make the dual-cores perform
                              (the one that I have is only a 2 GHz notebook, and it is about 30-35% slower
                              than the Hyperthreaded 3.2 GHz notebook it is replacing -- Vista looks nice,
                              but looks aren't everything). The OS (and .NET) have added so much that
                              gets in the way of raw performance that we have to use as much skill as we
                              can muster to avoid the bottlenecks. And, COM (and STAThread) marshaling is
                              a big bottleneck.

                              Perhaps you can investigate a native dll (or even .NET) interface to your
                              USB hardware. Getting away from the ActiveX interface might provide a
                              substantial speed improvement.

                              Dick

                              --
                              Richard Grier, MVP
                              Hard & Software
                              Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
                              Edition,
                              ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
                              2006.
                              See www.hardandsoftware.net for details and contact information.


                              Comment

                              Working...