By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,309 Members | 1,452 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,309 IT Pros & Developers. It's quick & easy.

How I can hide a public property in Visual ?

P: n/a
Hi

I define a public property in a new form and I can see this property in
table of Properties in Visual. How I can hide this property to see only in
code ?

Thank's Boniek
Nov 16 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Hi Boniek,
Hi

I define a public property in a new form and I can see this property in
table of Properties in Visual. How I can hide this property to see only in
code ?

Thank's Boniek


Add BrowsableAttribute, and set its value to false.

e.g.:

[Browsable(false)]
public bool MyBoolProperty {
get {
//
}
}

Cheers!

Marcin
Nov 16 '05 #2

P: n/a
> > Hi

I define a public property in a new form and I can see this property in
table of Properties in Visual. How I can hide this property to see only in code ?

Thank's Boniek


Add BrowsableAttribute, and set its value to false.

e.g.:

[Browsable(false)]
public bool MyBoolProperty {
get {
//
}
}

Cheers!

Marcin


Thank's Marcin
Nov 16 '05 #3

P: n/a
Boniek.

alternate way to hide a property displaying is changing access mode from
"public" to "internal". However, read the documentation of internal before
implementing it becoz it has its own limitations.

Shak.
"Boniek" <mo****@poczta.onet.pl> wrote in message
news:40********@news.home.net.pl...
Hi

I define a public property in a new form and I can see this property in
table of Properties in Visual. How I can hide this property to see only in
code ?

Thank's Boniek

Nov 16 '05 #4

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:<MP************************@msnews.microsoft. com>...

Here's the code fragment of the function. :

private void BlastOff(Mass mass, float dt)
{
Unit unit = mass.Unit;

if (null == unit || ! unit.Enabled)
return;

The stack trace (which I can't seem to find right now) definitely
nails the 'if' statement as the culprit.
Well, what is "unit" in this case? If it overloads the == operator,
that could be the problem. Are you *absolutely* sure it's actually
occurring on this line, rather than near it? Could you post some more
code?
Unit does override the CompareTo() function. By the variable naming
convention of the function, I most likely stole this right out of the
C# docs:
public enum UnitType
{
Apple,
Orange,
Elephant,
}

[XmlAttribute("type")]
public UnitType Type
{
get{return unitType;}
set{unitType=value;}
}
public int CompareTo(object obj)
{
Unit u = (Unit)obj;
if(this.Type == u.Type)
return 0;
else if (this.Type > u.Type)
return 1;
else
return -1;
}

I could see how this may generate a null reference exception, but like
I said, I get the null reference exception randomly. And the unit
object is null pretty much most of the time.

I will note that I'm using the DirectX API. It is using native
interop calls, possibly backing up my memory corruption claim.

While we're at it, I have another null reference exception that makes
no sense. Granted, the DX API may be having some issues of its own.
The setup for this is that I'm accessing an object out of an array
several times. (I own none of the implemenation behind this code, it's
all DirectX calls). 99.99% of the time, no problems. Once, I got this
null reference exception:

Code Frag:
device.TextureState[0].AlphaOperation = TextureOperation.Modulate;
device.TextureState[0].AlphaArgument0 = TextureArgument.Current;
device.TextureState[0].AlphaArgument1 =
TextureArgument.TextureColor;
device.TextureState[0].AlphaArgument2 = TextureArgument.Diffuse;

device.TextureState[0].ColorArgument0 = TextureArgument.Current; //
null reference happens here
device.TextureState[0].ColorArgument1
= TextureArgument.TextureColor;
device.TextureState[0].ColorArgument2 = TextureArgument.Diffuse;
device.TextureState[0].ColorOperation = TextureOperation.Modulate;

Here's the stack trace.

System.NullReferenceException: Object reference not set to an instance
of an object.
at Microsoft.DirectX.Direct3D.TextureStates.get_Textu reState(Int32
index)
at Lib.Rasterizer.MonkeyBusiness.SpriteBegin() in C:\Documents and
Settings\bladieblabla\My
Documents\Project\Rasterizer\MonkeyBusiness.cs:lin e 368
at Lib.Rasterizer.MonkeyBusiness.Draw(Vector2 destination, Int32
frameNumber, Int32 alpha) in C:\Documents and Settings\bladieblabla\My
Documents\Project\Rasterizer\MonkeyBusiness.cs:lin e 394
One thing I notice is that I get these in clusters. When I reboot,
they seem to go away for ahile.

My major problem is that I get these, and I can't find the root cause.
In C++, I would be looking for that stray pointer. C#, what could
have a stray pointer?


By the way, I'd suggest writing tests in the more natural way of

if (unit==null || !unit.Enabled)

by the way - I suspect I'm not alone in finding this considerably
easier to use. The problem of accidental assignment is gone in C#
(unless you compare booleans with true and false directly) as it's
stricter about what the type of expression of the "if" statement can
be.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #5

P: n/a
Marshall Belew <mb****@koiosworks.com> wrote:
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote:

Here's the code fragment of the function. :

private void BlastOff(Mass mass, float dt)
{
Unit unit = mass.Unit;

if (null == unit || ! unit.Enabled)
return;

The stack trace (which I can't seem to find right now) definitely
nails the 'if' statement as the culprit.
Hmm... I've seen a few dodgy stack traces before now. I have to
wonder...
Well, what is "unit" in this case? If it overloads the == operator,
that could be the problem. Are you *absolutely* sure it's actually
occurring on this line, rather than near it? Could you post some more
code?


Unit does override the CompareTo() function.


That's not relevant. It's only if it overloads the == operator that
it's relevant.
I will note that I'm using the DirectX API. It is using native
interop calls, possibly backing up my memory corruption claim.
Mmm... possibly.
While we're at it, I have another null reference exception that makes
no sense. Granted, the DX API may be having some issues of its own.
The setup for this is that I'm accessing an object out of an array
several times. (I own none of the implemenation behind this code, it's
all DirectX calls). 99.99% of the time, no problems. Once, I got this
null reference exception:

Code Frag:
device.TextureState[0].AlphaOperation = TextureOperation.Modulate;
<snip>

I'm not familiar enough the DirectX to know - are the TextureStates
meant to be set up for you, or do you have to set them up yourself?
One thing I notice is that I get these in clusters. When I reboot,
they seem to go away for ahile.

My major problem is that I get these, and I can't find the root cause.
In C++, I would be looking for that stray pointer. C#, what could
have a stray pointer?


Well, that depends on exactly what you mean by "stray pointer" - but if
you're doing interop, it could be that you're not pinning something you
should be, perhaps. (If you're using the DirectX SDK, it should be
taking care of that for you though.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.