Postbacks confusing to the user - any suggestions???

[Glenn]

Hi!

I've developed an app that displays multiple textbox and
combobox fields (most of which are autopostback) on a form
along with a submit button. My users find it confusing
when they change data in one of the autopostback textboxes
then click on the 'submit' button and, instead of seeing
the next form they see the same form come back to them, as
if they never clicked the 'submit' button. What's
happening behind the scenes is that changing the text box
then clicking the 'submit' button first triggers
the 'onblur' event of the textbox which triggers the
postback, so the click of the 'submit' never really
happens to the backend. Does anyone have any suggestions
on what my options are to make this clearer to the end
user (I do have a 'Please wait' message during postback
but that doesn't clarify things - it's the same form
coming back that doesn't make sense to them, all they know
is that they pressed 'submit'). Is there any clever way
for the back end (vb.net/asp.net) code to detect that the
submit has been clicked so that I can consolidate the 2
operations?

Thanks in advance,

Glenn

 

[George Ter-Saakov]

Do not show the Submit button until ready.

George.

 

[Guest]

I am not too sure that I understand your problem very clearly, but I'll try to help anyway based on my understanding of your situation. Becasue the button can have its own event handler (e.g. Button1_Click), you can put whatever code/functionality in here to differentiate from an AutoPostBack. To create an event handler for the button, double click on it in Design View and Visual Studio will create one for you

To actually differentiate between an AutoPostBack and a Button_Click: When the Button_Click occurs you can hide all the WebControls and display a "Thank you for your submission" message. One way of achieving this is by using two Panel controls. Panel1 would contain all the WebControls, and Panel2 can contain the message. Intiially Panel1 is visible and Panel2 is hidden. When the Button_Click occurs, hide Panel1 and show Panel2

Rasika Wijayaratne

 

[Glenn]

Thanks to all for the feedback...

but perhaps I didn't describe the problem properly. As an
oversimplified example consider an aspx page with 1
textbox (text1) that is autopostback and another textbox
(text2) that is not. Add a submit button (button1). Now
the behavior is:

If the user enters data into text1 and mouse-clicks the
submit button the postback for text1 occurs submitting the
text1.changed event to the server and the server never
sees the button1.click event, causing the original
(updated) page to appear (then the user must
press 'submit' as second time to move on to the next
page).

However, if the user enters text into text2 instead, then
clicks the submit button the button1.click event occurs
and the next form in the application appears.

This is inconsistent behavior to the user and very
confusing because all the user perceives is that he
pressed the submit button. (fyi I already display
a "Please wait" panel during postback...this doesn't clear
up their confusion, again, all they care about is that
they "submitted" the form.)

Hope this helps explain the issue better.

Thanks!!!

Glenn

 

[Rick Spiewak]

Look for a way to eliminate the autopostback use on the textboxes. What are
you doing that you need this event for? If it's validation, use the
validation controls or write some javascript.

 

[Glenn]

Rick:

Thanks for the reply.

Some fields need to be autopostback because the back end
app needs the info to update the page (add/remove fields)
or move on to another page or open a new window. This app
(not the oversimplified example) is rather "chatty" as it
backends both a windows app and this web app and is
extremely dynamic - all of the web pages are built
dynamically and can vary based on data on that or other
forms - there are no static forms - and each form is built
on-the-fly from an xml description of the page passed into
it from the back end. So the web app needs to be both
generic and flexible. So far this is the only situation
that doesn't work right because of the combination of
autopostback fields and the submit button and the
perceptions of the users.

Glenn

 

[Chuck Ritzke]

Seems to me like a reasonable solution would be to hide the submit button
when the text box gets the focus (perhaps with a message that says they must
tab out before submitting) and then make it visible upon return from the
post back.

Chuck

 

[Glenn]

Thanks Chuck!

We thought about that but realized that there exists the
very real possibility that there might be only 1 textbox
and the submit button on the form and if we hide the
submit button there would be no where to tab to. (See my
reply of 4/22 to Rick Spiewak elsewhere in on the main
thread.

Glenn

 

[Chuck Ritzke]

If you only have one textbox (which I assume you know during postback), then
do you need a submit button? Instead of tabbing anywhere, maybe you could
just have the postback automatically raise the submit event in that case.