🚀 go-pugleaf

Jason W. Hinson wrote:

> Here's what you would do in Builder:
> 
> TEdit* myTEdit = new TEdit; // new edit box owned by "this" form
> myEdit->Parent = this;  // edit box sits on this form
> myEdit->Top = 20;  // top position on form in pixels
> myEdit->Left = 100; // left position on form in pixels
> myEdit->Width = 150; // width of edit box in pixels
> myEdit->Font->Color = clHighlight;  // set font color to standard 
> windows highlight for fun
> myEdit->Text = "Type Something Here"; // edit the text inside the edit 
> box
> 
> 
> This to me is very "c++ish" in that you create an instance of a class 
> and then set its properties to edit it.  It may be less Builder-like and 
> more "pure c++ish" if you had to call, for example, 
> myEdit->SetLeft(100)--see comments below--but the same basic logic 
> applies (you create an object and edit it via its member 
> functions/variables). 
> 
> Could some kind soul please write the code to do this set of actions via 
> Visual C++ just so I can see how its done???
> 
> Thanks!!!
> 
> 
> -Jason

Using the MFC library that comes with VC++...

CEdit* myEdit = new CEdit();
CRect rect(left, top, right, bottom);
myEdit->Create(WS_VISIBLE | WS_BORDER, rect, this, IDC_MYEDIT);
myEdit->SetFont(GetFont());
myEdit->SetWindowText("Something");

MFC control objects have almost no member variables.  Instead, numerous 
CWnd functions (like SetFont) are inherited by all of them to get/set 
the properties that are stored within Win32.  MFC does not try to be 
very "C++ish".  Rather, it is for the most part a thin wrapper over the 
Win32 APIs.  It provides the essential interface needed between the C 
language API callbacks and C++ member functions.  You can see a lot of 
it quickly by working through the SCRIBBLE tutorial in the help.

-- 
Scott McPhillips [VC++ MVP]

Jason,

personally I think that the "simply-set-a-member" approach is rather
confusing, and indeed delphish. A single assignment looks as though it is an
atomic operation, but it is in fact calling a cascade of functions... in my
opinion this leads to much less efficient code, because you re-read or
re-set the attributes more often (instead of caching the values). Not only
that - the example you provided suggests that instead of calling 1 function
to set window position, you do 4 "assignments" (which are no doubt
implemented by calling the aforementioned function 4 times!) But, all this
is just my opinion. I think that it's a good thing for you to learn the
WIN32 API or the (more or less thin) MFC wrapper so that in the end you can
use the API more efficiently. In VC++, I think that you have no other choice
anyway :-)

Best Regards,
Filip

"Jason W. Hinson" <hinson@physicsguy.com> p�e v diskusn�m p��sp�vku
news:hinson-6E84C1.18360311112004@news.east.cox.net...
> Hi all...
>
> I'll note up front that I'm copying this to a C++Builder group in case
> anyone there is interested...
>
> Anyway, I've used Borland C++Builder for a while, and now I'm going to
> have to switch to Visual C++.  I took a look at VC++ a bit, and I must
> say it seems a lot less "c++ish" (compared to Borland C++ Builder) in
> its implementation of components.  By that I mean that in Builder you
> can programmatically create a new object (like an Edit box), place it on
> a form as desired, and set its various properties in a way very much
> like you do with any other c++ object.  I was hoping someone could
> provide an example explained below to help me understand how VC++ does
> things compared to Builder.
>
> Say I made a button on a form, and in its OnClick event (or equivalent
> in VC++) I wanted to create a new Edit box, set its location and size,
> and give it some initial text.  Here's what you would do in Builder:
>
> TEdit* myTEdit = new TEdit; // new edit box owned by "this" form
> myEdit->Parent = this;  // edit box sits on this form
> myEdit->Top = 20;  // top position on form in pixels
> myEdit->Left = 100; // left position on form in pixels
> myEdit->Width = 150; // width of edit box in pixels
> myEdit->Font->Color = clHighlight;  // set font color to standard
> windows highlight for fun
> myEdit->Text = "Type Something Here"; // edit the text inside the edit
> box
>
>
> This to me is very "c++ish" in that you create an instance of a class
> and then set its properties to edit it.  It may be less Builder-like and
> more "pure c++ish" if you had to call, for example,
> myEdit->SetLeft(100)--see comments below--but the same basic logic
> applies (you create an object and edit it via its member
> functions/variables).
>
> Could some kind soul please write the code to do this set of actions via
> Visual C++ just so I can see how its done???
>
> Thanks!!!
>
>
> -Jason
>
>
> Added Comments: For those that don't know, the "direct edit" of
> properties in my code example isn't as direct as it may seem.  In
> Builder, Top, Left, Width, etc. are member "properties" which act like
> member variables that you can directly interact with, but behind the
> scenes a "XYZ->Top = 5" command may actually call an internal set
> function, for example.  You the user don't have to know about or worry
> about whether you are directly setting them or whether they are actually
> calling a behind-the-scenes set function that does various checks before
> setting the actual variable.  It's all Delphi stuff, from what I
> understand, and I've seen something like it in VB as well, if I remember
> correctly.  But ANYWAY...

In article <ejgc6HMyEHA.3120@TK2MSFTNGP12.phx.gbl>,
 "Filip Konvicka" 
 <filip.konvicka.remove_this_antispam_token_please@logis.cz> wrote:

> Jason,
> 
> personally I think that the "simply-set-a-member" approach is rather
> confusing, and indeed delphish. A single assignment looks as though it is an
> atomic operation, but it is in fact calling a cascade of functions... in my
> opinion this leads to much less efficient code, because you re-read or
> re-set the attributes more often (instead of caching the values). Not only
> that - the example you provided suggests that instead of calling 1 function
> to set window position, you do 4 "assignments" (which are no doubt
> implemented by calling the aforementioned function 4 times!) But, all this
> is just my opinion. I think that it's a good thing for you to learn the
> WIN32 API or the (more or less thin) MFC wrapper so that in the end you can
> use the API more efficiently. In VC++, I think that you have no other choice
> anyway :-)
> 
> Best Regards,
> Filip
...

Hi, Filip, and thanks for the reply.

I certainly don't have problem with non-delphish approaches or with 
making a single call with multiple variables rather than several 
individual assignments if that's a more efficient way to do things.  I 
just like the idea of everything involving member functions of a given 
object like someComponent->SetPosition(x,y,width,height), for example.

Another poster (who I'll reply to next) showed an example I found quite 
nice in which he created a CEdit object and called its member functions 
to play around with its settings--not too bad from my perspective (at 
least with that example).


-Jason

In article <#eu5gVFyEHA.1452@TK2MSFTNGP11.phx.gbl>,
 "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote:

> Jason W. Hinson wrote:
> 
> > Here's what you would do in Builder:
> > 
> > TEdit* myTEdit = new TEdit; // new edit box owned by "this" form
> > myEdit->Parent = this;  // edit box sits on this form
> > myEdit->Top = 20;  // top position on form in pixels
> > myEdit->Left = 100; // left position on form in pixels
> > myEdit->Width = 150; // width of edit box in pixels
> > myEdit->Font->Color = clHighlight;  // set font color to standard 
> > windows highlight for fun
> > myEdit->Text = "Type Something Here"; // edit the text inside the edit 
> > box
> 
> Using the MFC library that comes with VC++...
> 
> CEdit* myEdit = new CEdit();
> CRect rect(left, top, right, bottom);
> myEdit->Create(WS_VISIBLE | WS_BORDER, rect, this, IDC_MYEDIT);
> myEdit->SetFont(GetFont());
> myEdit->SetWindowText("Something");
> 
> MFC control objects have almost no member variables.  Instead, numerous 
> CWnd functions (like SetFont) are inherited by all of them to get/set 
> the properties that are stored within Win32.  MFC does not try to be 
> very "C++ish".  Rather, it is for the most part a thin wrapper over the 
> Win32 APIs.  It provides the essential interface needed between the C 
> language API callbacks and C++ member functions.  You can see a lot of 
> it quickly by working through the SCRIBBLE tutorial in the help.

Thanks for the reply, Scott...

This is not bad at all.  You created the object directly with a new 
command, and you didn't have to refer to it by its ID number to set its 
variables (though it looks like you did have to give it an ID and make 
sure it was unique).  I'm obviously new to VC++, and I didn't know if 
such actions were the standard way of doing things or not.

Just to note, the visual component library (VCL) in Builder also has a 
lot of inherited members from more basic visual components.  For 
example, obviously every such component needs a Top, Left, Width, and 
Height.  However, obviously some higher-level components need additional 
members specific to their tasks.  For example, a combo box needs a list 
of items to display, so in Builder there is an Items member to the 
TComboBox to which you can add, edit, delete, etc items to be displayed 
in the box.

Another quick question: When you build a CEdit with the VC7 IDE, it is 
given an ID number, if I understand correctly.  Does it not have a name 
as well?  From the VERY limited exposure I've had, it seems you always 
have to get the item (I forget the call) using its ID, then that gives 
you a CWnd pointer (not a CEdit pointer).  So if there are 
CEdit-specific members, how do you access them?  If you create a combo 
box at run-time and want to add members to it, is that something you can 
do once you have a CWnd pointer to it, or is there some other way you 
have to access that type of component?

I also noticed that you could assign an IDE-created CEdit a variable, 
but (again, from my limited exposure) it seemed that this only gave you 
direct edit capabilities for the text in the CEdit rather than pointing 
you to the CEdit object itself.  However, when you create a variable 
for, say,  a button, it seems to point to the button object itself.  If 
I got that right, it sure is confusing.

Another annoyance I noted (and I'd like to think there were an easy way 
around this) is that if I created a button, added some code for its 
click event, then deleted the button, VC7 did not seem to do a good job 
of cleaning up the code that used to go with the button.  In fact, at on 
point it seems it didn't even get rid of some of the creation routines 
for the button, and so it refused to run just because I used the IDE to 
delete a button.  Is that just the way it is, or did I miss something?

Sorry for all the added questions, but I really appreciate any help you 
can offer!  I'll also find the SCRIBBLE tutorial for some added 
experience.


-Jason

Jason W. Hinson wrote:
>>Using the MFC library that comes with VC++...
>>
>>CEdit* myEdit = new CEdit();
>>CRect rect(left, top, right, bottom);
>>myEdit->Create(WS_VISIBLE | WS_BORDER, rect, this, IDC_MYEDIT);
>>myEdit->SetFont(GetFont());
>>myEdit->SetWindowText("Something");
>>
>>MFC control objects have almost no member variables.  Instead, numerous 
>>CWnd functions (like SetFont) are inherited by all of them to get/set 
>>the properties that are stored within Win32.  MFC does not try to be 
>>very "C++ish".  Rather, it is for the most part a thin wrapper over the 
>>Win32 APIs.  It provides the essential interface needed between the C 
>>language API callbacks and C++ member functions.  You can see a lot of 
>>it quickly by working through the SCRIBBLE tutorial in the help.
> 
> 
> Thanks for the reply, Scott...
> 
> This is not bad at all.  You created the object directly with a new 
> command, and you didn't have to refer to it by its ID number to set its 
> variables (though it looks like you did have to give it an ID and make 
> sure it was unique).  I'm obviously new to VC++, and I didn't know if 
> such actions were the standard way of doing things or not.
> 


The unique ID is used by the control to send notifications to the parent 
window.  This is the "standard" way to programmatically create a 
control, but one seldom needs to programmatically create a control.  So 
your question is not really a good context in which to understand the 
basics of MFC controls.


> 
> Another quick question: When you build a CEdit with the VC7 IDE, it is 
> given an ID number, if I understand correctly.  Does it not have a name 
> as well?  From the VERY limited exposure I've had, it seems you always 
> have to get the item (I forget the call) using its ID, then that gives 
> you a CWnd pointer (not a CEdit pointer).  So if there are 
> CEdit-specific members, how do you access them?  If you create a combo 
> box at run-time and want to add members to it, is that something you can 
> do once you have a CWnd pointer to it, or is there some other way you 
> have to access that type of component?
> 


In the code above, the control's "name" is myEdit.  More typically, it 
would be a dialog member variable named m_myEdit so other functions can 
access it.


> I also noticed that you could assign an IDE-created CEdit a variable, 
> but (again, from my limited exposure) it seemed that this only gave you 
> direct edit capabilities for the text in the CEdit rather than pointing 
> you to the CEdit object itself.  However, when you create a variable 
> for, say,  a button, it seems to point to the button object itself.  If 
> I got that right, it sure is confusing.


You are confused, because you actually have a choice between creating 
control member variables and data-exchange member variables. 
Data-exchange member variables (a CString) can only be used for 
getting/setting the text.  Data-exchange variables are a silly little 
marketing pizazz feature that make simple jobs simple, but can do no 
more.  Fluff.

But control member variables (a CEdit) refer to the control object and 
can call all control functions.  They are your workhorses.


> Another annoyance I noted (and I'd like to think there were an easy way 
> around this) is that if I created a button, added some code for its 
> click event, then deleted the button, VC7 did not seem to do a good job 
> of cleaning up the code that used to go with the button.  In fact, at on 
> point it seems it didn't even get rid of some of the creation routines 
> for the button, and so it refused to run just because I used the IDE to 
> delete a button.  Is that just the way it is, or did I miss something?
> 
> Sorry for all the added questions, but I really appreciate any help you 
> can offer!  I'll also find the SCRIBBLE tutorial for some added 
> experience.
> 
> 
> -Jason

That's just the way it is.  This problem will go away when you have more 
that a few days experience.  I can't criticize the IDE for being 
unwilling to delete some of my code.  After all, I may be intending to 
copy that code to a new function!

-- 
Scott McPhillips [VC++ MVP]

"Jason W. Hinson" <hinson@physicsguy.com> wrote in message news:hinson-6E84C1.18360311112004@news.east.cox.net...
> Hi all...
>
> I'll note up front that I'm copying this to a C++Builder group in case
> anyone there is interested...

I think there are ongoing discussions about BCB alternatives
in these newsgroups, but since such discussions are against
the usage terms of the newsgroups it wouldn�t be a good idea
to copy the posts to Builder groups.
Please don�t do that with my comments, i don�t want to
get involved in flame wars. I�ll try to be neutral in my statements.

> Anyway, I've used Borland C++Builder for a while, and now I'm going to
> have to switch to Visual C++.  I took a look at VC++ a bit, and I must
> .....<SNIP>

I know both compilers (VC and BCB) very well and both have their pros and
cons. On the BCB side the pro is surely the C++ RAD. I don�t know why
VC doesn�t have RAD implementations for Win32 like Visual Basic or BCB.
One reason might be that - AFAIK - C++ RAD has been protected by a software
patent - but i�m not sure about this.

Commonly i use a C++ compiler for non GUI services and applications.
For GUI applications i user mixed code - GUI in Basic or Pascal and
the backend in C++.

To your question:

I think you have the following options:

a) Use MFC.
    It�s still supported and will be supported in future versions. Though i would call it
    the "old" framework. But if you want to target the native Win32 platform it�s your
    only option.

    It�s somewhat comparable to OWL from Borland. It�s different - compared to BCB RAD
    and the learning
    curve is much more Win32 based. I�ve written a large application in MFC and
    have been productive after i�ve got used to the framework - and yes it�s more
    C++ ish than BCB.
    AFAIK - a better support for mixed applications using MFC and WinForms
    and later WinFX - Forms has been announced.

b) Use Managed C++ or better C++/CLI

     You�ll need the .NET framework installed to run your applications but managed C++
     gives you the same "comfort" like BCB in developing GUI applications.
     Though i would recommend you to wait for C++/CLI, which is replacing managed C++
     and integrates much better into existing C++ code.
     Just download a beta version of VC 2005 and play around with C++/CLI.

c) Use RAD plugins for VC

    There are some commercial RAD plugins for VC which are comparable to BCB.
    I didn�t use them and so can�t comment on them.
    AFAIK - there are also some open source plugins.

d) Use mixed  code

    You may implement your GUI in another language. C#, Visual Basic, Pascal
    and compile your C++ code as DLL or COM object.
    That�s what i�m mostly doing, when i target the .NET platform.
    Since IMHO C++ is not the best language for RAD (due to compilation time).
    For the Win32 platform this is perhaps not the best (productive) option - depends
    on your application.


Hope that helps.

Andre