🚀 go-pugleaf

In article <41disc$e3v@toon.ctp.com>, sayer@ctp.com (Stephen D. Ayers) says:
>
>I would like to build an application that utilizes Visual Basic for
>the GUI with Visual C++ business objects. Is it possible to "easily"
>build an application that is a mixture both?  I know it is possible to
>call "C" functions from VB, but is it possible to "call-back" to VB
>code?  We are considering this because some people "feel" that VB
>GUI's are easier to develop. Does the complexity of a mixed
>environment outweighs the benefits?  Are there pitfalls to be avoided?

Unless you are the type of person who likes to mix broken glass
with your Preparation-H you should not be writing Windows front
ends in C++.  You can be much more productive if you use a tool
for front ends, such as VB, rather than dealing directly with the
mess that is Windows or, that mess on top of a mess, MFC.  (Using
OWL is very minor improvement.)

I have had no problems mixing C++ and VB.  I have always let VB drive
the application and have called C(++) DLLs to do heavy processing.

It is possible to call VB from C++ only by sending messages.  This
is not a mechanism that should be encouraged.  If you get into such 
a situation where C(++) has to call VB then you will be geting into 
trouble.  You should design your application so this is a rare 
occurance in your application.

An alternative would be to look at Delphi.  You would get the
Visual environment of VB and some of the OO capabilities of
C++.

John

-----------------------------------------------
VisualWare, Inc.
Custom Visual Basic, C++, and Windows Programming
1675 East Main St, Suite 218
Kent OH 44240
(216) 297-4444
visualware@interramp.com
-----------------------------------------------

John M. Miano (visualware@interramp.com) wrote:
: In article <41disc$e3v@toon.ctp.com>, sayer@ctp.com (Stephen D. Ayers) says:
: >
: >I would like to build an application that utilizes Visual Basic for
: >the GUI with Visual C++ business objects. Is it possible to "easily"
: >build an application that is a mixture both?  I know it is possible to
: >call "C" functions from VB, but is it possible to "call-back" to VB
: >code?  We are considering this because some people "feel" that VB
: >GUI's are easier to develop. Does the complexity of a mixed
: >environment outweighs the benefits?  Are there pitfalls to be avoided?

: Unless you are the type of person who likes to mix broken glass
: with your Preparation-H you should not be writing Windows front
: ends in C++.  You can be much more productive if you use a tool
: for front ends, such as VB, rather than dealing directly with the
: mess that is Windows or, that mess on top of a mess, MFC.  (Using
: OWL is very minor improvement.)

: I have had no problems mixing C++ and VB.  I have always let VB drive
: the application and have called C(++) DLLs to do heavy processing.

: It is possible to call VB from C++ only by sending messages.  This
: is not a mechanism that should be encouraged.  If you get into such 
: a situation where C(++) has to call VB then you will be geting into 
: trouble.  You should design your application so this is a rare 
: occurance in your application.

: An alternative would be to look at Delphi.  You would get the
: Visual environment of VB and some of the OO capabilities of
: C++.

Such a simplistic approach to programming. MFC is an excellent set of 
classes way better than OWL, and the fact you compared MFC and VC++ to VB 
and Delphi puts you in a category of inept programmers who can't grasp 
the future... C++ is complex, but it is the  only thing that is capable 
of developing solid creative apps, and MFC makes architecture much easier 
to work with.  It requires a deeped knowledge of the system and 
programming to work in C++, VB is a high level excuse for non-programmers 
to develop crappy apps...

BTW good luck with VBXs and VB in Win32... And another 
thing, go post to some other newsgroup, this is an MFC one, so go away to 
rec.barney.fan or something!

				Alex
				Give me MFC or give me more MFC...

In article <41fcq7$h23@panix2.panix.com>, achacha@panix.com (Alex Chacha) says:
>
>Such a simplistic approach to programming. MFC is an excellent set of 
>classes way better than OWL, and the fact you compared MFC and VC++ to VB 
>and Delphi puts you in a category of inept programmers who can't grasp 
>the future... C++ is complex, but it is the  only thing that is capable 
>of developing solid creative apps, and MFC makes architecture much easier 
>to work with.  It requires a deeped knowledge of the system and 
>programming to work in C++, VB is a high level excuse for non-programmers 
>to develop crappy apps...
>
>BTW good luck with VBXs and VB in Win32... And another 
>thing, go post to some other newsgroup, this is an MFC one, so go away to 
>rec.barney.fan or something!

>
>                                Alex
>                                Give me MFC or give me more MFC...

From us inept programmers It's easy to tell that you are one of those
Neanderthals for whom playing with C++ is more important
than getting applications done. To say that "C++ is the only thing 
that is capable of developing solid creative apps" is shear ignorance.

BTW this was posted to comp.lang.c++.

Have a nice day, jerk.

John
-----------------------------------------------
VisualWare, Inc.
Custom Visual Basic, C++, and Windows Programming
1675 East Main St, Suite 218
Kent OH 44240
(216) 297-4444
visualware@interramp.com
-----------------------------------------------

In article <41e842$1t3@usenet4.interramp.com>, visualware@interramp.com 
says...
>
>Unless you are the type of person who likes to mix broken glass
>with your Preparation-H you should not be writing Windows front
>ends in C++.  You can be much more productive if you use a tool
>for front ends, such as VB, rather than dealing directly with the
>mess that is Windows or, that mess on top of a mess, MFC.  (Using
>OWL is very minor improvement.)
>
This opion is from a very biased source. I use MFC using application and
class tool building helpers contained within Symantec C++ 7.0 and find that
the user intereface can be built quite easily totally within C++.

When you are done, you have generic portable C++ code (plus probably portable
MFC).  This method of development seems much more likely to be around in a 
year. Depending on other (i.e. non-microsoft) venders frameworks and 
applications my folly with today's volitile market place.

Geoffrey Rubin
grubin@ti.com

In article <41fgei$7ir@usenet1.interramp.com> visualware@interramp.com (John M. Miano) writes:

>In article <41fcq7$h23@panix2.panix.com>, achacha@panix.com (Alex Chacha) 
says:>>
>>Such a simplistic approach to programming. MFC is an excellent set of 
>>classes way better than OWL, and the fact you compared MFC and VC++ to VB 
>>and Delphi puts you in a category of inept programmers who can't grasp 
>>the future... C++ is complex, but it is the  only thing that is capable 
>>of developing solid creative apps, and MFC makes architecture much easier 
>>to work with.  It requires a deeped knowledge of the system and 
>>programming to work in C++, VB is a high level excuse for non-programmers 
>>to develop crappy apps...
>>
>>BTW good luck with VBXs and VB in Win32... And another 
>>thing, go post to some other newsgroup, this is an MFC one, so go away to 
>>rec.barney.fan or something!

>>
>>                                Alex
>>                                Give me MFC or give me more MFC...

>From us inept programmers It's easy to tell that you are one of those
>Neanderthals for whom playing with C++ is more important
>than getting applications done. To say that "C++ is the only thing 
>that is capable of developing solid creative apps" is shear ignorance.

>BTW this was posted to comp.lang.c++.

>Have a nice day, jerk.

>John

John I'm afraid I must FLAME you:
	YOU WERE TO KIND.
	DON'T LET IT HAPPEN AGAIN.

Sorry but I had to.

Scott. 

Hi,

the main problem I've encountered mixing VB and VC++ is that it is impossible
to create standalone .exe programs - the VB *.vbx file must also be shipped
with your application.

BTW, if anybody knows how to get around this, or specifically if there is a
GRID DLL for VC++, then I'd like to know about it.

thanks

Maurice.

mmccourt@cs.tcd.ie

Maurice McCourt (mmccourt@cs.tcd.ie) wrote:
: Hi,

: the main problem I've encountered mixing VB and VC++ is that it is impossible
: to create standalone .exe programs - the VB *.vbx file must also be shipped
: with your application.

: BTW, if anybody knows how to get around this, or specifically if there is a
: GRID DLL for VC++, then I'd like to know about it.

FarPoint has a good grid that can run as a user control with their DLLs, and they also have a wrapper for it to be used in C++ 
MFC/OWL... I had good success with it...


					Alex

In article <41fcq7$h23@panix2.panix.com>,
Alex Chacha <achacha@panix.com> wrote:
>John M. Miano (visualware@interramp.com) wrote:
>: In article <41disc$e3v@toon.ctp.com>, sayer@ctp.com (Stephen D. Ayers) says:
>: >
>: >I would like to build an application that utilizes Visual Basic for
>: >the GUI with Visual C++ business objects. Is it possible to "easily"
>: >build an application that is a mixture both?  I know it is possible to
>: >call "C" functions from VB, but is it possible to "call-back" to VB
>: >code?  We are considering this because some people "feel" that VB
>: >GUI's are easier to develop. Does the complexity of a mixed
>: >environment outweighs the benefits?  Are there pitfalls to be avoided?
>
>: Unless you are the type of person who likes to mix broken glass
>: with your Preparation-H you should not be writing Windows front
>: ends in C++.  You can be much more productive if you use a tool
>: for front ends, such as VB, rather than dealing directly with the
>: mess that is Windows or, that mess on top of a mess, MFC.  (Using
>: OWL is very minor improvement.)
>
>: I have had no problems mixing C++ and VB.  I have always let VB drive
>: the application and have called C(++) DLLs to do heavy processing.
>
>: It is possible to call VB from C++ only by sending messages.  This
>: is not a mechanism that should be encouraged.  If you get into such 
>: a situation where C(++) has to call VB then you will be geting into 
>: trouble.  You should design your application so this is a rare 
>: occurance in your application.
>
>: An alternative would be to look at Delphi.  You would get the
>: Visual environment of VB and some of the OO capabilities of
>: C++.
>
>Such a simplistic approach to programming. MFC is an excellent set of 
>classes way better than OWL, and the fact you compared MFC and VC++ to VB 
>and Delphi puts you in a category of inept programmers who can't grasp 
>the future... C++ is complex, but it is the  only thing that is capable 
>of developing solid creative apps, and MFC makes architecture much easier 
>to work with.  It requires a deeped knowledge of the system and 
>programming to work in C++, VB is a high level excuse for non-programmers 
>to develop crappy apps...
>
>BTW good luck with VBXs and VB in Win32... And another 
>thing, go post to some other newsgroup, this is an MFC one, so go away to 
>rec.barney.fan or something!
>
>				Alex
>				Give me MFC or give me more MFC...
>
>

	I have built several windows apllications that mix VB and C++, VB only, 
C++/MFC only , C using WinSDK as well as 80286 Assembly using MASM 6.11 
mixed with WinSDK. The best applications are usually built using MFC/C++. 
They are very robust have a very sound architecture. MFC takes longer to 
master than VB , but believe it or not once you are past the initial 
learning curve, it's very easy to use it to develop programs quickly. 
As a matter of fact some programs take less time using MFC that they do 
in VB e.g. a minimal word processor can be built in MFC with only about 
10- 20 lines of hand written code, but the same would take a least 100 
lines of code in VB. Of course one option is to mix the two. Microsoft 
has several knowledge base articles on how to write a DLL using C++ 
language. All you have to in addition to what you do using C is to use 
extern "C" before your function definitions. You might want to look on 
CompuServe under the MDKB forum for these articles.
							
						-Asim