Visual C++/MFC vs. Visual Basic 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 6 post ] 

 Relevant Pages 

1. Visual C++ vs Visual Basic

2. visual basic vs. visual c++ which is better

3. Visual Basic Vs. Visual C++

4. Visual Basic vs. Visual C++

5. visual basic vs visual C++ (performance)

6. Visual Basic VS Visual C++ for project

7. visual basic vs visual c++

8. Visual Basic vs Visual C++

9. Visual Basic vs. Visual C++

10. Visual Basic vs. Visual C++

11. Visual Basic vs. Visual C++

12. Visual Basic vs. Visual C++

 

 
Powered by phpBB® Forum Software