Visual C++/MFC vs. Visual Basic
Author |
Message |
Stuart Downi #1 / 6
|
 Visual C++/MFC vs. Visual Basic
Environment: Win95 & MFC 4.2 Our CEO is concerned about the time that is takes the development staff to develop our products. Based on his contact with other CEOs, he has heard that they are developing their products much more quickly using VB. Is anyone aware of any white papers out there that compare using Visual C++/MFC and Visual Basic? We are developing shrink-wrap accounting applications that are essentially database applications. Very generally, our current architecture is to use Access for the back end and Visual C++ for the front end, which has allowed us to craft a UI that is both Win 95 UI compliant and uniquely our own. We spent significant time polishing some of the aspects of our UI conventions and created class libraries to support these conventions. For example, MFCs DDV support provides customizable field validation, but a shortcoming (to us) of it is that the validation occurs when the user presses the OK button, not when the field loses focus. We wanted to be able to validate the field when the user leaves the field for another field in the same data entry collection. In other words, in an MDI context we wanted to allow the user to visit a different MDI window even if the current field was invalid, but if they switched focus to a different control within that MDI window, we would validate the current field before allowing the focus to move. Using C++, we were able to create an edit manager class to accomplish this. This is an example of how we have been able to use the power of C++ to customize in a way that was consistent and reusable. One of my concerns about Visual Basic is that we will lose out in all these areas (power, consistency, reusability). Yes, perhaps we will be able to develop something faster in VB, but will we like the result? Will we be able to maintain it? OK, if I havent bored you to death already, Im interested in opinions and comments of those with experience in both arenas. Quick, before we become a VB shop and I have to quit my job. :) -----------------------------------------------------------
Creative Solutions, Inc.
|
Sun, 07 Mar 1999 03:00:00 GMT |
|
 |
Phil Grisi #2 / 6
|
 Visual C++/MFC vs. Visual Basic
Quote:
>Environment: Win95 & MFC 4.2 >Our CEO is concerned about the time that is takes the development >staff to develop our products. Based on his contact with other CEOs, >he has heard that they are developing their products much more quickly >using VB.
Ask the CEOs to compare the size of the projects they are building faster in VB. Do they map to the kinds of applications your shop builds? I doubt it. Quote: >We are developing shrink-wrap accounting applications that are >essentially database applications. Very generally, our current >architecture is to use Access for the back end and Visual C++ for the >front end, which has allowed us to craft a UI that is both Win 95 UI >compliant and uniquely our own. We spent significant time polishing >some of the aspects of our UI conventions and created class libraries >to support these conventions.
I've done the same kind of thing in SQLWindows, making extensive use of standard OO features like inheritance. Sorry, bud, but you have to check inheritance at the door when enter VB land. However, there are some techniques I'm exploring that lets you preserve your C++ design in VB. It just means a lot more coding and maintenance complexity. Quote: >Using C++, we >were able to create an edit manager class...
You may want to consider turning some of your field classes into OCXs using C++ so you can include them in your VB app. . Quote: >This is an example of how we have been able to use the power of C++ to >customize in a way that was consistent and reusable. One of my >concerns about Visual Basic is that we will lose out in all these >areas (power, consistency, reusability). Yes, perhaps we will be able >to develop something faster in VB, but will we like the result? Will >we be able to maintain it?
Again, you may want to consider keeping part of the team in C++ developing OCXs while the other members of the team stitch them together in VB. Otherwise, consider buying VB plus a bunch of 3rd-party controls and add-ins. Phil Grisier Santa Clara, CA
|
Wed, 10 Mar 1999 03:00:00 GMT |
|
 |
Phil Grisi #3 / 6
|
 Visual C++/MFC vs. Visual Basic
Reposting article removed by rogue canceller. Quote:
>Environment: Win95 & MFC 4.2 >Our CEO is concerned about the time that is takes the development >staff to develop our products. Based on his contact with other CEOs, >he has heard that they are developing their products much more quickly >using VB.
Ask the CEOs to compare the size of the projects they are building faster in VB. Do they map to the kinds of applications your shop builds? I doubt it. Quote: >We are developing shrink-wrap accounting applications that are >essentially database applications. Very generally, our current >architecture is to use Access for the back end and Visual C++ for the >front end, which has allowed us to craft a UI that is both Win 95 UI >compliant and uniquely our own. We spent significant time polishing >some of the aspects of our UI conventions and created class libraries >to support these conventions.
I've done the same kind of thing in SQLWindows, making extensive use of standard OO features like inheritance. Sorry, bud, but you have to check inheritance at the door when enter VB land. However, there are some techniques I'm exploring that lets you preserve your C++ design in VB. It just means a lot more coding and maintenance complexity. Quote: >Using C++, we >were able to create an edit manager class...
You may want to consider turning some of your field classes into OCXs using C++ so you can include them in your VB app. . Quote: >This is an example of how we have been able to use the power of C++ to >customize in a way that was consistent and reusable. One of my >concerns about Visual Basic is that we will lose out in all these >areas (power, consistency, reusability). Yes, perhaps we will be able >to develop something faster in VB, but will we like the result? Will >we be able to maintain it?
Again, you may want to consider keeping part of the team in C++ developing OCXs while the other members of the team stitch them together in VB. Otherwise, consider buying VB plus a bunch of 3rd-party controls and add-ins. Phil Grisier Santa Clara, CA
|
Wed, 10 Mar 1999 03:00:00 GMT |
|
 |
William E. Kem #4 / 6
|
 Visual C++/MFC vs. Visual Basic
:Environment: Win95 & MFC 4.2 : :Our CEO is concerned about the time that is takes the development :staff to develop our products. Based on his contact with other CEOs, :he has heard that they are developing their products much more quickly :using VB. Is anyone aware of any white papers out there that compare :using Visual C++/MFC and Visual Basic? : Not sure of white papers, but in my experience, the learning curve for MFC is much greater, but the actual application development time for experienced coders is only slightly longer. :We are developing shrink-wrap accounting applications that are :essentially database applications. Very generally, our current :architecture is to use Access for the back end and Visual C++ for the :front end, which has allowed us to craft a UI that is both Win 95 UI :compliant and uniquely our own. We spent significant time polishing :some of the aspects of our UI conventions and created class libraries :to support these conventions. : :For example, MFCs DDV support provides customizable field validation, :but a shortcoming (to us) of it is that the validation occurs when the :user presses the OK button, not when the field loses focus. We wanted :to be able to validate the field when the user leaves the field for :another field in the same data entry collection. In other words, in :an MDI context we wanted to allow the user to visit a different MDI :window even if the current field was invalid, but if they switched :focus to a different control within that MDI window, we would validate :the current field before allowing the focus to move. Using C++, we :were able to create an edit manager class to accomplish this. : The validation occurs whenever you ask it to. So simply ask it to when the control loses focus. HOWEVER... I do not recommend this. Focus change messages are tricky messages to code for. You have NO control over when these messages occur, and can occur because of events out of the control of not only the programmer, but also the end user. For example... a network message is broadcast and pops up on the screen. Handling this can be quite difficult and very frustrating for the user. :This is an example of how we have been able to use the power of C++ to :customize in a way that was consistent and reusable. One of my :concerns about Visual Basic is that we will lose out in all these :areas (power, consistency, reusability). Yes, perhaps we will be able :to develop something faster in VB, but will we like the result? Will :we be able to maintain it? : In my opinion: no. VB coding is black box coding. You've got to take a lot on faith. :OK, if I havent bored you to death already, Im interested in :opinions and comments of those with experience in both arenas. Quick, :before we become a VB shop and I have to quit my job. :) : :-----------------------------------------------------------
:Creative Solutions, Inc. : ----- William E. Kempf : http://www.novia.net/~srwillrd
Knight of the Ascii Table :
|
Sat, 13 Mar 1999 03:00:00 GMT |
|
 |
Stuart Downi #5 / 6
|
 Visual C++/MFC vs. Visual Basic
Quote:
>:We are developing shrink-wrap accounting applications that are >:essentially database applications. Very generally, our current >:architecture is to use Access for the back end and Visual C++ for the >:front end, which has allowed us to craft a UI that is both Win 95 UI >:compliant and uniquely our own. We spent significant time polishing >:some of the aspects of our UI conventions and created class libraries >:to support these conventions. >: >:For example, MFCs DDV support provides customizable field validation, >:but a shortcoming (to us) of it is that the validation occurs when the >:user presses the OK button, not when the field loses focus. We wanted >:to be able to validate the field when the user leaves the field for >:another field in the same data entry collection. In other words, in >:an MDI context we wanted to allow the user to visit a different MDI >:window even if the current field was invalid, but if they switched >:focus to a different control within that MDI window, we would validate >:the current field before allowing the focus to move. Using C++, we >:were able to create an edit manager class to accomplish this. >: >The validation occurs whenever you ask it to. So simply ask it to >when the control loses focus. HOWEVER... I do not recommend this. >Focus change messages are tricky messages to code for. You have NO >control over when these messages occur, and can occur because of >events out of the control of not only the programmer, but also the end >user. For example... a network message is broadcast and pops up on >the screen. Handling this can be quite difficult and very frustrating >for the user.
You are right. This was VERY tricky. I guess that was the point I was trying to make. We were able to customize the default MFC behavior in a way that I'm concerned wouldn't even be a possibility in VB. We hope to come up with a small pilot project that we can use to gain enough experience with VB to be in a better position to evaluate it for our needs. -----------------------------------------------------------
Creative Solutions, Inc.
|
Sun, 14 Mar 1999 03:00:00 GMT |
|
 |
Chris Morr #6 / 6
|
 Visual C++/MFC vs. Visual Basic
Quote:
>Environment: Win95 & MFC 4.2 >Our CEO is concerned about the time that is takes the development >staff to develop our products. Based on his contact with other CEOs, >he has heard that they are developing their products much more quickly >using VB. >We are developing shrink-wrap accounting applications that are >essentially database applications. Very generally, our current >architecture is to use Access for the back end and Visual C++ for the >front end, which has allowed us to craft a UI that is both Win 95 UI >compliant and uniquely our own. We spent significant time polishing >some of the aspects of our UI conventions and created class libraries >to support these conventions. >Using C++, we were able to create an edit manager class... >This is an example of how we have been able to use the power of C++ to >customize in a way that was consistent and reusable. One of my >concerns about Visual Basic is that we will lose out in all these >areas (power, consistency, reusability). Yes, perhaps we will be able >to develop something faster in VB, but will we like the result? Will >we be able to maintain it?
Have you ever heard of Borland's Delphi? It is object oriented, fully visual and I have heard that you can design the interface visually and link it to C++ code. The best of both worlds... People I have talked to about Visual Basic says it's clumsy to work with compared to Delphi. I use it at work, we have written several LARGE applications in it and have been extremely happy with the time it takes to design the interface. One person is working on a project now where he has written a DLL in Borland C++ and calls it from Delphi. The Delphi de{*filter*} even steps into the DLL! Anyway, that's my two cents worth...Hope it helps. Chris Morris
|
Wed, 17 Mar 1999 03:00:00 GMT |
|
|
|