11:40:02 PM
3FO1EQ7CF
You can set the form's target differently to force the page to post back to itself rather than the Process class page.
Well, yes, that would have been the preferred solution if I had just thought of it. That way I could use ExpandPage instead of Redirect to launch the page - I assume that would be a more efficient way to do things.
Submit button clicks are handled differently than other server events because the browser actually posts back the button name that was clicked to the server. Internally Web Connection checks for the EventTarget form var, if that doesn't exist it checks all submit buttons and if they have a click event handler the click is routed. It's done based on names.
The code that handles this logic is in wwWebControl::FireEvents.
Thanks - I've been using button events all these years without really having a handle on how they work.
--stein
Can you check what actually gets generated in the HTML output? Buttons don't use __doPostBack() - they just submit the form since they 'naturally' submit. It's just a submit button.
Does the app actually post back to the server when you click the button? Or is it just going on the client side? One thing might be the runat='server' - use double quotes. Web Connection doesn't parse single quoted attributes. That might account for the problem since if it's not a server control it won't render properly...
+++ Rick ---
I've got a framework page with a what should be a standard button:
For whatever reason, I cannot get the click event to fire. Clicking the button simply reposts the page as tho there were no Click property. And I have no idea how to debug this because I don't really know how this stuff works. There's a __doPostBack js function that's somehow involved, even though it does not explicitly show up in the page's HTML source. (How does that work anyway?) How can I tell if it's actually firing, or what parameters it's getting?
What could cause a button to fail like this? I've built many such pages with multiple buttons on them, all calling xxxx_Click events and they always just work (which is one reason I never thought about the actual mechanism behind them).
--stein
