Button missing BorderColor and BorderStyle?

[Peter Oliphant]

I'm writing a program using MS VC++ 2005 Express [managed (CLI)], and I use
the Button class.

For the most part, this is working fine. I can set BackColor, ForeColor,
Width, Height, etc. But if I try to us either 'BorderColor' or 'BorderStyle'
it says they aren't properties of Button!

However, it says here that is does have both properties:

ms-help://MS.VSExpressCC.v80/MS.NETFramework.v20.en/cpref16/html/P_System_Web_UI_WebControls_WebControl_BorderColor.htm

This code therefore does not work:

Button^ button = gcnew Button() ;
button->BorderColor = Color::White ; // error

The second line gets this error:

error C2039: 'BorderColor' : is not a member of
'System::Windows::Forms::Button'


How come it doesn't recognize BorderColor or BorderStyle? Are there more
than one Button classes using the same name somehow?

[==Peter==]

 

[Ben Voigt [C++ MVP]]

I'm writing a program using MS VC++ 2005 Express [managed (CLI)], and I
use the Button class.

For the most part, this is working fine. I can set BackColor, ForeColor,
Width, Height, etc. But if I try to us either 'BorderColor' or
'BorderStyle' it says they aren't properties of Button!

However, it says here that is does have both properties:

ms-help://MS.VSExpressCC.v80/MS.NETFramework.v20.en/cpref16/html/P_System_Web_UI_WebControls_WebControl_BorderColor.htm

This code therefore does not work:

Button^ button = gcnew Button() ;
button->BorderColor = Color::White ; // error

The second line gets this error:

error C2039: 'BorderColor' : is not a member of
'System::Windows::Forms::Button'


How come it doesn't recognize BorderColor or BorderStyle? Are there more
than one Button classes using the same name somehow?

Yes. You're conflating System.Web.UI.WebControls with Windows.Forms.
Please be sure to use the documentation appropriate for your application.
The ASP.NET buttons apparently have BorderColor and BorderStyle (expected,
because HTML buttons have these). Windows Forms buttons have other
properties, like FlatStyle, which may give you the same effect.

http://msdn2.microsoft.com/en-us/library/system.windows.forms.button(vs.80).aspx

[==Peter==]

 

[Peter Oliphant]

Thanks, Ben!

Don't you think when I highlight 'Button' in my program and hit the 'F1'-key
it should then go to the CORRECT Button definition in MSDN? I would prefer
it NOT go anywhere than to the WRONG definition (which it does). The VS GUI
is obviously as confused as I am, and now I realize I can't trust it for
realiable help, since it's prone to linking me to incorrect information. And
since in this case since there is another Button class that has the same
name and similar functionality, how can I tell the difference?

Or wouldn't it possibly be a good idea to not give DIFFERENT classes
described in MSDN the SAME name?

Or possibly in MSDN when there is a name ambiguity to put up a BIG WARNING
to that affect on such MSDN pages, with a link to the other classes with the
same name that are described in MSDN as well as HOW they differ (such as the
at least two different versions of Button)?

This is not the first time I've run into MSDN having the same name for
different versions of a class with similar but not identical behavior (which
makes it worse, since, like me in this case, it can take a while to realize
you are using the wrong version).

I'd say 99.99999% of the time I have any problems with VC++ .NET it's
becuase the documentation is so poor or hard to find or there are no
tutorials or no sample code or, as I've been saying, even DIS-INFORMATION in
MSDN if you go to the wrong location describing something with the same
name. What I'm saying is, MS languages would be great if the SUPPORT for
them wasn't so bad. We developers shouldn't have to go to a newsgroup to
learn how to use features if they were well-documented in the first place
(e.g., tutorials and/or sample code).

At least this VC C++ newsgroup is pretty responsive (thank gawd). Don't even
get me started about how it has been taking me WEEKS to find information on
MS SAPI (for which apparently there is no newsgroup for) for a speech
recognition project...

[==Peter==]

I'm writing a program using MS VC++ 2005 Express [managed (CLI)], and I
use the Button class.

For the most part, this is working fine. I can set BackColor, ForeColor,
Width, Height, etc. But if I try to us either 'BorderColor' or
'BorderStyle' it says they aren't properties of Button!

However, it says here that is does have both properties:

ms-help://MS.VSExpressCC.v80/MS.NETFramework.v20.en/cpref16/html/P_System_Web_UI_WebControls_WebControl_BorderColor.htm

This code therefore does not work:

Button^ button = gcnew Button() ;
button->BorderColor = Color::White ; // error

The second line gets this error:

error C2039: 'BorderColor' : is not a member of
'System::Windows::Forms::Button'


How come it doesn't recognize BorderColor or BorderStyle? Are there more
than one Button classes using the same name somehow?

Yes. You're conflating System.Web.UI.WebControls with Windows.Forms.
Please be sure to use the documentation appropriate for your application.
The ASP.NET buttons apparently have BorderColor and BorderStyle (expected,
because HTML buttons have these). Windows Forms buttons have other
properties, like FlatStyle, which may give you the same effect.

http://msdn2.microsoft.com/en-us/library/system.windows.forms.button(vs.80).aspx

[==Peter==]

 

[Peter Oliphant]

BTW, it now works (I use FlatStyle as you suggested), and the link was very
helpful. Thanks again! : )

[==Peter==]

I'm writing a program using MS VC++ 2005 Express [managed (CLI)], and I
use the Button class.

For the most part, this is working fine. I can set BackColor, ForeColor,
Width, Height, etc. But if I try to us either 'BorderColor' or
'BorderStyle' it says they aren't properties of Button!

However, it says here that is does have both properties:

ms-help://MS.VSExpressCC.v80/MS.NETFramework.v20.en/cpref16/html/P_System_Web_UI_WebControls_WebControl_BorderColor.htm

This code therefore does not work:

Button^ button = gcnew Button() ;
button->BorderColor = Color::White ; // error

The second line gets this error:

error C2039: 'BorderColor' : is not a member of
'System::Windows::Forms::Button'


How come it doesn't recognize BorderColor or BorderStyle? Are there more
than one Button classes using the same name somehow?

Yes. You're conflating System.Web.UI.WebControls with Windows.Forms.
Please be sure to use the documentation appropriate for your application.
The ASP.NET buttons apparently have BorderColor and BorderStyle (expected,
because HTML buttons have these). Windows Forms buttons have other
properties, like FlatStyle, which may give you the same effect.

http://msdn2.microsoft.com/en-us/library/system.windows.forms.button(vs.80).aspx

[==Peter==]

 

[Ben Voigt [C++ MVP]]

Thanks, Ben!

Don't you think when I highlight 'Button' in my program and hit the
'F1'-key it should then go to the CORRECT Button definition in MSDN? I
would prefer it NOT go anywhere than to the WRONG definition (which it
does). The VS GUI is obviously as confused as I am, and now I realize I
can't trust it for realiable help, since it's prone to linking me to
incorrect information. And since in this case since there is another
Button class that has the same name and similar functionality, how can I
tell the difference?

I would agree that it *should*. Was the code compilable at the time? The
only way Visual Studio can know which "Button" class you are using is by
performing a compile of the code (doesn't need to optimize or generate MSIL,
but does need most of a compiler). If you have errors in the code then
Studio hasn't much hope of finding which Button you meant.

I always get an extra pane at the bottom of my help window showing all the
matching topics. Does activating the "Index Results" window (available on
the Help menu inside Help) show you the other topics?

Or wouldn't it possibly be a good idea to not give DIFFERENT classes
described in MSDN the SAME name?

Usually yes, but with a name like Button... you're going to get naming
conflicts. That's the whole point of having namespaces.