NumericUpDown control event not firing

Well...I've Googled high and low on this one to no avail. All the posts referring to the event not firing have to do with entering text, not using the up/down arrows. The problem is simple...I have a sub called:

Code:

---

    Private Sub PathNumber_NumUpDwn_ValueChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles PathNumber_NumUpDwn.ValueChanged

---

I click an arrow of the control and nothing happens. The event does not fire. So I deleted the control and the event code and re-added a new default NumericUpDown control and pasted my event code back in. Same problem.
the name of the sub and its arguments are the defaults created by .net when the control is double-clicked in design mode. I put a breakpoint at the very top of the event. It never trips.

What the heck am I missing here? All the docs say it should be firing.

Using vb.Net 2008. Project was a port-over from vb6 due to vb6 controls flaking out when it comes to Unicode.

Please disregard my post. It is working now and I haven't the slightest idea why. I would have loved to post why, but if I knew why, I could post why!
The only thing I can gather is that I had a dummy form where I could temporarily put a copy of some code. It had references to controls that did not exist on the dummy form. So when I would launch the program, .net would ask me if I wanted to continue with error sand I said yes. The dummy form is not connected to anything so it should not have interfered with anything.

So your guess is as good as mine!

I'm thinking the Handles clause wasn't wired up. But that's just a guess. It happens when you copy and paste controls. The IDE unwires event handlers when you cut/delete controls.

I checked that, but also when I recreated the control, .net recreated the sub line and all its parameters, including the handle.

Also, that temporary copy of some code I was storing in that dummy form was placed inside a dummy procedure, so it wasn't bare code exposed in the class area of the dummy form. So that seems like it should have been OK. The errors in that code were completely isolated from the rest of the program.

Hmmm I see. The IDE was probably bugging out then. In such a case you have to close VS and delete the bin and debug folders, restart VS and recompile and such glitches go away.

Good advice. I will definitely remember that one. Thanks for your help, Niya!

OK...This was part of the problem. According to MSDN, when a NumericUpDown control is set to a minimum, say, in this case, "1", then if afterwards, you set its current value to some variable that just happens to be less than 1, it is supposed to be defaulted to "1". In my case this did not happen, and vb.Net did not throw an error when the value = 0...It simply ignored the line and exited the sub, without completing the remainder of the code. Without a thrown error, it took a long time to find the culprit. That sounds like a bug to me...If a line instructs vb to do some task and it cannot do it, it would be great if it would let someone know about it.

Are you using any flavor of 64 bit Windows ? I've read a couple times around here that Form_Load in .Net applications swallows exceptions on any 64 bit incarnation of Windows.

I was about to ask whether you were doing this in the Load event. That behavior certainly sounds like the Load event issue.

On the other hand, I have had situations where I carefully studied a bug only to have it suddenly, and mysteriously, vanish. In some of those cases I had made a change that shouldn't have impacted it, so I went back and undid the change only to have the bug remain vanished. In other words: These things happen. Fortunately, they are very rare.

Quote:

---

Are you using any flavor of 64 bit Windows ?

---

Right, you are. So .net on 64 bit = black hole, eh? I wonder if vs2008 can be run in compatability mode...Would certainly be a synch to find out.

Quote:

---

I was about to ask whether you were doing this in the Load event.

---

No. It does sound like it though, since .net is strange about that compared to vb6. Seems more convoluted. Please see attached graphic of program flow. Interestingly, I did a new tiny test program with just the basics and an exception was thrown that time when the NumUpDown value was zero.

Attachment 98255

No, that is EXACTLY right. The problem with 64 bit systems, which arises from an internal disagreement between the VS and OS teams within MS (and that's about enough acronyms for this post), results in this: Exceptions thrown at any point in the form load event, including those thrown and not caught, in methods called by the Load event, will cause the load event to cease execution at that point. The method will immediately return when an exception is encountered, but no exception will be emitted.

You show a diagram of code operating in the Load event. At some point you say that an error should occur. If you are on a 64-bit OS, that is the LAST statement that the Load event will even try to execute in that method, which is why the rest never appears to happen. It doesn't appear to be executed because it is NOT executed. As soon as it hits that bad line....it returns immediately.

EDIT: By the way, this is not an issue that is likely to be fixed, because it is not technically a flaw. The OS team feels that this is correct behavior, and I tend to agree with them. The problem is that the VS team needs information they can't get. Perhaps a workaround will be found, perhaps not. In any case, there is something you can do about it: Add a try....Catch block around your code in the Load event if you think it will throw an exception. Of course, it is better to keep it from throwing an exception in the first place, but what you absolutely must avoid is having it throw an exception that you don't catch, because only that will cause totally aberrant behavior.

Sorry, I misunderstood you. I thought you meant that the WHOLE problem started from a form_load event, when I started from a button click. I see now that you mean the PARTICULAR issues that occur in the form_load event, regardless of how I got into the form_load event in the first place.

Thank you for the clarification and the workaround with a Try/Catch block. Your comments are going into my procedures "library".

Quote:

---

Originally Posted by Shaggy Hiker

No, that is EXACTLY right. The problem with 64 bit systems, which arises from an internal disagreement between the VS and OS teams within MS (and that's about enough acronyms for this post), results in this: Exceptions thrown at any point in the form load event, including those thrown and not caught, in methods called by the Load event, will cause the load event to cease execution at that point. The method will immediately return when an exception is encountered, but no exception will be emitted.

---

I think a lot of people use 64bit/AnyCPU cause they think it is always better.
I found this part interesting from Hidden Improvements in VB11,...

The compiler switch "/platform: anycpu32bitpreferred" was added as a better alternative to the AnyCPU setting.

Many developers change the default Target CPU from x86 to AnyCPU, thinking that will provide optimum performance in both x86 and x64 operating system (OS) environments. However, the performance penalty for running 64-bit code is rarely worth it. It's justified only when large memory space is truly needed. The vast majority of applications will run faster as 32-bit applications, even in a 64-bit OS.

I understand that is only because most programmers are not taking advantage of the CPU hardware's architecture and still thinking 32-bit on a platform that can do much more. They can get away with it because the hardware allows it, unlike GPU programming where understanding the hardware is essential. But on the flip side, I think that most applications are pretty basic in principal, and are not in any position to see significant performance increases with the caches and such.