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.

Phil Grisier
Santa Clara, CA

Reposting article removed by rogue canceller.

Phil Grisier
Santa Clara, CA

: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 :

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.

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