Problems in IF condition

Sam

Hi,

I have a strange situation as follows:

There are several (public) NumericUpDown controls.
I wish to multiply the Value of one of the controls by factor 100.
I set the controls limits (min and max) and all other parameters accordingly.
The specific control is identified in an 'if' condition by its Name or Tag.

if (numUpDn.Tag == "09") {
numUpDn.Value = numUpDn.Value * 100;
}

The problem is that the multiplication by 100 is performed twice, resulting in a large number, out of the control max limit.

When running in single step debug, the first time the value is multiplied by 100 and gets its correct value,
but on the next step it does not exit the 'if' condition, but seems to once again run the multiplication, causing out of range exception, with a number
100 times its expected value (total multiplication by 10,000 ).

Furthermore, I found out that if the multiplier number is small enough (like 2 instead of 100), it will loop and multiply until out-of-range exemption will occur.

If I change the Tag inside the assignment {....} BEFORE multiplying, it will pass one time and be OK (the condition is false!).
If I do the same AFTER the multiplication, it will pass twice and will fail.

if (numUpDn.Tag == "09") {
numUpDn.Tag = " " ; numUpDn.Value = numUpDn.Value * 100;
}

Does anyone have an explanation to this phenomenon?
Is my syntax wrong?
Is there a way to force out of the if after execution?
Thanks
sam

5 Replies

Know the answer? Post it — somebody with the same question will find it here.

Vulpes14y ago
Accepted answer
I think that Sam probably put his finger on the cause of this problem when he said: "I assume it is done in an event such as a button click".

If it's being done in the NumericUpown's ValueChanged eventhandler (perhaps a common handler for all your NUDs), then you will get this kind of behaviour because each time you change the value the event immediately fires again until the limit is reached.
0
Sam14y ago
Yes, Vulpes and Sam Hobbs, your were both right.
It is simple:
The If condition is inside a numUpDnValueChanged event method.
Firing the event, changes the value and the event fires again and again....
I am glad I found a workaround....

As Sam Hobbs wrote "Problems such as this often result from assumptions that are not valid".

Thanks
Sam
0
Sam Hobbs14y ago
Note that in this thread, saying Sam did something is ambiguous.

Yes, I think the code is being executed more than once due to the method being executed more than once due to events. I think one way to diagnose the problem is the stack. Hopefully the stack will show what is causing the code to be executed more than once. Of course if the explanation is that something totally valid is happening such as what Vulpes says then the stack might not help see that. The stack is more likely to help if there is something unusual happening.
0
Sam14y ago
Thanks Sam Hobbs.
You are right in writing that the the problem is probably external to the few lines I have shown, and that one needs more information to resolve it.

As I did not want to waste too much time I found a workaround that is even better and does not have the problem.

Nevertheless, I think the two lines I showed should work as they are.
There is nothing there more than a simple basic one item condition and one multiplication to perform.
The condition is untouched and is not influenced whatsoever by the result (the calculated value has no affect on the condition)
Regardless of what is outside of that 'if' , it should find the condition to be true, execute the action and unconditional continue to the next line rather than repeating itself.

I do not think it is a compiler bug, but I do think it is a unique combination that has not been taken care of.
I may get back to it when I'll have the time just of curiosity and try to figure out what it is.
Sorry I can not show the whole code. It is too big and complex with many ties (not really clean .NET OO code, which probably is the reason to the problem).
It is a part of a one-time test program that controls and tests another test device that we develop.
In any case, thanks a lot for trying to help, which you always do, and even if your answer does not point to the problem, it always opens new horizons and makes one think out of the box.
Sam
0
Sam Hobbs14y ago
Obviously the problem exists otside of what you provided here. You do not specify where this is done; I assume it is done in an event such as a button click but you do not specify what.

Problems such as this often result from assumptions that are not valid. So to help you we need to verify the validity of assumptions. Unfortunately I do not understand enough about your code to know what to suggest.
0