|
|
Rank: Newbie
Groups: Member
Joined: 10/6/2009
Posts: 7
|
I have an application that utilizes a Master Page with EO.Menu control.
In many of my derived pages I wish to persist the users entries and selections without requiring the user to save his changes before selecting another menu option. Most controls are not a problem because I can use the Callback control to notify the server. The issue comes with textboxes where I need to wait until the user has completed his edit and changed focus; i.e. clicked on a MenuItem. Without any action on my part these entries would be ignored.
For an unassigned MenuItem I do not have a problem since I can capture the Click event and, via a delegate, I can notify the page to save itself before the new page is loaded.
The issue comes with MenuItems that have a NavigateUrl specified. In this case the event does not trigger. I have worked around this by using the Value property to hold the URL rather than it's correct property. In the MasterPage I redirect after raising the appropriate event to save the users changes.
My workaround seems to work OK but what I would really like is to have the click event processed irrespective of whether a URL is specified. This would minimize the risk of other developers missing my workaround.
OldBrit
PS.
Great product, I'm a windows app guy really and so I was dreading the prospect of programming in ASP until I found your suite of controls.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi,
There is no way for you to go straight to another page while capture the input of the existing page because in order to capture the input, you must post back to the same page. Obviously by definition, this goes against going to another page. Using Value and Response.Redirect is the probably the best solution for this situation.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 10/6/2009
Posts: 7
|
I guess what I was looking for was for the Click event to get processed before the new page was loaded. Clearly I understand that once the new page starts to load all bets are off but in this case the original page is still active and quite capable of receiving events as demonstrated by my workaround.
Not a big deal but it just seems to me that the option for processing click events has little value if it doesn't fire on MenuItems that don't load another page!
OldBrit
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
OldBrit wrote:in this case the original page is still active and quite capable of receiving events as demonstrated by my workaround. Yes. That is probably the best way to do it. However it is probably not a good idea to have this built into the menu because for this to work, there must be somewhat of a "grand scheme" to justify such server events as necessary ---- in your case you have other elements such as CallbackPanel. Server event together with NavigateUrl alone would be meaningless unless you have such scenarios, and adding options for the menu to fire server event for users who do not face such scenarios would confuse them more than help them. Appreciate your input though. Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 10/6/2009
Posts: 7
|
Thanks, I take your point.
Most applications of a Menu are used to switch to a different section of a website. In my case I use the Menu to provide multiple means of arriving at the same end point. i.e. Customer, Product Serial number etc.
Thanks for your input anyway!
|
|