From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
BreakPoint
Arrggghhhhhhh... VB6 again
Having just discussed VB6 in this thread, VB6 has reared its ugly head again.
I got an email last night asking me to extend the functionality of a VB6 program I wrote several years ago. I'm asking them if they'd consider moving to another language, but there's a lot of work involved (I'd love the payday, but they might not). What's a common solution to supporting legacy VB6 programs? Are people rewriting/replacing all their VB6 systems? Is it less effort to port it to VB.NET?
Thanks for the answer. Here are mine:
the amount of VB6 experience you'd have I wrote the program, so I know the structure of the code (textual spaghetti, literally) and the engineering behind the maths.
What's your estimate on the amount of time to add the functionality to the existing VB code? I'm still working on this, but I expect it'll be less than 100 hours of night and weekend work.
What's your estimate for completely rewriting it in LabVIEW? Forever, give or take an eternity. 🙂 But, I would be starting from a position of knowledge that I didn't have when starting the original almost ten years ago. I could ARCHITECT it!
When you ask whether it's less effort to port it to VB.NET are you asking relative to LabVIEW? I think so. It's a VB6 application so it makes sense to me that it'd be a shorter putt. It won't work in VB.NET, but I was thinking that it would be close.
If, for example, the app is doing a bunch of Windows API calls, then that's NOT going to be fun in LabVIEW. VB.NET isn't too bad, though, with respect to this. It's doing a bunch of calls to Adobe Illustrator's API. It would be a lot of short/wide VIs.
whether you want to really support this application I do.
I'm mostly interested in how I can help my customer not get stuck in the future. I added a tongue-in-cheek post to the other VB thread, but there was some real concern behind it. What's the risk that VB6 will not work in Windows 7 (I guess I could buy a Win7 PC and try it) or beyond. A colleague is trying to buy a license of Win XP to repair an old ATE and he can't find it (except EBay, which is prohibited) so keeping old PCs around forever isn't a great option. I also want to be the one they come back to, so it's in my interest to look to their future even before they do.
@smercurio_fc wrote:
[...] perhaps drop a strong hint that you may not be doing any more VB6 support in the future. But ultimately that's a business decision on your end, more than a programming decision.
I'll be willing to support VB6 for them until I become independantly wealthy. I'm thinking the OS environment will quit before I do.
I've got VB6 (and most MS studio products) on Win7 at home here-- Flipping NI driver DVD for 2011 is taking forever to install support- Can't say I USE VB6 ( or text languages) but the system doesn't crash
Too bad about the Adobe calls though
The VB6 runtime is basically just your run of the mill 32bit program, and is going to be officially supported by Win7 for the next few years, however you may need to write and update code in Win XP, as the IDE may run, but is not supported.
@Jeff Bohrer wrote:
Too bad about the Adobe calls though
Figuring out those Adobe calls has been profitable over the past few years. 😉 I tried to do create the same functionality in SolidWorks but I couldn't get lines to start close to each other (picture graduations on a pressure gauge dial) without ends snapping together. I'm sure I was doing something wrong, but Illustrator didn't give me that issue. Additionally, I got the Graphic Artist on my side by using the tool he uses. He'd be my biggest fan if I refactored my code to run on the Mac...
