GUI Development Recommendations?
-
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:
-
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
Dan Neely wrote:
(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)
Take a look at this I use one of these daily, and it's a really good option if you want another monitor but don't have the port for it.
-
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.
You've taken 16 years to get to this point. Don't expect to get out of it in one release cycle. There are a lot of stakeholder attitudes and expectations that need to change. There is a lot of learning on the part of the team to get up to speed on new techniques and technologies. My recommendation is not to do a complete rewrite all at once. As a rough guess, I'd set expectations for this to be a two year project. The code base is only part of the problem; in fact it's probably more a symptom than the cause. Take a multi-pronged approach over multiple release cycles. You need to work with customers to get them to upgrade to newer equipment. This takes time. Let them know in X releases (i.e. Y months), they will no longer be supported on anything older than Windows Z. Pick reasonable values for X, Y and Z based on what needs to be done and the customers. A purely hypothetical example: 1 release in 6 months: XP is minimum requirement. 2 releases in 12 months: Win 7 is minimum requirement. You need to work with the team to get their workflow habits changed to a better process. Introduce unit testing, VCS, continuous integration. Each of these is one step. Pick one and focus on it until it's habit. Don't overwhelm everyone with trying to do everything all at once. And you need to update the code base. Pick a part that is most isolated from the rest in the current design and refactor it within the current environment to the point it's isolated enough to move to another environment. Only then move it to a new environment. Release and repeat. Through it all, you should never be very far away from a fully working version. (DLLs you don't have source for may be a perfect thing to start with. By definition they are pretty isolated. And rewriting those so you have source would reduce overall risk.) Sync code changes with the base system requirements you outline with the customer. I.e. don't try to put a brand spanking new GUI on as the first step with an XP requirement. Do the GUI part last when everyone is on up-to-date h/w. By the time you get to the GUI layer, the options may be significantly different than where we are today. Start with behind the scenes, lower layer stuff that is amenable to older .Net frameworks that won't change (much) on newer versions. Through it all, continue to add new features, improvements and bug fixes, so the releases have true value for the customer. You don't want to put them through upgrade pain just so you have a cleaner environment to work in. They don't care. But
-
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.
-
Dan Neely wrote:
(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)
Take a look at this I use one of these daily, and it's a really good option if you want another monitor but don't have the port for it.
I've considered something like that; but a few other people who've used similar devices reported that even scrolling a document resulted in lag/etc due to saturating the USB2 bus even at fairly moderate resolutions (I'd almost certainly be running 1280x1024 on #3). USB3 would solve the bandwidth issue once adapters become available, but neither my laptop nor my docking station support USB3; and even if I get a new laptop with USB3 un/replugging it on a daily basis would be a PITA so unless I get native 3 monitor support. Dell sells multiple docking station models; mine has 1 each DVI, VGA, and DP/HDMI (combined) ports; but I can only output to two of the three ports at any one time.
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
-
You've taken 16 years to get to this point. Don't expect to get out of it in one release cycle. There are a lot of stakeholder attitudes and expectations that need to change. There is a lot of learning on the part of the team to get up to speed on new techniques and technologies. My recommendation is not to do a complete rewrite all at once. As a rough guess, I'd set expectations for this to be a two year project. The code base is only part of the problem; in fact it's probably more a symptom than the cause. Take a multi-pronged approach over multiple release cycles. You need to work with customers to get them to upgrade to newer equipment. This takes time. Let them know in X releases (i.e. Y months), they will no longer be supported on anything older than Windows Z. Pick reasonable values for X, Y and Z based on what needs to be done and the customers. A purely hypothetical example: 1 release in 6 months: XP is minimum requirement. 2 releases in 12 months: Win 7 is minimum requirement. You need to work with the team to get their workflow habits changed to a better process. Introduce unit testing, VCS, continuous integration. Each of these is one step. Pick one and focus on it until it's habit. Don't overwhelm everyone with trying to do everything all at once. And you need to update the code base. Pick a part that is most isolated from the rest in the current design and refactor it within the current environment to the point it's isolated enough to move to another environment. Only then move it to a new environment. Release and repeat. Through it all, you should never be very far away from a fully working version. (DLLs you don't have source for may be a perfect thing to start with. By definition they are pretty isolated. And rewriting those so you have source would reduce overall risk.) Sync code changes with the base system requirements you outline with the customer. I.e. don't try to put a brand spanking new GUI on as the first step with an XP requirement. Do the GUI part last when everyone is on up-to-date h/w. By the time you get to the GUI layer, the options may be significantly different than where we are today. Start with behind the scenes, lower layer stuff that is amenable to older .Net frameworks that won't change (much) on newer versions. Through it all, continue to add new features, improvements and bug fixes, so the releases have true value for the customer. You don't want to put them through upgrade pain just so you have a cleaner environment to work in. They don't care. But
Thanks, Harley! Excellent advice and recommendations. That's kind of the path I'm trying to get us to take right now in the first place. My initial push has been trying to get VCS implemented. We've had no end of lost changes, lost versions, toes getting stepped on, etc. from EVERYONE working on the same VB project on the server. :doh: Yet, that's right. Everyone works on the same files on the server currently. :wtf: On RARE occasions, someone will take a local copy of the project to their HDD to work on it and "merge" (usually just copy) it back to the server when they are done. So yeah, VCS is a desperately needed first step. Specifications and unit testing are probably next in line, but are almost as foreign concepts as VCS currently. Long way to go... I do not anticipate this being a quick and easy process. I think realistically, two years for a complete changeover is probably optimistic. My main purpose for this thread was to try to gather some up-to-date information from CPians who have more experience with current tech that I do to try to get a feel for our options. WPF seems to be the strong preference. Although I'm intrigued by Phil's Qt/C++ recommendation as well. Personally, I'd like to experiment with a dedicated Linux box with all OS traces hidden from the user. Just boot right into the control application and run the equipment. I don't know how many machines we've had screwed up by operators messing around with the files outside of our application. But that's probably too big of a departure to tackle. We'll likely stick with Windows and just deal with the headaches that come with it.
-
Thanks, Harley! Excellent advice and recommendations. That's kind of the path I'm trying to get us to take right now in the first place. My initial push has been trying to get VCS implemented. We've had no end of lost changes, lost versions, toes getting stepped on, etc. from EVERYONE working on the same VB project on the server. :doh: Yet, that's right. Everyone works on the same files on the server currently. :wtf: On RARE occasions, someone will take a local copy of the project to their HDD to work on it and "merge" (usually just copy) it back to the server when they are done. So yeah, VCS is a desperately needed first step. Specifications and unit testing are probably next in line, but are almost as foreign concepts as VCS currently. Long way to go... I do not anticipate this being a quick and easy process. I think realistically, two years for a complete changeover is probably optimistic. My main purpose for this thread was to try to gather some up-to-date information from CPians who have more experience with current tech that I do to try to get a feel for our options. WPF seems to be the strong preference. Although I'm intrigued by Phil's Qt/C++ recommendation as well. Personally, I'd like to experiment with a dedicated Linux box with all OS traces hidden from the user. Just boot right into the control application and run the equipment. I don't know how many machines we've had screwed up by operators messing around with the files outside of our application. But that's probably too big of a departure to tackle. We'll likely stick with Windows and just deal with the headaches that come with it.
Ouch. Sounds like culture may be as big, if not bigger, a thing to overcome than the technical side of it. Personally I can't imagine not using a VCS on a project, even if I was a solo developer. The history of changes is just too valuable. Unit tests would probably be the next thing after VCS. Writing things so they are testable almost forces better, less coupled, design. If its hard to test, then typically the design needs to be changed. And specifications, to a large extent, fall out almost naturally. If I were doing it today on Windows only, I'd probably go with WPF. Qt/C++, while interesting, I'd only consider for a x-platform app. However, in a couple years, that may change, depending on what MS's long term plans are for WPF with respect to Windows 8+. That's why I said earlier, leave GUI decisions until last. By the time you get there, we may have a whole different paradigm. You know, you can make Windows boot to your own app too. I've not personally done it, but it's basically a registry change to point to your app instead of Windows Explorer.
-
I've considered something like that; but a few other people who've used similar devices reported that even scrolling a document resulted in lag/etc due to saturating the USB2 bus even at fairly moderate resolutions (I'd almost certainly be running 1280x1024 on #3). USB3 would solve the bandwidth issue once adapters become available, but neither my laptop nor my docking station support USB3; and even if I get a new laptop with USB3 un/replugging it on a daily basis would be a PITA so unless I get native 3 monitor support. Dell sells multiple docking station models; mine has 1 each DVI, VGA, and DP/HDMI (combined) ports; but I can only output to two of the three ports at any one time.
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
Like I said, I use one daily. While I wouldn't want to run hi-def full-screen video over it (youtube small videos work fine) I don't really see that much lag. As in none at all for web page and document scrolling. Also, I have a coworker who's running four of these off a Mac for day-to-day work and he's pretty happy with them. YMMV, of course.