GUI Development Recommendations?
-
Not sure if the lounge is the place for this, but I couldn't figure out any better place to post, so here goes... I've been working the last 8-9 years or so with a team that has developed an industrial machine control interface application from the ground up in VB (currently on VB6). This project was started in 1995, and we have hundreds of customer machines using the application. This means hundreds of configuration variants that need to be supported as well. This has been accomplished through various configuration data files and "Personality Factor" variables in the application. Needless to say, the application as a whole has become a huge mass of spaghetti-code, modules, classes, and some of our own in-house DLL's (some of which the source code appears to have been "lost"). The entire project desperately needs refactored/rewritten and brought up to date with the programming tools (I've just barely been able to pique my manager's interest in the benefits of using VCS!) and languages that are available to us now. The problem is, none of us have really worked with much outside of VB6 for quite a while and aren't familiar with what is currently available for GUI development. I was hoping to get some input from the userbase here on CP as to what GUI languages and tools have been having the most success lately. Some of our project features/requirements that are critical include: * Runtime-configurable displays (hundreds of machine configurations to support) * Multi-language (w/ Unicode) support, selectable/editable at runtime. Currently, our language files are a single database for each installation, user editable either through context menus or our own "safe" external database editing tool. * Database support (for importing existing customer data, machine configurations, production recipes, etc.) Old database would be Access97 format, currently accessed via DAO 3.51. * Communication support for both serial and Ethernet based protocols. * Compatible with old computers. We have some customers who still survive on Win'98! We may end up forcing them to upgrade OS's, but there are a significant number of our machines out there with Win2k and Win'98. WinXP is a minimum compatibility requirement. And the ability to play nicely with XP, Vista and Win7 is preferred. This list list could probably continue from here to next year, but I've already got a whole page here, so I'd better stop and see if I can get some feedback before I bore you all any futher.
nedmech wrote:
We have some customers who still survive on Win'98!
With that single statement, you've doomed yourself to a non .Net solution, so there's no point in wndering what's available unless you're willing to abandon the customers that refuse to upgrade (and who, by all rights, SHOULD be abandoned so that your other customers can reap the benefits of better security and performance).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Not sure if the lounge is the place for this, but I couldn't figure out any better place to post, so here goes... I've been working the last 8-9 years or so with a team that has developed an industrial machine control interface application from the ground up in VB (currently on VB6). This project was started in 1995, and we have hundreds of customer machines using the application. This means hundreds of configuration variants that need to be supported as well. This has been accomplished through various configuration data files and "Personality Factor" variables in the application. Needless to say, the application as a whole has become a huge mass of spaghetti-code, modules, classes, and some of our own in-house DLL's (some of which the source code appears to have been "lost"). The entire project desperately needs refactored/rewritten and brought up to date with the programming tools (I've just barely been able to pique my manager's interest in the benefits of using VCS!) and languages that are available to us now. The problem is, none of us have really worked with much outside of VB6 for quite a while and aren't familiar with what is currently available for GUI development. I was hoping to get some input from the userbase here on CP as to what GUI languages and tools have been having the most success lately. Some of our project features/requirements that are critical include: * Runtime-configurable displays (hundreds of machine configurations to support) * Multi-language (w/ Unicode) support, selectable/editable at runtime. Currently, our language files are a single database for each installation, user editable either through context menus or our own "safe" external database editing tool. * Database support (for importing existing customer data, machine configurations, production recipes, etc.) Old database would be Access97 format, currently accessed via DAO 3.51. * Communication support for both serial and Ethernet based protocols. * Compatible with old computers. We have some customers who still survive on Win'98! We may end up forcing them to upgrade OS's, but there are a significant number of our machines out there with Win2k and Win'98. WinXP is a minimum compatibility requirement. And the ability to play nicely with XP, Vista and Win7 is preferred. This list list could probably continue from here to next year, but I've already got a whole page here, so I'd better stop and see if I can get some feedback before I bore you all any futher.
My biggest question would be why? Is there a signficant cost in maintainence right now? Is the current architecture unsuitable for future feature requests? If you've got 100's of machines using existing software with (presumably) few issues, why go through the pain and expense of creating a shiny new system with more bugs? Where's the benefit to the customer? Assuming you've thought it all through and it's still an important thing to do, I would recommend Qt and C++. And the main reason for that is to satisfy the requirements with working with older hardware and systems. WPF and WinForms are just too slow for 10 year old computers, especially for industrial work. Well, in my opinion anyway. But to be honest I wouldn't even bother. If you're entire team is totally experienced in VB6, the cost of retraining will be so large, and so many mistakes made, I sure hope your upgrade brings in lots of new customers, you'll need the new income to cover the costs! If you can get a tiny bit of wiggle room on the computer requirements, then I'd go for Vb.Net and WinForms. It's close enough to not scare existing developers, but .Net enough to learn something new and take advantage of the new tools out there.
-
Not sure if the lounge is the place for this, but I couldn't figure out any better place to post, so here goes... I've been working the last 8-9 years or so with a team that has developed an industrial machine control interface application from the ground up in VB (currently on VB6). This project was started in 1995, and we have hundreds of customer machines using the application. This means hundreds of configuration variants that need to be supported as well. This has been accomplished through various configuration data files and "Personality Factor" variables in the application. Needless to say, the application as a whole has become a huge mass of spaghetti-code, modules, classes, and some of our own in-house DLL's (some of which the source code appears to have been "lost"). The entire project desperately needs refactored/rewritten and brought up to date with the programming tools (I've just barely been able to pique my manager's interest in the benefits of using VCS!) and languages that are available to us now. The problem is, none of us have really worked with much outside of VB6 for quite a while and aren't familiar with what is currently available for GUI development. I was hoping to get some input from the userbase here on CP as to what GUI languages and tools have been having the most success lately. Some of our project features/requirements that are critical include: * Runtime-configurable displays (hundreds of machine configurations to support) * Multi-language (w/ Unicode) support, selectable/editable at runtime. Currently, our language files are a single database for each installation, user editable either through context menus or our own "safe" external database editing tool. * Database support (for importing existing customer data, machine configurations, production recipes, etc.) Old database would be Access97 format, currently accessed via DAO 3.51. * Communication support for both serial and Ethernet based protocols. * Compatible with old computers. We have some customers who still survive on Win'98! We may end up forcing them to upgrade OS's, but there are a significant number of our machines out there with Win2k and Win'98. WinXP is a minimum compatibility requirement. And the ability to play nicely with XP, Vista and Win7 is preferred. This list list could probably continue from here to next year, but I've already got a whole page here, so I'd better stop and see if I can get some feedback before I bore you all any futher.
Like stated above, I'd start by making XP the minimum requirement. I'd use the .net framework, and switching to VB.net wouldn't take too much retraining. You might want to consider having someone with experience consulting at the beginning, just to make sure that it's well structured from the beginning. Even if you stay on '98, you can use VB.net, you'll just have to target older versions of it. I think 2.0 was the last that ran on '98. You won't have all classes available though, but I had to run a few programs on it a few years back, and you can work around most issues.
-
My biggest question would be why? Is there a signficant cost in maintainence right now? Is the current architecture unsuitable for future feature requests? If you've got 100's of machines using existing software with (presumably) few issues, why go through the pain and expense of creating a shiny new system with more bugs? Where's the benefit to the customer? Assuming you've thought it all through and it's still an important thing to do, I would recommend Qt and C++. And the main reason for that is to satisfy the requirements with working with older hardware and systems. WPF and WinForms are just too slow for 10 year old computers, especially for industrial work. Well, in my opinion anyway. But to be honest I wouldn't even bother. If you're entire team is totally experienced in VB6, the cost of retraining will be so large, and so many mistakes made, I sure hope your upgrade brings in lots of new customers, you'll need the new income to cover the costs! If you can get a tiny bit of wiggle room on the computer requirements, then I'd go for Vb.Net and WinForms. It's close enough to not scare existing developers, but .Net enough to learn something new and take advantage of the new tools out there.
Phil Martin... wrote:
And the main reason for that is to satisfy the requirements with working with older hardware and systems. WPF and WinForms are just too slow for 10 year old computers, especially for industrial work. Well, in my opinion anyway.
It's not just raw speed. You'd also be stuck on obsolete versions of the framework/visual studio. NT4 tops out at .net 1.1, win98 and 2k at 2.0. NT4 is the biggest killer since 1.1 framework means you're trapped with VS 2003, and without the use of generics which make using collections much uglier (since you have to constantly cast from object and validate results). The 2.0 framework is the minimum version supported with VS 2k10.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Phil Martin... wrote:
And the main reason for that is to satisfy the requirements with working with older hardware and systems. WPF and WinForms are just too slow for 10 year old computers, especially for industrial work. Well, in my opinion anyway.
It's not just raw speed. You'd also be stuck on obsolete versions of the framework/visual studio. NT4 tops out at .net 1.1, win98 and 2k at 2.0. NT4 is the biggest killer since 1.1 framework means you're trapped with VS 2003, and without the use of generics which make using collections much uglier (since you have to constantly cast from object and validate results). The 2.0 framework is the minimum version supported with VS 2k10.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
Totally. It's just an all round bad situation. It makes switching to anything "modern" so so painful.
-
Totally. It's just an all round bad situation. It makes switching to anything "modern" so so painful.
yup. It was bad enough when I was doing stuck in VS 2k3 in 05-07 due to an NT4 req; I don't even want to think about how much worse it would be today. I've still got the y2k pass stickered :rolleyes: relic I used for NT4 testing sitting in my cube (although at this point it's more so that if I ever get a triple monitor capable laptop I have a 3rd lcd sitting at my desk already).
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Not sure if the lounge is the place for this, but I couldn't figure out any better place to post, so here goes... I've been working the last 8-9 years or so with a team that has developed an industrial machine control interface application from the ground up in VB (currently on VB6). This project was started in 1995, and we have hundreds of customer machines using the application. This means hundreds of configuration variants that need to be supported as well. This has been accomplished through various configuration data files and "Personality Factor" variables in the application. Needless to say, the application as a whole has become a huge mass of spaghetti-code, modules, classes, and some of our own in-house DLL's (some of which the source code appears to have been "lost"). The entire project desperately needs refactored/rewritten and brought up to date with the programming tools (I've just barely been able to pique my manager's interest in the benefits of using VCS!) and languages that are available to us now. The problem is, none of us have really worked with much outside of VB6 for quite a while and aren't familiar with what is currently available for GUI development. I was hoping to get some input from the userbase here on CP as to what GUI languages and tools have been having the most success lately. Some of our project features/requirements that are critical include: * Runtime-configurable displays (hundreds of machine configurations to support) * Multi-language (w/ Unicode) support, selectable/editable at runtime. Currently, our language files are a single database for each installation, user editable either through context menus or our own "safe" external database editing tool. * Database support (for importing existing customer data, machine configurations, production recipes, etc.) Old database would be Access97 format, currently accessed via DAO 3.51. * Communication support for both serial and Ethernet based protocols. * Compatible with old computers. We have some customers who still survive on Win'98! We may end up forcing them to upgrade OS's, but there are a significant number of our machines out there with Win2k and Win'98. WinXP is a minimum compatibility requirement. And the ability to play nicely with XP, Vista and Win7 is preferred. This list list could probably continue from here to next year, but I've already got a whole page here, so I'd better stop and see if I can get some feedback before I bore you all any futher.
I'll go with the rest, you are going to have to force through a hardware and OS upgrade, I would aim for w7, by the time this rewrite is done XP will no longer be viable. If you are going to go through the pain of this process then do it right. I would be using SQL Server and probably WPF. I would also force yourselves to move to C#, there are better support resources out there and most examples are in C#. The transition is not that painful and you have to make one anyway so go to C#. I have no experience with MEF but the concept seems to align with your requirements. I would also look into restructuring your database, anything with a lifespan like your app can probably use a complete rewrite. Don't let the bean counters nickle and dime you into a half way patch upgrade, take the pain and go for a complete rewrite.
Never underestimate the power of human stupidity RAH
-
My biggest question would be why? Is there a signficant cost in maintainence right now? Is the current architecture unsuitable for future feature requests? If you've got 100's of machines using existing software with (presumably) few issues, why go through the pain and expense of creating a shiny new system with more bugs? Where's the benefit to the customer? Assuming you've thought it all through and it's still an important thing to do, I would recommend Qt and C++. And the main reason for that is to satisfy the requirements with working with older hardware and systems. WPF and WinForms are just too slow for 10 year old computers, especially for industrial work. Well, in my opinion anyway. But to be honest I wouldn't even bother. If you're entire team is totally experienced in VB6, the cost of retraining will be so large, and so many mistakes made, I sure hope your upgrade brings in lots of new customers, you'll need the new income to cover the costs! If you can get a tiny bit of wiggle room on the computer requirements, then I'd go for Vb.Net and WinForms. It's close enough to not scare existing developers, but .Net enough to learn something new and take advantage of the new tools out there.
I completely get your point, Phil. The biggest drive to change things comes from us grunts in development who are having to maintain a tangled mess of non-standardized methods that has devolved into chaos over the product's lifetime. We have a solid concept of how the machine operates and what a user needs to be able to interface with it, but the implementation is so scattered that it's become more than difficult to work on. We currently have some large customers clamoring for a cleaner, simplified interface application, so it would be a prefect time to go back to basics, document the hell out of how things are supposed to work, then code to a well-defined spec from the ground up. The ultimate goal is to have a more stable, predictable application (both in use and in trouble-shooting) that is up-to-date with current standards and methods. Of course, we could just refactor in VB6, but the tendency will be to just reuse code whether it is clean or not. Having a new language to code to kinda forces the re-think process a bit more (which is the desired effect). Most of this is probably a pipe-dream on my part, but I'm at least gonna give it my best effort with as much information to back up my ideas as possible.
-
Not sure if the lounge is the place for this, but I couldn't figure out any better place to post, so here goes... I've been working the last 8-9 years or so with a team that has developed an industrial machine control interface application from the ground up in VB (currently on VB6). This project was started in 1995, and we have hundreds of customer machines using the application. This means hundreds of configuration variants that need to be supported as well. This has been accomplished through various configuration data files and "Personality Factor" variables in the application. Needless to say, the application as a whole has become a huge mass of spaghetti-code, modules, classes, and some of our own in-house DLL's (some of which the source code appears to have been "lost"). The entire project desperately needs refactored/rewritten and brought up to date with the programming tools (I've just barely been able to pique my manager's interest in the benefits of using VCS!) and languages that are available to us now. The problem is, none of us have really worked with much outside of VB6 for quite a while and aren't familiar with what is currently available for GUI development. I was hoping to get some input from the userbase here on CP as to what GUI languages and tools have been having the most success lately. Some of our project features/requirements that are critical include: * Runtime-configurable displays (hundreds of machine configurations to support) * Multi-language (w/ Unicode) support, selectable/editable at runtime. Currently, our language files are a single database for each installation, user editable either through context menus or our own "safe" external database editing tool. * Database support (for importing existing customer data, machine configurations, production recipes, etc.) Old database would be Access97 format, currently accessed via DAO 3.51. * Communication support for both serial and Ethernet based protocols. * Compatible with old computers. We have some customers who still survive on Win'98! We may end up forcing them to upgrade OS's, but there are a significant number of our machines out there with Win2k and Win'98. WinXP is a minimum compatibility requirement. And the ability to play nicely with XP, Vista and Win7 is preferred. This list list could probably continue from here to next year, but I've already got a whole page here, so I'd better stop and see if I can get some feedback before I bore you all any futher.
VB.net is the easiest developer upgrade from VB6, though at least some of you would need to learn C# as that's what most of the helpful resources are in. If you can enforce an OS that will run .Net 2.0, so you have generics, and you're happy to develop in WinForms, you aren't missing out on that much in 3.5 (basically just WPF) or 4.0.
-
Not sure if the lounge is the place for this, but I couldn't figure out any better place to post, so here goes... I've been working the last 8-9 years or so with a team that has developed an industrial machine control interface application from the ground up in VB (currently on VB6). This project was started in 1995, and we have hundreds of customer machines using the application. This means hundreds of configuration variants that need to be supported as well. This has been accomplished through various configuration data files and "Personality Factor" variables in the application. Needless to say, the application as a whole has become a huge mass of spaghetti-code, modules, classes, and some of our own in-house DLL's (some of which the source code appears to have been "lost"). The entire project desperately needs refactored/rewritten and brought up to date with the programming tools (I've just barely been able to pique my manager's interest in the benefits of using VCS!) and languages that are available to us now. The problem is, none of us have really worked with much outside of VB6 for quite a while and aren't familiar with what is currently available for GUI development. I was hoping to get some input from the userbase here on CP as to what GUI languages and tools have been having the most success lately. Some of our project features/requirements that are critical include: * Runtime-configurable displays (hundreds of machine configurations to support) * Multi-language (w/ Unicode) support, selectable/editable at runtime. Currently, our language files are a single database for each installation, user editable either through context menus or our own "safe" external database editing tool. * Database support (for importing existing customer data, machine configurations, production recipes, etc.) Old database would be Access97 format, currently accessed via DAO 3.51. * Communication support for both serial and Ethernet based protocols. * Compatible with old computers. We have some customers who still survive on Win'98! We may end up forcing them to upgrade OS's, but there are a significant number of our machines out there with Win2k and Win'98. WinXP is a minimum compatibility requirement. And the ability to play nicely with XP, Vista and Win7 is preferred. This list list could probably continue from here to next year, but I've already got a whole page here, so I'd better stop and see if I can get some feedback before I bore you all any futher.
-
Not sure if the lounge is the place for this, but I couldn't figure out any better place to post, so here goes... I've been working the last 8-9 years or so with a team that has developed an industrial machine control interface application from the ground up in VB (currently on VB6). This project was started in 1995, and we have hundreds of customer machines using the application. This means hundreds of configuration variants that need to be supported as well. This has been accomplished through various configuration data files and "Personality Factor" variables in the application. Needless to say, the application as a whole has become a huge mass of spaghetti-code, modules, classes, and some of our own in-house DLL's (some of which the source code appears to have been "lost"). The entire project desperately needs refactored/rewritten and brought up to date with the programming tools (I've just barely been able to pique my manager's interest in the benefits of using VCS!) and languages that are available to us now. The problem is, none of us have really worked with much outside of VB6 for quite a while and aren't familiar with what is currently available for GUI development. I was hoping to get some input from the userbase here on CP as to what GUI languages and tools have been having the most success lately. Some of our project features/requirements that are critical include: * Runtime-configurable displays (hundreds of machine configurations to support) * Multi-language (w/ Unicode) support, selectable/editable at runtime. Currently, our language files are a single database for each installation, user editable either through context menus or our own "safe" external database editing tool. * Database support (for importing existing customer data, machine configurations, production recipes, etc.) Old database would be Access97 format, currently accessed via DAO 3.51. * Communication support for both serial and Ethernet based protocols. * Compatible with old computers. We have some customers who still survive on Win'98! We may end up forcing them to upgrade OS's, but there are a significant number of our machines out there with Win2k and Win'98. WinXP is a minimum compatibility requirement. And the ability to play nicely with XP, Vista and Win7 is preferred. This list list could probably continue from here to next year, but I've already got a whole page here, so I'd better stop and see if I can get some feedback before I bore you all any futher.
First of all get rid of Windows 98 OS. Then you will be able to use either WinForms or WPF. But, since you still have Win98 and 2k I figure the hardware is also pretty old so I would go for WinForms which requires a bit less resources. Good luck. :)
Liviu M.
-
My biggest question would be why? Is there a signficant cost in maintainence right now? Is the current architecture unsuitable for future feature requests? If you've got 100's of machines using existing software with (presumably) few issues, why go through the pain and expense of creating a shiny new system with more bugs? Where's the benefit to the customer? Assuming you've thought it all through and it's still an important thing to do, I would recommend Qt and C++. And the main reason for that is to satisfy the requirements with working with older hardware and systems. WPF and WinForms are just too slow for 10 year old computers, especially for industrial work. Well, in my opinion anyway. But to be honest I wouldn't even bother. If you're entire team is totally experienced in VB6, the cost of retraining will be so large, and so many mistakes made, I sure hope your upgrade brings in lots of new customers, you'll need the new income to cover the costs! If you can get a tiny bit of wiggle room on the computer requirements, then I'd go for Vb.Net and WinForms. It's close enough to not scare existing developers, but .Net enough to learn something new and take advantage of the new tools out there.
Phil Martin... wrote:
My biggest question would be why?
IF you have to ask this, then I wouldn't want to hire you. But here are a few answers to consider: 1) Security updates - No patches for the framework or the OS it is running on. 2) Career security - Have you looked at the number of jobs asking for VB6 lately? I would seriously look to update your skills and find a new employer. Your employer does not care about your career, you must take care of it. 3) He has mentioned the mess that it has become. This would be good place to start in cleaning up. 4) One day some customers will do a security audit. The new IT department will replace the product with something that is less likely to have the huge security holes mentioned in #1.
Phil Martin... wrote:
But to be honest I wouldn't even bother. If you're entire team is totally experienced in VB6, the cost of retraining will be so large, and so many mistakes made, I sure hope your upgrade brings in lots of new customers, you'll need the new income to cover the costs!
This is all wonderful as long as the team stays put. The cost of replacing a single member is going up every day. In fact, replacing a team member will probably require deceiving candidates (or they will settle for the bottom of the barrel). It may be time to consider what will happen when the team moves on. Someone will before too long. Perhaps because they realized that their career is in mortal danger. Perhaps because a bus hits them. Perhaps because the mate of their dreams drags them to another city. At any rate, the team will turn over eventually. The big thing is that you are in a hole which is going to be very hard to climb out of. The time to start digging out was yesterday.
-
Not sure if the lounge is the place for this, but I couldn't figure out any better place to post, so here goes... I've been working the last 8-9 years or so with a team that has developed an industrial machine control interface application from the ground up in VB (currently on VB6). This project was started in 1995, and we have hundreds of customer machines using the application. This means hundreds of configuration variants that need to be supported as well. This has been accomplished through various configuration data files and "Personality Factor" variables in the application. Needless to say, the application as a whole has become a huge mass of spaghetti-code, modules, classes, and some of our own in-house DLL's (some of which the source code appears to have been "lost"). The entire project desperately needs refactored/rewritten and brought up to date with the programming tools (I've just barely been able to pique my manager's interest in the benefits of using VCS!) and languages that are available to us now. The problem is, none of us have really worked with much outside of VB6 for quite a while and aren't familiar with what is currently available for GUI development. I was hoping to get some input from the userbase here on CP as to what GUI languages and tools have been having the most success lately. Some of our project features/requirements that are critical include: * Runtime-configurable displays (hundreds of machine configurations to support) * Multi-language (w/ Unicode) support, selectable/editable at runtime. Currently, our language files are a single database for each installation, user editable either through context menus or our own "safe" external database editing tool. * Database support (for importing existing customer data, machine configurations, production recipes, etc.) Old database would be Access97 format, currently accessed via DAO 3.51. * Communication support for both serial and Ethernet based protocols. * Compatible with old computers. We have some customers who still survive on Win'98! We may end up forcing them to upgrade OS's, but there are a significant number of our machines out there with Win2k and Win'98. WinXP is a minimum compatibility requirement. And the ability to play nicely with XP, Vista and Win7 is preferred. This list list could probably continue from here to next year, but I've already got a whole page here, so I'd better stop and see if I can get some feedback before I bore you all any futher.
It seems to me you are asking the wrong question. Your business requirements, to support OS's past the point of supplier support and machines past their useful life force you to use tools developed when these OS's and machines were top spec. Instead I would ask "how can I change our development process to encorage refactoring and better design?" The answers might include pair programming, code reviews, documentation, design reviews, agile management techniques such as SCRUM, or any combination of elements. At some point you will have to take the pain and update but the real business benifit must outweigh the desire to play with the latest toys.
-
Not sure if the lounge is the place for this, but I couldn't figure out any better place to post, so here goes... I've been working the last 8-9 years or so with a team that has developed an industrial machine control interface application from the ground up in VB (currently on VB6). This project was started in 1995, and we have hundreds of customer machines using the application. This means hundreds of configuration variants that need to be supported as well. This has been accomplished through various configuration data files and "Personality Factor" variables in the application. Needless to say, the application as a whole has become a huge mass of spaghetti-code, modules, classes, and some of our own in-house DLL's (some of which the source code appears to have been "lost"). The entire project desperately needs refactored/rewritten and brought up to date with the programming tools (I've just barely been able to pique my manager's interest in the benefits of using VCS!) and languages that are available to us now. The problem is, none of us have really worked with much outside of VB6 for quite a while and aren't familiar with what is currently available for GUI development. I was hoping to get some input from the userbase here on CP as to what GUI languages and tools have been having the most success lately. Some of our project features/requirements that are critical include: * Runtime-configurable displays (hundreds of machine configurations to support) * Multi-language (w/ Unicode) support, selectable/editable at runtime. Currently, our language files are a single database for each installation, user editable either through context menus or our own "safe" external database editing tool. * Database support (for importing existing customer data, machine configurations, production recipes, etc.) Old database would be Access97 format, currently accessed via DAO 3.51. * Communication support for both serial and Ethernet based protocols. * Compatible with old computers. We have some customers who still survive on Win'98! We may end up forcing them to upgrade OS's, but there are a significant number of our machines out there with Win2k and Win'98. WinXP is a minimum compatibility requirement. And the ability to play nicely with XP, Vista and Win7 is preferred. This list list could probably continue from here to next year, but I've already got a whole page here, so I'd better stop and see if I can get some feedback before I bore you all any futher.
Been almost exactly there in my previous job and I feel your pain. It took about 2 years for us to learn VB.NET well enough and get comfortable with what it could do and rebuild most of the code base. (I left with one component still left to do.) Mind you, we were also fairly busy on multiple customer projects at the same time. I don't normally comment, but thought I would make a note on serial comms. They are significantly different from VB6 and unless something has changed recently, you will want to build at least the serial components against .NET Framework 2.0. See here: http://social.msdn.microsoft.com/forums/en-US/Vsexpressvb/thread/3e64f562-e74b-4213-8019-e69f54fc0d74/[^] Also, this site will provide you with a significant head start on the serial side: http://www.innovatic.dk/knowledg/SerialCOM/SerialCOM.htm[^]
-
Been almost exactly there in my previous job and I feel your pain. It took about 2 years for us to learn VB.NET well enough and get comfortable with what it could do and rebuild most of the code base. (I left with one component still left to do.) Mind you, we were also fairly busy on multiple customer projects at the same time. I don't normally comment, but thought I would make a note on serial comms. They are significantly different from VB6 and unless something has changed recently, you will want to build at least the serial components against .NET Framework 2.0. See here: http://social.msdn.microsoft.com/forums/en-US/Vsexpressvb/thread/3e64f562-e74b-4213-8019-e69f54fc0d74/[^] Also, this site will provide you with a significant head start on the serial side: http://www.innovatic.dk/knowledg/SerialCOM/SerialCOM.htm[^]
I also have been doing serial comms using .NET for several years now (I use C#, but the framework is the same for VB.NET also). What I have found is exactly what you found, BUT also I have found that the drivers for the USB to serial adapters have a GREAT impact on whether the issues listed occur. I had all kinds of problems with 3.5 RTM, but none since I upgraded my drivers as well as upgrading to at least 3.5 SP1 for the framework (I now use 4.0 with no issues either). In general, the USB to serial adapters use one of two types of drivers, with far and away the most common being by Prolific. If you search for them on the web, they will have drivers at their site. I have found that the drivers shipped with the adapters are nowhere near as good as the ones you download directly from the chip manufacturers themselves. One other thing to remember is that there are many 3rd party tools you can use to do serial comms with .NET also if using the framework either scares you or is more work than you want to put in. David
-
Not sure if the lounge is the place for this, but I couldn't figure out any better place to post, so here goes... I've been working the last 8-9 years or so with a team that has developed an industrial machine control interface application from the ground up in VB (currently on VB6). This project was started in 1995, and we have hundreds of customer machines using the application. This means hundreds of configuration variants that need to be supported as well. This has been accomplished through various configuration data files and "Personality Factor" variables in the application. Needless to say, the application as a whole has become a huge mass of spaghetti-code, modules, classes, and some of our own in-house DLL's (some of which the source code appears to have been "lost"). The entire project desperately needs refactored/rewritten and brought up to date with the programming tools (I've just barely been able to pique my manager's interest in the benefits of using VCS!) and languages that are available to us now. The problem is, none of us have really worked with much outside of VB6 for quite a while and aren't familiar with what is currently available for GUI development. I was hoping to get some input from the userbase here on CP as to what GUI languages and tools have been having the most success lately. Some of our project features/requirements that are critical include: * Runtime-configurable displays (hundreds of machine configurations to support) * Multi-language (w/ Unicode) support, selectable/editable at runtime. Currently, our language files are a single database for each installation, user editable either through context menus or our own "safe" external database editing tool. * Database support (for importing existing customer data, machine configurations, production recipes, etc.) Old database would be Access97 format, currently accessed via DAO 3.51. * Communication support for both serial and Ethernet based protocols. * Compatible with old computers. We have some customers who still survive on Win'98! We may end up forcing them to upgrade OS's, but there are a significant number of our machines out there with Win2k and Win'98. WinXP is a minimum compatibility requirement. And the ability to play nicely with XP, Vista and Win7 is preferred. This list list could probably continue from here to next year, but I've already got a whole page here, so I'd better stop and see if I can get some feedback before I bore you all any futher.
While it is always good to look around and stay abreast of the latest technology, I believe that in the end it comes down to a business decision and an answer to the following question that will determine what kind of tools you will be using in the future: How long will the organization support profitable (?) legacy customers at the expense of new business lost due to the limitation of the current implementation (e.g. security issues, lack of innovation)? Few decision makers really care if your code is a huge mass of spaghetti code or what kind of tools you are using. They are interested in the bottom line (compare your manager’s interest in VCS). If you want to change the tools you are using, make the case for the bottom line first. Kirk Wood made some great points about the security and human resource aspects of legacy systems and developers that should make management really start thinking about the future: 1) Security updates - No patches for the framework or the OS it is running on. 2) Career security - Have you looked at the number of jobs asking for VB6 lately? I would seriously look to update your skills and find a new employer. Your employer does not care about your career, you must take care of it. 3) He has mentioned the mess that it has become. This would be good place to start in cleaning up. 4) One day some customers will do a security audit. The new IT department will replace the product with something that is less likely to have the huge security holes mentioned in #1.
-
I also have been doing serial comms using .NET for several years now (I use C#, but the framework is the same for VB.NET also). What I have found is exactly what you found, BUT also I have found that the drivers for the USB to serial adapters have a GREAT impact on whether the issues listed occur. I had all kinds of problems with 3.5 RTM, but none since I upgraded my drivers as well as upgrading to at least 3.5 SP1 for the framework (I now use 4.0 with no issues either). In general, the USB to serial adapters use one of two types of drivers, with far and away the most common being by Prolific. If you search for them on the web, they will have drivers at their site. I have found that the drivers shipped with the adapters are nowhere near as good as the ones you download directly from the chip manufacturers themselves. One other thing to remember is that there are many 3rd party tools you can use to do serial comms with .NET also if using the framework either scares you or is more work than you want to put in. David
Thanks for the heads-up on the serial issues. I'll definitely keep the information in mind. USB-to-Serial isn't usually an issue though since the industrial PC's we use (B&R Automation) either have onboard serial already built in, or PCI slots for more ports (typically, we use SeaLevel boards). We've had some experience with the trouble getting USB-to-Serial to work as well and ended up ditching it due to all the headaches, not to mention better performance from a PCI card implementation.
-
Phil Martin... wrote:
My biggest question would be why?
IF you have to ask this, then I wouldn't want to hire you. But here are a few answers to consider: 1) Security updates - No patches for the framework or the OS it is running on. 2) Career security - Have you looked at the number of jobs asking for VB6 lately? I would seriously look to update your skills and find a new employer. Your employer does not care about your career, you must take care of it. 3) He has mentioned the mess that it has become. This would be good place to start in cleaning up. 4) One day some customers will do a security audit. The new IT department will replace the product with something that is less likely to have the huge security holes mentioned in #1.
Phil Martin... wrote:
But to be honest I wouldn't even bother. If you're entire team is totally experienced in VB6, the cost of retraining will be so large, and so many mistakes made, I sure hope your upgrade brings in lots of new customers, you'll need the new income to cover the costs!
This is all wonderful as long as the team stays put. The cost of replacing a single member is going up every day. In fact, replacing a team member will probably require deceiving candidates (or they will settle for the bottom of the barrel). It may be time to consider what will happen when the team moves on. Someone will before too long. Perhaps because they realized that their career is in mortal danger. Perhaps because a bus hits them. Perhaps because the mate of their dreams drags them to another city. At any rate, the team will turn over eventually. The big thing is that you are in a hole which is going to be very hard to climb out of. The time to start digging out was yesterday.
Kirk, you and Phil both have great points. Unfortunately for the project, history around here tends to side with Phil. Mentalities are very difficult to change with the entrenchment we have. Turnover rate around here is very low. We're a small team of 6 developers (including the manager), and I've been here the shortest amount of time (8-9 years). We've had some younger developers (basically fresh out of school) come and go from time to time with varying degrees of success (I guess that's kind of a point in your favor, Kirk), but the core group has pretty much stayed the same for quite a while. Additionally, security has never been much of a concern for our customers because these machines are rarely connected to a LAN, much less the internet. Of course, that's a whole different issue with certain customers wanting to be able to incorporate remote machine control and SCADA-like features that we have never implemented. Of course, with a new development environment, some of those features may become more feasible, and security could become more of an issue.
-
It seems to me you are asking the wrong question. Your business requirements, to support OS's past the point of supplier support and machines past their useful life force you to use tools developed when these OS's and machines were top spec. Instead I would ask "how can I change our development process to encorage refactoring and better design?" The answers might include pair programming, code reviews, documentation, design reviews, agile management techniques such as SCRUM, or any combination of elements. At some point you will have to take the pain and update but the real business benifit must outweigh the desire to play with the latest toys.
Excellent point. My biggest hurdle towards trying to change the development process is the huge level of entrenchment due to the lifespan of the application. Our existing codebase is littered with approximately 30-40% commented-out code "for legacy purposes". There has been no unified method for naming conventions, module/class interfaces, or variable management over the life of the project. The overwhelming tendency for adding a new feature is to copy and old feature that "is almost what is needed", rename things slightly, comment out the "unnecessary" parts, and hack a kludge on top of it. Yes, the poor practices could be eliminated from here on out, but the tendency to "reuse" something instead of reevaluating and refactoring is more than likely going to remain too much of a temptation if we stay in VB6. Part of the desire to change environments is to force a fresh perspective and establishe some standards and best-practices from the get-go and break away from the entrenchment issues.
-
While it is always good to look around and stay abreast of the latest technology, I believe that in the end it comes down to a business decision and an answer to the following question that will determine what kind of tools you will be using in the future: How long will the organization support profitable (?) legacy customers at the expense of new business lost due to the limitation of the current implementation (e.g. security issues, lack of innovation)? Few decision makers really care if your code is a huge mass of spaghetti code or what kind of tools you are using. They are interested in the bottom line (compare your manager’s interest in VCS). If you want to change the tools you are using, make the case for the bottom line first. Kirk Wood made some great points about the security and human resource aspects of legacy systems and developers that should make management really start thinking about the future: 1) Security updates - No patches for the framework or the OS it is running on. 2) Career security - Have you looked at the number of jobs asking for VB6 lately? I would seriously look to update your skills and find a new employer. Your employer does not care about your career, you must take care of it. 3) He has mentioned the mess that it has become. This would be good place to start in cleaning up. 4) One day some customers will do a security audit. The new IT department will replace the product with something that is less likely to have the huge security holes mentioned in #1.
There have been several well-argued points made for evaluating the cost-benefit and bottom line of making a huge change like this. The only problem with that line of thought is that our company has never charged for our control software, or for version updates. It is "bundled" into to original cost of the machery (typically ~$500K-$800K for a complete line), and then we support the software "for life". Our department is basically a huge fiscal black-hole to the company. Essentially, no matter what we do, the development group never shows up on the books as bringing in any kind of income. So evaluating and arguing for how a change like this would contribute to the bottom line is not an easy thing to do. :confused: