|
|
When u write:
class MyClass {<br />
}
it's really:
class MyClass : object {<br />
}
Thats understood.
now for example:
MyClass myclass = new MyClass();
now
(myclass.GetType() == typeof(MyClass)) = true
Similarly:
object myobject = new object;
now
(myobject.GetType() == typeof(object)) = true
Hope u understand...I wouldnt have sleepless nites though 
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info. 
|
|
|
|
|
|
That will throw an compiler error as it is a duplicate definition.
You can however do this:
class MyClass : SomeOtherNamespace.MyClass {<br />
}
as the context for each MyClass is different
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
|
OK I think I know what u are getting to, the answer lies in inheritance.
class Base : object //this is not necessary as u know
{
public string Name {get;set}
}
Now Base class will inherit (iow have) all of it's base class's (object or System.Object, same thing) public and protected members.
class MyClass : Base
{
public int Value {get;set;}
public void DoStuff();
}
Now MyClass will get all of Base's public and protected methods, but remember Base has inherited some members from object as well, so it gets those as well.
It can get very confusing, I know. Designing a good class hierarchy takes time, only certain aspects might be affected at each level, but in the end all the inherited properties will be "visible" from top (most specialized class) to bottom (object). Look at the Form class and see how many members are actually inherited.
So in the end there can be only one! The same object class is used everywhere in .NET.
Hope this helps
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
never mind, you didnt understand what i said, my qq has been aswered in a later post by someone else. [look below]
BTW what i said was, from wot u said, i thought it was declared by
class objectBase : object {}
class object : objectBase {}
but never mind.
|
|
|
|
|
its not of any type - its a class with no parent.
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
hi I have three Webforms in one page (with frames)
when one button on one of them is clicked a page
should be load in the other frame, I gotta do it in
codebehind (I know the old HTML way)
Mazy
"If I go crazy then will you still
Call me Superman
If I’m alive and well, will you be
There holding my hand
I’ll keep you by my side with
My superhuman might
Kryptonite"Kryptonite-3 Doors Down
|
|
|
|
|
Hi all,
What is the command in .NET Framework, to do Shutdown, Restart and Logout from Windows?
Thanks for the help..
Eka
|
|
|
|
|
I made a invisible control,and add a ico to it (by [[ToolboxBitmapAttribute("iconfile.ico")])
then I set the ico file as embed resource。at MSDN it said you can use projectname.filename.ext to access the resource embeded in a dll.
but I use [ToolboxBitmapAttribute(typeof(projectname.iconfile.ico))]or
[ToolboxBitmapAttribute("projectname.iconfile.ico")] ,it also can not access the icofile.
What shall I do????
lost my way
|
|
|
|
|
I don't believe you can use icon files for the ToolboxBitmap 
Add the bitmap to the project, open up the properties panel (if it isn't already open) and change the Build Type for the icon to "Embedded Resource". The bitmap filename also needs to be named the same as the control, without the default namespace prepended.
Now change the ToolboxBitmap attribute to read.
[ToolboxBitmap(typeof(MyControl))] where MyControl is the name of the control.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Thank you very much!It works well now.
And useing ToolBoxBitmapAttribute really can load a ico file,but it is useless by use typeof(MyControl);bitmap is exact.
Thanks again.;)
This is a good place to discuss programing technique.
lost my way
|
|
|
|
|
Any good ideas of what to buy in regard to writing custom control?
I'm looking for a book that explains the ins and outs of Control class,
like when to override createParams, WndProc.
I also saw a few books:
.NET Windows Forms Custom Controls
by Richard L. Weeks, Richard L Weeks
GDI+ Programming: Creating Custom Controls Using C#
by Eric White, Chris Garrett (Contributor)
are they good??
|
|
|
|
|
|
I have one at hand.
I agree with you that this one is a comprehensive guide on GDI+ and how to use these controls. But not in depth when it comes to writing our own controls.
|
|
|
|
|
I cant remember the books name now, but its on the WROX website (www.wrox.com)
Best is the source code for the book is available on the site (no need to even register) and the examples therein is so well written that you dont even need the book.
Hope you find it usefull
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
I have both the Petzold book (Programming Microsoft Windows with C#) and the Eric White book (GDI+ Programming: Creating Custom Controls Using C#).
The Petzold book is not aimed at custom controls, and although it is a good read it is probably not what you want. The reason I own both books is because the Petzold book has more GDI+ details, especially in regard to drawing paths, working with Beziers and other splines etc..
The Eric White book has three chapters directly relevant to designing custom controls. These are entitled:
An Overview of GDI+ and Custom Controls
Architecture and Design of Windows Forms Custom Controls
Design Time Support
However much of the book is slanted towards the design of custom controls. I would not like to be without either book, but if you can only get one, go with the Eric White book because it seems to best match your needs.
You should probably not override WndProc until you have explored other options. For example, you don't have to override WndProc to create a custom shape for your form or control. Instead you need only set the Region property of the form or control. Of course there are times you may really need to override WndProc. Just don't rush to it!
I live in the hope that sticking to a higher layer abstraction, which is what GDI+ really is, might someday make my life easier when it comes to porting code. But the reality is somewhat different!
I cannot comment on the .NET Windows Forms Custom Controls. I have not seen it.
Only change is constant
|
|
|
|
|
How can I make a control in C# like
http://www.codeproject.com/treectrl/newtreelistcode.asp .
Is it possible to link with database ? When I change data in database this control will show the right thing in the same time ?
Thx.
|
|
|
|
|
candan wrote:
How can I make a control in C# like
http://www.codeproject.com/treectrl/newtreelistcode.asp
I would suggest to build an ActiveX wrapper on top of this win32 control. Then all what's left to do is drop it onto your form.
Doing owner drawing at the C# level is a mess, and many things are not possible. In fact, you'll end doing the same that some developers have been posting in the C# control section of codeproject : controls that do 100% win32 interop,
candan wrote:
Is it possible to link with database ? When I change data in database this control will show the right thing in the same time ?
That's your application logic.
And I swallow a small raisin.
|
|
|
|
|
I sitting here coding along when I release I need to be able to unsubscribe to an event I just subscribed to. So I go to my books, and none of them talk about it, they show you how to subscribe to an event but not unsubscribe to it. So I do an internet search I get nothing. I do a Code Project search and I get nothing. I have a hard time believing that I am the first person who needed to know how to unsubscribe to an event in C#. In Java it was always straight forward with add and remove events tied to the object want to know about the event.
Well here is the way everyone teaches to subscribe to and event:
<pre lang="cs"> OnEvent += new EventHandler(HandlerMethod);</pre>So I would assume that to unsubscribe you would do the reverse:<br />
<code lang="cs"><pre lang="cs"> OnEvent -= handleToEventHandlerObject;</pre>However since this the EventHandler was created anonymously you do not have a handle/reference to it. <br />
<br />
So my next assumption would be this:<br />
<code lang="cs"><pre lang="cs"> EventHandler handleToEventHandler = new EventHandler(HandlerMethod);
/ ... /
OnEvent += handleToEventHandler;
/ ... /
OnEvent -= handleToEventHandler;</pre>Does this sound right. I have not tried it yet, since I was hoping there was a better way, and also I wanted to do some gripping about C#'s auto-magical delegate system for handling events. Which have created problems, at least for me. Mainly when you want to wrap another object, and provide pass through event handling, you can not. Your wrapper class has to register for the events, and then provide its own delegates for handling it. Also when you want to do something like subscribe and unsubscribe to an event it seams like subscribing is no big deal, but unsubscribing seams like it comes with a little extra (more like annoying) work.<br />
<br />
Just to say it, I think the Java event handling system was far better and more flexible. There was nothing going on auto-magically under the covers. You new there was a Collection holding all the classes who subscribed, and that they are required to have a method signature that you will call when it is thrown. There were standardized add/remove methods that all you have to do is pass the object who subscribed which was 99% of the 'this' keyword. You always hand a handle to the object you used to subscribe to it with.<br />
<br />
Well that’s it with my gripping about C# events. If someone can confirm that above is the correct and only way to subscribe and unsubscribe to an event, or provide a alternative solution.<br />
<br />
:laugh: Thanks for putting up with me. ;P<br />
<br />
Aalst
|
|
|
|
|
|
Thanks, and as hard as it was to believe, and even after reading the related part in the tutorial you linked to, I believe it only because I know how stupid Microsoft can be.
Is anyone with me here on this? 
You create an EventHandler object and add it to the an event
to subscribe to this event by means of the += operation. Then
to unsubscribe to this event you have to create another,
unrelated, EventHandler object and subtract it from the event
by means of the -= operation. So you are saying I want to
remove an object that is not there, and it actually removes the
object you intended even though you did not reference this
object at all. (I know it must do it via the method passed as
an argument). This is the most illogical and idiotic thing. If
this is not auto-magical behavior I don't know what is. Man, Microsoft went off the deep end on that one. No wonder no publisher prints this, everyone would think it was a type-o. 
As for using event properties to "simulate" pass-through, that looks like more overhead than the way I described. The method I mention also "simulates" pass-through behavior. Regardless, the point is that you cannot actually do any pass-through of event's short of some complicated reflection. All because Microsoft has a few screws loose.
Don't get me wrong, I complain and grip this much about Java and C++ all the time. I am an Equal Opportunity Gripper (EOG).
C# is new, so I have some catching up to do.
Adios,
Aalst
**There is no perfect language
**There is no perfect language
**There is no perfect language
**There is no perfect language
**There is no perfect language
**There is no perfect language
**There is no perfect language
**There is no perfect language
**There is no perfect language
**There is no perfect language
|
|
|
|
|
All they've done is run into the same problem you were griping about in the first place and come up with an easy-to-use (if a little auto-magical) solution, now you're griping about that .
The basic idea is that creating the EventHandler object creates enough information for either += or -= to operate, so it's easy enough to understand how it works.
You're not far wrong about pass-through behavior, but the point is there are several ways to achieve it, depending on the purpose.
For example, another way to achieve it is to make the object containing the event public and "handle" it an extra level up.
ie.
this.MyPassThroughClass.MyEventingClass.MyEvent += new EventHandler...
Paul
|
|
|
|
|
I am not clear on the problem I was gripping about that is the same problem "they" ran into.
Because if a solution is logical, I would only grip about it's extra steps or complexity over a simpler solution. You may be talking about the example I gave in the original post of how I thought it may work, and how I gripped about it have extra steps. If it was the solution it would have been at least a logical solution.
They could have done away with EventHanlders all together, and just have the event use the += operation on the method directly, and -= on the method directly.
public event OnEvent(object, EventArgs);
/ ... /
private void eventHandler(object sender, EventArgs e) { / ... / }
/ ... /
OnEvent += eventHandler;
/ ... /
OnEvent -= eventHandler;
It gains the exact same results with out all the HandlerObjects in the framework, and at least makes more logical sense as to how to use it. I still have not seen anything better and more robust that the way Java handles events.
Regardless its very easy to go around and around on subjects like these. Since nothing we can say can change the fact that the way it is, is the way it is. I easily adjust to stupid and illogical things, all programming languages have there faults.
It is my opinion we are kick the crap out of a dead horse here, I would recommend we just leave it be that no matter how much justification is provided I will not accept the fact that it is the way it is, I will just have to deal with it, and that no matter how much I grip about it and say how much it sucks, and this way or that way is better it will not change the fact that that way or this will will never come to be and that I have to deal with it.
Aalst
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Email: 