|
praveen raghuvanshi wrote: please send me the links, resources and how to prepare for the test
Have you looked at the Microsoft site?
|
|
|
|
|
Friends,
How do i handle the event when window is minimized to the taskbar by clicking the minimize button. Also i want to handle the event when user clicks taskbar button to maximize it. I cant find these events in events window.
Imtiaz
|
|
|
|
|
You have to use the Activated event and in that check the windowstate of the form.
Hope that works for u...
Thanks & Regards,
Pramod
"Everyone is a genius at least once a year"
|
|
|
|
|
hi
this wont work cz it is only fired when the form comes to the active mode from the inactive mode which is not the case here.
|
|
|
|
|
hi,
I think you shuld use the sizeChanged event which is fired whenever the size of the form changes.
in the sizeChanged event you should add the following code
<br />
if(this.Size == this.MaximumSize)<br />
<br />
if(this.Size == this.MinimumSize)<br />
good luck
|
|
|
|
|
The shortest way to do is :
In the Form Resize event check for "FormWindowState".
Eg:
private void Form1_Resize(object sender, System.EventArgs e)
{
if (FormWindowState.Minimized == WindowState)
{
//Your code ..
}
}
Regards,
Bhupi Bhai.
|
|
|
|
|
Hi, I have a MenuItem. There is a "File" MenuItem. "File" has a number of sub-menus (ToolStripMenuItem) which are "New" , "Log-out" and "Exit". The problem is:
I can't find a way how to disable "New" or "Log-out" or "Exit".
using this syntax :
mainFormObj.menuStrip1.Items[0].disable = true;
only disable the "File" menu. But:
using this syntax :
mainFormObj.menuStrip1.Items[0][0].disable = true;
is wrong, and this syntax :
mainFormObj.menuStrip1.Items[0].items[0].disable = true;
is wrong too...
Anyone can find how? and thankx for the help.
-- modified at 0:57 Monday 11th December, 2006
-- modified at 0:58 Monday 11th December, 2006
Enjoy It!
|
|
|
|
|
all you need to do is disable it like you would a regular button
if i have a menuitem that is called "exitToolStripMenuItem" i would just write
exitToolStripMenuItem.Enabled = false;
hope this helps
Don't be overcome by evil, but overcome evil with good
|
|
|
|
|
wow, thanks a lot!
Enjoy It!
|
|
|
|
|
Is it possible to use c# class to vb web project as it is???//
DaVe
|
|
|
|
|
Dawit Bahre wrote: Is it possible to use c# class to vb web project as it is???//
Yes, you have to reference the c# class. Should be pretty straight forward to do. I've done it before, just don't recall the specific off the top of my head right now :->
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
|
|
|
|
|
Is there an "approved" means of recursing an anonymous method, I spent most Sunday reading the C# language spec and other resources, and couldn't see anything. Recursion is one of the more common reasons for me writing a method that is only referenced once, so anonymizing them is attractive.
The only means I could devise was to have the method grab itself off the stack and use MethodBase Invoke to invoke itself eg
new StackTrace().GetFrame(0).GetMethod().Invoke(newTarget)
It works, but it's not pretty - Ta PhilD
|
|
|
|
|
What you're asking is how to invoke anonymous methods outside of the block they were defined in.
I think that's a bad idea. Anonymous methods really aren't designed for this; as you've discovered, it's not easy calling the anonymous method outside of the block that defined the method.
If you absolutely must do this, the easiest way would be to do something like:
System.Reflection.MethodInfo.GetCurrentMethod().Invoke
But that's ugly, not to mention horribly inefficient -- reflection is always much slower than calling code statically. I recommend you don't use anonymous methods this way.
|
|
|
|
|
Is it only a bad idea because the only way to do it is "ugly", or do you have a philosophical objection to the principle - ie if there was a language reserved word such as "self" (sorry SmallTalk) which enabled one to write
"self(arg1, arg2);"
would you still say it was a bad idea?
|
|
|
|
|
No, not only because it is ugly and slow, but also because it is getting beyond the scope of purpose for anonymous methods, IMO. When it comes down to it, anonymous methods aren't meant to be called from anywhere other than the method defining the anonymous method.
|
|
|
|
|
Respectively I have to disagree. Recursion is a natural feature of C# and should be universally available in all methods. A case in point being property accessors, there is nothing to prevent a property accessor method recursing, usually erroneously. And, if an anon method calls itself it is surely, by definition, being done within the scope of the method in which its contained.
rgds phild
|
|
|
|
|
I'm not commenting on whether or not recursion should be allowed in anonymous methods, I'm speculating on the current state of things, which is that anonymous methods are not meant to be directly called from anywhere but the defining function, hence being "anonymous".
If you feel very strongly about making them callable elsewhere, you could give the C# language team some feedback indicating this on sites like connect.microsoft.com, or on the MSDN blogs of the C# language devs, they always welcome feedback.
|
|
|
|
|
Recursion is not just one method calling itself. To introduce a way for a method to anonymously call itself would only be usabale for self recursion, but not for mutual recursion. As it would only allow one special case of recursion, it would not make recursion universally available, it would only make that special case of recursion universally available.
I don't think that it would be a good idea to introduce such a construct, as it would work towards reducing the concept of recursion into just self recursion.
---
b { font-weight: normal; }
|
|
|
|
|
There's nothing to prevent an anon method calling an external method which in turn calls the method in which the anon method resides, which duly invokes the anon method - voila indirect recursion.
as for defining recursion - the existence of multiple instances of the gizmo (method, function, entry point whatever) on the stack - would be where i'd start; it being the means by which my NoRecursion attribute detects undesirable recursions.
Which reminds me that I haven't tried giving an anon method any attributes, yet;)
|
|
|
|
|
pjd1001 wrote: There's nothing to prevent an anon method calling an external method which in turn calls the method in which the anon method resides, which duly invokes the anon method - voila indirect recursion.
No, it's not indirect recursion. The anonymous method only calls a recursive method, it has no part of the recursion itself.
---
It's amazing to see how much work some people will go through just to avoid a little bit of work.
|
|
|
|
|
public someClass
{
public double methodOne(int arg1, List<double> arg2)
{
float number = Math.Sqrt(arg1)
double answer;
arg2.ForEach(delegate{double itemVal)
{
answer += (arg1 < 0) ? extClass.Meth1(this, itemVal, arg1) : extClass.Meth2(this. itemVal, arg1);
}
}
}
public class extClass
{
public double Meth1(someClass mySomeClass, double value, int order)
{
blah blah
double var = mySomeClass.MethodOne(myInt, myListDoubles)
}
}
Surely there is some sort of recursion happening here. I call it indirect recursion - as a result of MethodOne being indirectly recursed then so too is the Action delegate within MethodOne. If I wanted to prevent this I would have MethodOne examine the stack to determine if it, itself, has a prior entry and to react accordingly (it might raise an Exception or simply return zero). If I did not detect recursion and do something about it at the top of the method then I say that MethodOne, including the anon methods therein, are in a state of recursion.
|
|
|
|
|
Yes, there is indirect recursion, and there is an anonymous method, but they are independent of each other. The anonymous method is not an integral part of the recursion. If the Meth1 method would have called the anonymous method, it would have been.
---
It's amazing to see how much work some people will go through just to avoid a little bit of work.
|
|
|
|
|
point taken - how about consequential recursion;P
the stack interrogation method works fine, and I've generalised it into a static method, so the code in the anon method looks reasonable ie within a directory related anon method it would look something like utils.RecurseMe(directory, includeReparsePoints) - RecurseMe's currently only handles void methods, when I need it I'll do a generic version to handle return values.
today public static void RecurseMe(params object[] methodParams);
tomorrow public static void RecurseMe<retType>(params object[] methodParams) where retType:class;
|
|
|
|
|
To define recursion, we must first define recursion!!
All generalizations are wrong, including this one!
(\ /)
(O.o)
(><)
|
|
|
|
|
pjd, did you figure out how to do this? It looks like you can do it by first assigning it to null:
Function f = null;
f = delegate() { f(); }
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
