Usefullness of any event

Miyamoto M

Hi all,

Visual Basic was released in the 1990's and immediately became hugely popular in corporate America because its new Event Driven design allowed programmers to deliver huge financial value to organizations.

Event Driven is a key concept there, it seems to me.

I have a theory today, as follows, for Windows Forms 2.0:

THE VALUE OF AN EVENT TO A PROGRAMMER IS USUALLY INVERSELY RELATED TO THE NUMBER OF TIMES IT FIRES.

For example, if, when a Form opens, its form_load event fires once and only once, that is a good thing for a programmer. But if it fires twice, then the event is not so useful. If it fires 6 or 7 or maybe 10 times every time the form is opened, then its value is even less. Thank goodness, in Windows Forms 2.0, the form_load event still fires once and only once.

But next, take for example a ComboBox's SelectedIndexChanged Event.

If, when we bind a form for example, the ComboBox's SelectedIndexChanged Event fires once, and only once, then it can be very valuable to a programmer. But if it fires twice, at unpredictable points, its value to a programmer is greatly diminished, it seems to me. And if it fires, 3 or 4, or maybe 7 or 8 times, unpredictably, its even more useless. Unfortunately, in Windows Forms 2.0, the SelectedIndexChanged fires multiple times, somewhat unpredictably to boot.

Or take for example a simple button click. Hopefully, we programmers are confident that whatever code we put in a button's click event will only be processed once, and only once, when the user clicks the button. What if the button_click event fired not once, but 2 or 3, or maybe a dozen times, and not just when the user clicked, but during form_load and binding Would we want to use it

This is only a theory of course. Can anybody see any weakness in this theory, or ways to state the theory more correctly

Any thoughts or ideas will be appreciated.

Miyamoto M

Theory:

"The value of an event to a programmer is inversely related to the number of times it fires."

Am I wrong about this Any thoughts will be appreciated.

Mario Cossi

Miyamoto M,

according to your theory, the Paint event would be utterly worthless. I humbly disagree.

--mc

Steve Py

Rofl... You won't let this one go eh

Data-binding exposes all evils in the world. I still avoid it.

VB was a brilliant tool. Simple and effective. Unfortunately that wasn't enough for many people & projects, they expected too much of it so developers had to invest lots of time and experimentation to learn it's quirks and work-around its limitations. "Hardcore Visual Basic".

.Net (VB.Net & C#) is an evolution of VB in the sense that Microsoft has gone and tried to develop a framework to abstract the muck that has become the Windows Kernel. It's a framework now rather than a development tool wrapping COM. This gives developers more power than they had with VB, along with a bundle of new tricks. (Serialization, security, XML, threading, globalization, etc.) The fact is it's still built upon the same kludge that is Windows so don't be surprised when something happens that doesn't seem logical.

I don't remember the exact quote but it's along the lines of " If you get nervous every time the universe does something that doesn't make sense, you're going to be nervous every day until the day you die."

Miyamoto M

Mario,

I haven't used the Paint event yet. I take it that it fires multiple times. Do the multiple firings execute you code over and over

Do the multiple firings help you or, if it was built differently, i.e, to only fire cleanly only once, would you prefer that

Thanks.

Miyamoto M

Steve Py,

First, thanks for telling me about the SelectionChangeCommitted event in another thread a couple of days ago. It was a real life saver:

http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=2001373&SiteID=1

On the multiple firings of events, I guess I've never been in the shoes of the folks that wrote the stuff. I don't know whether their reasons were that they had a deadline and had to get the thing out the door, or whether they made some decisions while they were tired late at night, or whether there is some mysterious developer out there who actually benefits from the multiple firings.

But the more I work with Windows Forms 2.0, the more respect I have for the folks that designed ASP.NET. I was expecting Windows Forms to be cleaner than ASP.NET, but I've found it to seem just the opposite. Maybe it's my imagination.

Does that go along with your thought that the Windows kernel is a major source of the problem with Windows Forms

Thanks.

nobugz

Miyamoto M

Hans,

Thanks. On the subject of the ComboBox, why didn't they introduce a newer model then, instead of building on the cruft. Kind of like they did with the DataGridView being a newer model, fresher and better than the DataGrid, but the DataGrid still works if you want to keep using it

On the subject of WPF, I did flip through a book in Barnes & Noble the other day. I was looking to see if they have any good databinding stuff, but didn't see any. Do you know if they have any drag/drop databinding yet for WPF Thanks.

nobugz

Miyamoto M

Thanks.

Steve Py


Heck, I was ecstatic when they finally upgraded the scrollbar's value from a 16-bit integer. It didn't happen until .Net was released.

Ultimately while changing behaviour may seem like the most logical course of action you need to keep in mind that countless lines of code are written to use, or work around that behaviour. One service release or new framework version release that changes that behaviour and *ka-pow*, potentially lots of broken apps. Introduce the new, and deprecate the old, or leave the old as-is because it still serves a purpose.

Relating to the Paint event, yeah it fires more than once and it's good that it does because there are a lot of things that can happen that signal that a window or region within a window need to re-paint. But for specific user-actions there are more practical events to utilize. For instance when a form is resized you can catch Paint events, (not efficient) Resize events, (the old improved standard) or now a Layout event. (The new, more efficient event.)