EventHandlers

[Retrei]

Hi, I would really appreciate this new feature (EventHandlers).. when you have 20 Private Methods and 7 of them are EventHandlers, it's awkward to browse through them.

[rauchy]

Reteri,

Syntax-wise, event handlers look exactly like normal methods so it will be impossible to automatically apply layout on them without going into semantic levels.

Could you paste some example code to demonstrate this annoyance? Maybe it could be solved using existing functionality.

[Retrei]

Yep.. maybe you are right. But I don't see how it could be done yet. I posted here a sample of code.. some of the methods are handling events, some are just methods. Imagine a load of code instead of each "..." string. If you are looking for some event handling method, you got to check too many lines, before you find what you want. Maybe you could check on the arguments of a method and when there is an argument named according to regex pattern *EventArgs, then mark it as EventHandler method.. I know that one might name a class derived from EventArgs differrently than it *SHOULD* be named, but then one´s needs reading some coding guidelines or simply exclude EventHadlers from CodeLayout.xml.. Btw, thanks for Regionerate.. it´s really great tool.

Retrei

Code: Select all

             
#region  Private Methods (11)

private void articleGridView_KeyPress(object sender, KeyPressEventArgs e)
...
private void articleGroupTabControl_Selected(object sender, TabControlEventArgs e)
...
private void ArticleGroupTreeview_AfterSelect(object sender, TreeViewEventArgs e)
...      
private void ArticleSelectGridView_CellDoubleClick(object sender, DataGridViewCellEventArgs e)
...   
private void BindTabPageData()
...
private void ClearTabPageData()
...   
private void closeButton_Click(object sender, EventArgs e)
...
ArticleGroupTreeNode CreateTreeNode(ArticleGroup group, TList<ArticleGroup> allGroups)
...
private void DoDataBind()
...
private void OnNewArticleToCurrentGroupCommanded(int articleGroupId)
...
private void OnShowArticleDetailsCommanded(int id)
...   
#endregion

[rauchy]

Reteri,

That's a tricky one, as there is no certain way to know which methds are event handlers by syntax alone.
If all of your event handlers look as in your code sample, you can filter by creating a regex like ".*_.*". Not perfect, but might work.
Are you trying to enforce a layout for your personal code or are you creating a layout for your entire team?

Let me know.

[Retrei]

It´s my personal code I intend to enforce layout on.. I accept your opinion that there is no CERTAIN way to determine, what is EventHandler and what is not.. I suggest determining them by parameters (EventArgs classes) and using them could be optional, not default. It could be designed like:

<CreateRegion Title="Event Handlers" Style="Visible">
<PutMethods>
<Where>
<ParameterType Equals="{some regex for EventArgs classes}" />
</Where>
...

[rauchy]

Retrei,

Sounds like a reasonable solution. Unfortunately, there is no support for filtering by parameters.
I will add this as a feature request and have it on the upcoming survey.

Btw, I've been to Prague a few months ago on vacation and miss it badly

[Retrei]

OK, thanks. Been to Prague? Good choice If you miss it so badly come back for a couple of days

[MelGrubb]

I would also like to see the ability to put event handlers in their own regions. As for how to accomplish it, you could just look for anything with an underscore in the name, as that's the naming convention for event handlers. It's not foolproof, but it's a good 95% solution. Alternately, any method that has an argument named "e" would work, but is still not foolproof. The most robust solution would be to consider any method with an argument which inherits from EventArgs to be an event handler. This is, of course, the hardest one to code, but the most reliable of the three.

I always divide off my event handlers as a matter of style. Not just because they are different, but because I don't tend to put much code in them. They are not the "interesting" part of my code. In my opinion, I shouldn't have business logic in a button handler because methods should say what they do, and do what they say. While clicking a button may initiate some kind of processing, the name of the handler doesn't tell you anything about that. All the name of the handler says is "btnSave_Click". It should immediately hand off to a method called "SaveData" or something like that. When someone unfamiliar with your code is trying to work on it, they won't immediately go looking at the button handler... they are naturally going to go looking for something that starts with "Save". Only after NOT finding it would they go looking in the "wrong" place inside the button handler.

In general, my event methods will be very short, only a couple of lines. Only enough to do what they method SAYS they should do. Perhaps that involves checking some state data to see which of several options should be executed, but that's it. They are layovers, not destinations.

MG2

[rauchy]

MelGrubb,

I agree with your perspective on logic inside event handlers. I basically see event handlers as wiring to the actual logic.

Regarding the way to filter event handlers -

Option one is indeed the easiest but not foolproof. But it is already available and you can use it right now.
Option two is also easy but not available yet. However, I think this has already been requested so it should be available shortly (the ability to match a method by matching a regular expression to the parameters string)
Option three is indeed difficult, and will require using semantic abilities which hopefully will be available in v2.0.

If option one is 95% certain and option two is 95% certain, I guess the best way to go right now is to combine both of them and reach a very high level of certainty. Something like:

Code: Select all

<CreateRegion Name="Event Handlers">
   <Where>
      <Name Matches=".+_.+"/> <!-- Matches any method which has an underscore in the middle -->
      <Parameters Match=".*EventArgs\se.*"/> <!-- Matches any method which has a parameter whose type ends with "EventsArgs" and name is "e", for example "ButtonClickedEventArgs e" or just "EventArgs e" -->
   </Where>
</CreateRegion>