|
Hello there,
i am developing a custom TabControl.
Have you seen the standard TabControl? From the properties window one can add or remove tabs...
I want to do the same!
Do you know guys if there is a way to achieve my goal? 
Montezuma
|
|
|
|
|
I think these are called verbs. You can also see them by right-clicking on the control in the design window.
You will need to do some reading on Designers. I would tell you more but I've never used them myself.
|
|
|
|
|
Great man,
thanks to your keyword (i would never guess such a biblic name) i have been able to find this article
http://www.codeproject.com/csharp/CustomDesigner.asp
which explains exactly what i want to implement.
Thanks a lot! 
Montezuma
|
|
|
|
|
Hi
I am working on a project that uses switch telephone machine and i want to control this machine by using C# if there is any one can help me please >>>
|
|
|
|
|
How can i found the full path of my IsolatedStorageFile ?
IsolatedStorageFile.GetStore(IsolatedStorageScope.User | IsolatedStorageScope.Assembly | IsolatedStorageScope.Roaming,null,null);
Thanks
-- modified at 9:41 Monday 24th October, 2005
|
|
|
|
|
i've used this stuff more and more times in the same project of my application.
Now i've saved a file and i've tryed to open it with another my application that has another namespace.
Now i can't open it.
How can do a free-namespace serializable class?
|
|
|
|
|
You mean namespace-free, I reckon.
When you serialize an instance of a class, the serialized data is intended to reconstruct an instance of that class, not some other class that happens to have the same name.
Why don't both of the apps use the same namespace and the same class? In other words, maybe you should have a separate library which both apps (the one saving and the one loading) use.
Either that, or you shouldn't be using serialization for this purpose. From what you are saying, it sounds like you may be abusing the idea of serialization and now it is coming back to bite you. 
Matt Gerrans
|
|
|
|
|
Hello,
I have a recursive function call, and I want to cathc the StackOverflowException, in case too many stamps of the function are created. Here is my code to catch the exception:
<br />
public decimal startCalculationOfIRR (double[] intArray, decimal rate)<br />
{<br />
.<br />
.<br />
.<br />
<br />
<br />
try {<br />
rate = this.calcIRR(intArray, MINRATE, MAXRATE, rate, prevTotal, increment, counter);<br />
} catch (StackOverflowException) {<br />
return -0.00m;<br />
}<br />
return rate;<br />
}<br />
<br />
<br />
public decimal calcIRR (double[] intArray, string MINRATE, string MAXRATE, decimal rate, double prevTotal, decimal increment, int counter)<br />
{<br />
.<br />
.<br />
.<br />
<br />
return calcIRR (intArray, MINRATE, MAXRATE, rate, total, increment, counter);<br />
<br />
}<br />
<br />
The problem is that the try catch statement does not seem to catch the error, since the program exists with the StackOverflow Exception. Any ideas?
Thank you
|
|
|
|
|
hi,
catch the exception in the method calcIRR (intArray, MINRATE, MAXRATE, rate, total, increment, counter)
just try this.
i hope this should work for u
Regards,
Pramod
|
|
|
|
|
Catching the exception within the calcIRR function does not work either.
I just don't know what's going on.
Thanks
|
|
|
|
|
then try and use the base Exception class instead of
StackOverFlowException
May be this works
Thanks
pramod
|
|
|
|
|
I already tried to use
catch (Exception), but to no avail. It seems nothing works. It's almost like there is no catch statement at all present.
Thanks
|
|
|
|
|
You really shouldn't be coding like this. When a stack overflow exception occurs, there is no guarantee that any additional code will execute, like catch or finally handlers, for example.
You are much better off using iteration instead of recursion.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
WIth iteration I have to know basically the number of iteration I must perform. Unfortunately here I don't know that. That is why I used the recursive call.
Thank you.
|
|
|
|
|
What he means is that you should terminate your recursion in a controled manner instead of letting it go bonkers. There should be a point where you know you can't go farther. Why not stop there instead of blindly plowing on? Sometimes the stack will die at 100 frames. Sometimes the stack will die at 1000 frames. You can't glean any useful information from StackOverflowException except the execution couldn't allocate stack. Inferring any other meaning to any exception is of dubious logic.
|
|
|
|
|
Where does it give the location of the StackOverflowException?
|
|
|
|
|
The location is random, I even pass the counter to see how many times the function is called. Even then, the number is not always the same. Thy funny thing it was working before, all of a sudden it's not working.
Thank you.
|
|
|
|
|
Well that is the nature of overflow exceptions: they depend on the system state you run in which changes over time (resources like memory comes and goes).
Something else is going on then. Are you getting the exception throw from outside your recursive try/catch block? That means the problem is elswhere (or everywhere). Or more specificially, the try/catch block doesn't fail because it can allocate 99% of the thread's stack space but then something else goes off and does something that requires 2% more.
If this is the case you need either need to place the try/catch block "higher" or rethink your design. I would encourage you to rethink your design since terminating your recursion because you ran out of stack is somewhat abnormal and worst not reproducable.
|
|
|
|
|
Thank you for your input. I will try to rethink some of the steps within the function. Unfortunately, when you are trying to calculate IRR (rate of return), and the function throws an exception (like stack overflow), it does not mean that there is no calculated rate, it's just did not get to the point where it can return the calculated value. I run this function on the array of numbers, which sum reaches into hundreds of millions, and when you trying to calculate the rate of return it sometimes takes 30 iterations, or 100 etc.. That's why I can't really bind myself with iteration limit. Well, I will have to come up with something. Thank you guys anyway it was a great help.
|
|
|
|
|
Have you considered rewritting this using a while loop?
<br />
while (!ExitCondition)<br />
{<br />
}<br />
You should be able to rewrite your recursion into a while loop which wouldn't require an iteration limit at all. It will probably be a little more complicated, but it will avoid your memory problems.
Recursion is good for some (small) problems but you have to be aware that the memory usage can baloon dramatically.
|
|
|
|
|
You simply cannot catch StackOverflowExceptions. When the stack is full, the runtime cannot allocate space for the catch handler, so it won't be run.
If you really need to code like this, create some variable that counts the stack depth and throw a custom exception before the stack if full.
|
|
|
|
|
Do I have to create a stack variable as well?
Something like : Stack myStack = new Stack();
But that means I have to place every output on top of this stack.
If not, what do you mean by counting the depth of the stack?
Thank you.
|
|
|
|
|
Well there are ways in the Diagnostic namespace to look at the stack but I wouldn't recommend doing this at all. As stated by many others, the ability of the CLR to allocate object references depends on the machine's state which is constantly changing.
Beyond that you should heed my warning about inferring extra information in any exception. It would be like inferring that a IOException means a file is bad.
You seriously need to rethink how to calculate rate of return. I wouldn't have done recursion in the first place. Iteration might be a long calculation but at least it is reliable. Your method now will randomly stop and worst report bogus data.
|
|
|
|
|
As Daniel said, you cant catch it. Create a counter and see how deep you are going. Then rethink your algorhitm.
xacc-ide 0.0.99-preview7 now with C#, C, C++, IL, XML, Nemerle, IronPython, Perl, Caml, SML, Ruby, Flex, Yacc, Java, Javascript, Lua, Prolog and Boo highlighting support!
|
|
|
|
|
You can't catch StackOverflowException.
My suggestions:
1. It can be proved that any tail-recursive call can be reduced to a simple "while" loop. It seems to be your case "return calcIRR (..."
2. You're passing a lot of big parameters. Why not passing a reference to a class that contains all this information? This would reduce your stack size.
3. Do you have lots of local variables? If yes, try extracting methods from your code, so your stack size becomes smaller.
I see dead pixels
Yes, even I am blogging now!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
