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?

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
>
>
>

>>
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.
>
>

>>
There is nothing saying that you have to convert the VB6 legacy

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

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.

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@community.nospamwrote in message
news:%23GCNSUptHHA.736@TK2MSFTNGP06.phx.gbl...>

"Mr. Arnold" <MR. Arnold@Arnold.comwrote in message
news:uLJ6oOqtHHA.3544@TK2MSFTNGP03.phx.gbl...beingshowingdoesapplicationVB6>
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@fieldcraft.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
>
>

"Mr. Arnold" <MR. Arnold@Arnold.comwrote in message
news:uLJ6oOqtHHA.3544@TK2MSFTNGP03.phx.gbl...beingshowingdoesapplicationVB6>
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?

>
"Mr. Arnold" <MR. Arnold@Arnold.comwrote in message
news:uLJ6oOqtHHA.3544@TK2MSFTNGP03.phx.gbl...I split the data files, written to, into a separate folder. Added a
manifest file and the VB6 app runs fine on Vista

>
"Galen Somerville" <galen@community.nospamwrote in message
news:e7G2sRstHHA.4972@TK2MSFTNGP05.phx.gbl...>
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.
>

>
"Mr. Arnold" <MR. Arnold@Arnold.comwrote in message
news:eZPGXEutHHA.3640@TK2MSFTNGP05.phx.gbl...This is the Cardio74.exe.manifest I am using.
>

>
"Galen Somerville" <galen@community.nospamwrote in message
news:u3VW3MztHHA.3476@TK2MSFTNGP02.phx.gbl...>
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.
>
http://www.codeproject.com/useritems...asp?print=true
>
>

>
Way too much to read. My program runs on a standard user, no admin, so I'm
happy.

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.
>

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

"Galen Somerville" <galen@community.nospamwrote in message
news:%23GCNSUptHHA.736@TK2MSFTNGP06.phx.gbl...>
While keeping the application in VB6 will give better performance over
interop/COM performance, MS has stated that it will no longer support VB6
after Vista. And, seeing as how MS says the next OS is slated for release
in 2009 (only a year and a half from now) it may be wise to go ahead and
bite the bullet and move away from VB6.
>
If .Net is too slow (and it most probably is for real time, high speed
serial device input) you may want to go with a C++ application. It's not
as easy to code, but C++ will be around for a very long time to come.
>
jim
>

>
"jim" <jim@yourpc.eduwrote in message
news:GNfgi.7092$c_4.6058@bignews2.bellsouth.net...As I remember, they weren't going to support VB6 in Vista either. The
original apps were in assembly language with two ISA cards doing the real
time work. Then Graphics cards got better and cpu's got faster. That's
when I jumped on VB6 as it was easy to get up to speed.
>
Then ISA became passe and USB appeared, so I jumped on that.
>
I've toyed with going to C++ but it puts me back in the position of
figuring everything in detail. Hell, that's what I was doing originally in
MASM. Age comes into play also. My first program was an Infant Hearing
Screener written on an Intel ISIS system using 8085's.
>
Galen

>
"Galen Somerville" <galen@community.nospamwrote in message
news:eFEPzPFuHHA.2028@TK2MSFTNGP04.phx.gbl...>
I feel your pain. I am 39. I taught my first programming class when I
was 15 (Apple IIe and IIgs). I stopped coding 4 years ago and opened my
own business doing network administration for small to mid-sized
bsinesses. It gets boring, but it beats the hell out of coding for big
companies like Citibank, Porsche, Coca-Cola, etc. (The constant push to
put apps out before they are ready...and all that crap.)
>
I have been planning on doing some .Net stuff, learning C & C++...but I am
(and I think everyone gets) not so impressed with technology any more. I
look for simple, cost effective solutions. I look for things that will
let me do my job as fast as possible and go live a little.
>
In fact, it looks to me like the general population is tiring of the whole
technology boom. Just look at the Wii kicking the butts of Playstation
and XBox.
>
I've screamed about it until blood has shot out of my mouth.....people
just want simple. Simple has always outsold complex, and it always will.
>
Simple is more cost-effective and makes greater profit margins. Simple
means fewer tech support calls. Simple means money.
>
But, I'll be damned if anyone is listening.
>
Microsoft killed the most popular programming language EVER (in terms of
coders and application base) in favor of what? .Net?
>
.Net was never written for programmers. It was written by Microsoft, for
Microsoft's vision of software as a service. They lied to people to try
and sell it (there NEVER was a "Dll Hell" and I can prove it). They push
.Net on programmers because they can.
>
(One more point and I promise....I'm off my soapbox.) And, Microsoft can
push programmers (and end users) around for one simple
reason...proprietary data formats.
>
Proprietary data formats make it damned near impossible (practically or
financially) for businesses to leave Microsoft or Quickbooks or AutoCAD
or thousands of other applications and move to a different app (much less
a different OS).
>
Things will never change until we enact legislation that enforces open
data formats. All companies that store user data should be forced by law
to publish the data formats that the data is stored in BEFORE they can
sell (or update) their software that users will use to store data. After
all, it is your data (regardless of what software package you use to
compile or store it) and it should always be your data and be portable to
where ever you want to take it.
>
If we enacted open data format legislation, you would see a whole new,
affordable, usable downpour of applications and OS' begin to be used in
business and home use.
>
Software would have to compete based on usability, features and cost
effectiveness....not because the users can't easily or cost effectively
port their data to an app more suited to their needs.
>
(OK....ok.....I'm stepping down now......)
>
>
>

>
"Galen Somerville" <galen@community.nospamwrote in message
news:eFEPzPFuHHA.2028@TK2MSFTNGP04.phx.gbl...

>
I feel your pain. I am 39. I taught my first programming class when I

15 (Apple IIe and IIgs). I stopped coding 4 years ago and opened my own
business doing network administration for small to mid-sized bsinesses.

gets boring, but it beats the hell out of coding for big companies like
Citibank, Porsche, Coca-Cola, etc. (The constant push to put apps out

they are ready...and all that crap.)
>
I have been planning on doing some .Net stuff, learning C & C++...but I am
(and I think everyone gets) not so impressed with technology any more. I
look for simple, cost effective solutions. I look for things that will

me do my job as fast as possible and go live a little.
>
In fact, it looks to me like the general population is tiring of the whole
technology boom. Just look at the Wii kicking the butts of Playstation

XBox.
>
I've screamed about it until blood has shot out of my mouth.....people

want simple. Simple has always outsold complex, and it always will.
>
Simple is more cost-effective and makes greater profit margins. Simple
means fewer tech support calls. Simple means money.
>
But, I'll be damned if anyone is listening.
>
Microsoft killed the most popular programming language EVER (in terms of
coders and application base) in favor of what? .Net?
>
.Net was never written for programmers. It was written by Microsoft, for
Microsoft's vision of software as a service. They lied to people to try

sell it (there NEVER was a "Dll Hell" and I can prove it). They push .Net
on programmers because they can.
>
(One more point and I promise....I'm off my soapbox.) And, Microsoft can
push programmers (and end users) around for one simple

data formats.
>
Proprietary data formats make it damned near impossible (practically or
financially) for businesses to leave Microsoft or Quickbooks or AutoCAD

thousands of other applications and move to a different app (much less a
different OS).
>
Things will never change until we enact legislation that enforces open

formats. All companies that store user data should be forced by law to
publish the data formats that the data is stored in BEFORE they can sell

update) their software that users will use to store data. After all, it

your data (regardless of what software package you use to compile or store
it) and it should always be your data and be portable to where ever you

to take it.
>
If we enacted open data format legislation, you would see a whole new,
affordable, usable downpour of applications and OS' begin to be used in
business and home use.
>
Software would have to compete based on usability, features and cost
effectiveness....not because the users can't easily or cost effectively

their data to an app more suited to their needs.
>
(OK....ok.....I'm stepping down now......)
>

"jim" <jim@yourpc.eduwrote in message
news:zSjgi.15878$19.5606@bignews5.bellsouth.net...USBburstsandthedoneVB.NET?theVB6notrealinwasItbeforeletandjustandreason...proprietaryordata(oriswantport>
Anyone can come up with a database format, and provided it communicates
via
internationally recognised standard formats, it does the job. It's the API
for which a standard needs to be set. This would be possible only if it
can
be legally recognised that the API is part of the IDEA of the operating
system and NOT part of its design. That way, the API can neither be
protected by copyright nor patent. As a programming level communications
standard necessary for cross-platform (XP) applications, I'd say that it's
not unreasonable to consider the API of ANY operating system fair game for
application in competing operating systems. If the Open Source crowd had
the
cajones to take the Windows API on as an application communication
standard,
all our apps would suddenly be Linux compatible as well...
>
The push for a redundant intermediate level API known as the framework via
.NET, signals plans to make major changes to the existing API - namely the
removal of substantial functionality. By going .NET your software becomes
forward compatible with respect to planned changes to Windows API. There
is
a lot of pressure from wealthy Hollywood nobs to remove functions that can
be used to directly access media without monitoring by the operating
system's anti-piracy routines. Equally, this means that the Open Source
crowd will not only have to take on the Microsoft for the Windows API but
also for the Framework as well - if the dream of true XP applications is
ever going to be realised...
>
I would suggest that the Hollywood set may not necessarily represent
American interests - something to remember next time you vote...
>
--
Timothy Casey GPEMC! >11950 is the number@fieldcraft.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
>
>

Whoa. Way to much for me. I am deleting this newsgroup and sticking with
VB6.general.discussion or whatever.
>
Galen
>
"Number 11950 - GPEMC! Replace number with 11950" <number@fieldcraft.biz>
wrote in message
news:46844838$0$67430$c30e37c6@lon-reader.news.telstra.net...