Hi Russ!! Congratulations for the new beta!

I had this code with the previous beta which worked ok:

There is a page with this menu control:

 Then, in the code behind file, I programatically add items to the menu, ending up with a five level menu. I can post the code if needed.

What happens now is that the page postbacks when I select a menu item but the MenuItemClick event is not beign fired (regardless if I explicetly set the OnMenuItemClick function like in the code above, or if I just use the MenuItemClick handler)

Any ideas? Just let me know if you need more code details.

Thanks,

Juan

Hi Juan,

I'm sorry you ran into a problem with the new release.  Let's explore what might be going wrong.

Try out this page, http://www.asp.net/CSSAdapters/WalkThru/SimpleMenu.aspx.

When you click on a menu item on that page it fires the MenuItemClick handler on the server.  Take a look at the markup/code, http://www.asp.net/CSSAdapters/SrcViewer.aspx?inspect=~/WalkThru/SimpleMenu.aspx&notree=true.

Does that sample page work for you, too?  If so, I wonder if you can compare what you are doing with this sample.  Where are they different?

Hi Russ,

Yes, the sample is working here.

So, I started to compare it with mine: The only difference I found is that I'm also setting the value property for each menu item.  

Here is the "ChangeSelection" code i'm calling on the "OnMenuItemClick" handler:

And that's the problem: it's not firing that event. 

As  said before, I tried first to do it with a handler event (Protected Sub Menu2_MenuItemClick(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.MenuEventArgs) Handles Menu2.MenuItemClick) with no luck.

Ok Russ, it sounded like a good idea to me, so I did it :)

I tried all the following:
1) If I disable the Menu adapter extensions (commenting out the "Menu" adapter line in CSSFriendlyAdapters.browser), everything works fine.
2) I tried removing all the ajax bits in the page, so no ajax is messing up with the controls, with no luck.
3) It doesn't matter if you add the controls programatically or if you declare them in the .aspx page, it doesn't work either way.

Finally, I went to the "values" problem, and I found the "solution": I was setting the value for the first dynamic level item as an empty string ( "" ), and it seems that it needs some value, any, but not an empty string. So it was causing ALL the child controls not to fire the MenuItemClick event.

The thing is that, without the adapters, it works, and I think it "should" work, even with an empty value. Now. as a workaround, i'm using a dummy non-empty value, but I guess it should be fixed.

Cheers,

Juan

Ok, Russ, just but the sake of curiosity let us know what you find! :)

Anyway, it's a minor thing, could be easily "workarounded" for now :)

Hi Juan,

I've been doing more research into this issue.  I've discovered some things that I want to share with you.

I'm going to suggest that you re-validate your assertion that this problem only occurs when you use the adapters.  My testing is showing that it occurs in both the adapted and unadapted cases.

That actually makes sense to me, given the heuristics involved.  Let me explain.

When a menu is built to post back to itself its links use the usual __doPostDack JavaScript method.  This is done the exact same way (or that's the intention) both with and with the adapters in play.  If you hover over a menu link you can see its URL in the status bar of the browser.  Look at the second argument of __doPostBack.  It identifies the particular menu item that will be clicked.  It's how the framework on the server knows how to formulate the right event args to pass to the click handler.

That second arg to __doPostBack is actually the ValuePath of the MenuItem.  Each menu item, under the hood, can have a value.  If these values are unique then they give the menu a way to uniquely identify all of its menu items.  Actually, you can get away with giving the same value to two menu items but they can't be siblings.  That would be like naming two children (of the same mother and father) Bob and then expecting that folks would understand when you referred to "Bob's left hand."  Hmmm.  Which Bob are you talking about?

So the basic problem in your original scenario is what you ultimately found: you had defined Value properties such that the menu didn't have a way to give each menu item a unique ValuePath, thus it could not identify the menu items properly.  So the post back event handling got messed up and didn't happen as you expected.

The fix is exactly as you discovered, make sure that your menu item Value properties (if you specify them) are unique (at least for all sibling menu items).

I tested this whole using a modified version of walkthru\simplemenu.aspx from the kit.  I enabled and disabled the adapters by retaining or deleting (temporarily) the browser file in App_Browsers.  In my tests I placed Value="x" on sibling menu items in the menu in simplemenu.aspx.  Then I ran the page in a browser (being sure to refresh the page or dump my page cache ahead of time).  Then I clicked each menu item.  Whenever sibling menu items had the same value I ran into problems with at least some of the menu items not triggering the OnClick handler for the menu click event.  I could dup this problem regardless of the value I gave to Value.  I could even give it the empty string "" and the problem would occur.

As I said, I seemed to be able to dup this problem both with and without adapters in play.

Be sure to test lots of the menu items, not just the ones where you add the Value attribute.  The pattern of which ones work and which don't is a little tricky to see.

Also, be very, very careful to refresh your page after you modify it to be sure you aren't actually running the PREVIOUS incarnation of the page.

The bottom line to all this is that I don't see a simple way to avoid this problem in the kit.  I'm inclined to leave the adapter code as-is.  Are you OK with that?  It simply means that you need to be careful not to make ValuePath ambigous for you menu items.  And this seems to be a restriction in the unadapted case, too.