|
mad1982 wrote: do not send any spam because i allready get to much right now.
Don't put your email address in the message, then.
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
Please don't send money to my Paypal account - I have too much money allready
Paypal account : paypal@malcolm.smart.com
(worth a try...)
"More functions should disregard input values and just return 12. It would make life easier." - comment posted on WTF
|
|
|
|
|
|
You'd be much better off asking this on a game centric website.
AS a note, make sure they are C# friendly though ... alot of game developers are very chauvinistic about c++ 
|
|
|
|
|
A good web site I use is www.gamedev.net a very good site with lots of resources and a very active forum
Ta
Paul
Help, Urgent, Need answers Urgent, Quick Help arggggghhhhhhhhhh
|
|
|
|
|
Ok, I've built a custom server control based on an existing control the GridView. However, when I register the *.dll to my Web Page project and use it's functionality, it also gives the default GridView options. I want to restrict these defaults and only allow developers to use my custom public methods I've written to it. How do I go about this?
If more details needed please let me know.
Thanks all in advance.
|
|
|
|
|
If your control inherits from GridView, you should expect to inherit the members of the GridView class. You could consider redefining the inherited members using the 'new' method modifier. Alternatively, you could design your control to encapsulate an instance of the GridView control rather than inheriting from it.
Paul
|
|
|
|
|
Thanks for your feedback Paul.
My code somewhat looks like the following within the namespace:
public class MyServerControl : GridView
{
}
My guess would be changing to the following:
public class MyServerControl : WebControl()
{
//NEED SOMETHING HERE TO MAKE "WebControl" to GridView to redefine.
}
Paul or anyone have thoughts?
|
|
|
|
|
WebControl is a good choice to inherit from if you are developing a control with a user interface. You could encapsulate an instance of a GridView control within your control and only expose the properties that you want consumers of your control to access. These properties could then be used to update the state of your encapsulated GridView control. If you override the Render() on your control, you could then render out the GridView control as your control's user interface.
Paul
|
|
|
|
|
Right on Paul. Your thoughts have definately helped. What I've done was use a "PlaceHolder" then have a method that will add controls to it on call. I think this is more dynamic and flexible. I bet there are many ways to do this, but hey this works. 
|
|
|
|
|
Hi,
Can anyone make a quick example that shows how to countdown in time? I want to run a function every minute, so it needs to countdown in the background with no textoutput (where it shows the timer).
Thanks.
|
|
|
|
|
|
Hi,
you would use some kind of timer:
- if the periodic function is lightweight and needs to access the GUI (assuming
a Windows app), the easiest solution is a Windows.Forms.Timer
- if the periodic function takes more than say 50 msec, you should use
a Timers.Timer or Threading.Timer; it will execute its handler on a different
thread, hence not blocking the GUI. But if it also needs to access the GUI,
you will have to use the Control.InvokeRequired and Control.Invoke() pattern.
Just one example.
somewhere, maybe in the form's constructor:
Windows.Forms.Timer timer=new Windows.Forms.Timer();
timer.Interval=60000;
timer.Tick+=new EventHandler(timer_Tick);
timer.Start();
And this is the method that will execute periodically; you may not use
the parameters, but they must be there anyway.
void timer_Tick(object sender, EventArgs e) {
Console.WriteLine("whatever");
myTextBox.Text=DateTime.Now.ToString("hh:mm:ss");
}
Warning: most timers vanish (i.e. could be garbage collected) as soon as
you stop them, unless of course you keep a reference to it (e.g. as a class member,
rather than a local variable).
|
|
|
|
|
For the very precise intervals you can creat a worker thread and with the help of Thread.Sleep() function you can do the countdown.
Manoj
Never Gives up
|
|
|
|
|
Thanks to all Works perfect!
|
|
|
|
|
Hi there
I'm relatively new to C#, so please exuse me if this seems n00bish...
But, when referencing a control on a form is it good practice to include "this.", for example:
textBox1.Text = "Hello World";
-or-
this.textBox1.Text = "Hello World";
I ask this because I haven't seen any convention mentioned anywhere, or consistency. Does it even matter? Also, I note that within a contructor for a class, you might use the same variable name for a parsed variable as you would for the private local variable, eg:
public class fclsHelloWorld: Form
{
private bool sayHelloWorld;
public fclsHelloWorld ( bool args, bool sayHelloWorld )
{
InitializeComponent ();
this.sayHelloWorld = sayHelloWorld;
}
...
}
So, it's obviously needed to specify which variable you're referring to.
Thanks in advance 
Cheers
Poolee
... pessimists are rarely disappointed ...
|
|
|
|
|
I almost never use this, unless it is the constructor case you mentioned.
|
|
|
|
|
In most cases, I've just seen people use the "this" keyword to trigger intellisense.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
I've seen people use it for intellisense (however, CTRL+J will bring up intellisense without having to type 'this').
Some tools, such as widely-used Resharper tool issues warnings for using 'this' when it's not needed. Since it purely is excess typing and more words to read while reading code, I recommend against using 'this' keyword unless it's warranted (e.g. the constructor example or passing the current class instance into a function).
|
|
|
|
|
Hello,
Poolee wrote: this.sayHelloWorld = sayHelloWorld;
I wouldn't want to see a codeline like this in my project!
There for, I only need "this" when passing an instance to a function. (like Judah pointed out very well)
All the best,
Martin
|
|
|
|
|
Thanks for your reply.
So just to clarify, you would use a differently-named private variable to the passed variable name?
Cheers
Poolee
... pessimists are rarely disappointed ...
|
|
|
|
|
Poolee wrote: So just to clarify, you would use a differently-named private variable to the passed variable name?
Yes!!!!
All the best,
Martin
|
|
|
|
|
I think it is a matter of style. I don't have anything against using this when it is superflous and I won't go around changing anyone's code that uses it.
My personal style is to not use this unless it is needed or unless it helps code readability.
Upcoming events:
* Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ...
"I wouldn't say boo to a goose. I'm not a coward, I just realise that it would be largely pointless."
My website
|
|
|
|
|
You specify this to tell the compiler or yourself it's about this class, not somewhere else.
I almost only use it in the constructor example you mentioned, and very occasionally when eg I do something with a form like this.Close(); or if(this.DialogResult == DialogResult.OK)...
One of my colleagues uses this to point out variables that are defined globally in the class. Please, for the sake of your dear fellow colleagues, avoid this ..... in this case  !
V.
No hurries, no worries
|
|
|
|
|
V. wrote: One of my colleagues uses this to point out variables that are defined globally in the class. Please, for the sake of your dear fellow colleagues, avoid this ..... in this case
I find it more readable when this is used like this :P
It's all down to style and personal preference.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
