Taborder after postback

[kpg]

After an autopostback event the control that gets focus next
is not the one defined in the taborder, but the first control.

This makes sense becuase the page is reloaded, but of course this
is not the desired behaviour.

I have seen the use of a hidden field, which stores the name of the control
that should get focus next, being set in the autopostback event, then an
OnPageLoad javascript that sets the focus to it.

This works, but only for 'forward' tabs, and the next control has nothing
to do with the taborder but is set in code.

It seems like there should be a better solution to this problem.

Actually, it seems like the viewstate should handle this automatically.

Any ideas or solutions?

kpg

[Mark Rae]

"kpg" <[e-mail]> wrote in message
news:Xn*******************************@207.46.248. 16...

It seems like there should be a better solution to this problem.
There doesn't need to be, as it's fully customisable server-side.
Actually, it seems like the viewstate should handle this automatically.
ViewState simply preserves values in form field either side of a postback
until / unless they are changed by that postback - no more, no less.
Any ideas or solutions?

You already know which of your client-side objects (button, dropdownlist,
hyperlink, checkbox etc) has caused the postback, and write server-side code
to be processed accordingly. Simply add the following to the end of the
server-side code as required:

ClientScript.RegisterStartupScript(this.GetType(), "focus",
"<script>document.getElementById('....').focus ();</script>");

Obviously, replace .... with the ID of the control that you want to receive
the focus.

N.B. this is v2 syntax, but v1.1 is almost identical.

[kpg]

As Mark Rae once said in microsoft.public.dotnet.framework.aspnet

ClientScript.RegisterStartupScript(this.GetType(), "focus",
"<script>document.getElementById('....').focus ();</script>");

Well, that is a more eloquent solution than the one I had
described and I thank you for it.

It does still leave the (albeit small) issue of the user
pressing a shift-tab on an autopostback field. In that
case it would still move forward in the tab order.

And not to dwell on this point to much, my comment about
the viewstate was to simply introduce the concept that
the page 'knows' where it would have set focus to before
the postback, and as such it could remember this bit of
information somewhere (the viewstate for lack of a better
place?) and automatically move the focus there when the page
is returned. Perhaps there are reasons why this can't be
done, it was just an intuitive thought I had.

But as it stands I'll use your suggestion.

Thanks.
kpg

[Mark Rae]

"kpg" <[e-mail]> wrote in message
news:Xn*******************************@207.46.248. 16...

It does still leave the (albeit small) issue of the user
pressing a shift-tab on an autopostback field. In that
case it would still move forward in the tab order.
Hmm - yeah, OK, I know what you mean but as you hint at, the likelihood of
this happening is fairly small. I've always been a great believer in the
80/20 rule for web development i.e. 20% of effort supplies 80% of usability,
and just how far you go to supplying the final 20% is really down to
time/budget/sanity...
And not to dwell on this point to much, my comment about
the viewstate was to simply introduce the concept that
the page 'knows' where it would have set focus to before
the postback, and as such it could remember this bit of
information somewhere (the viewstate for lack of a better
place?) and automatically move the focus there when the page
is returned. Perhaps there are reasons why this can't be
done, it was just an intuitive thought I had.

No, the ViewState really doesn't know this - that's not what it's for.

The ViewState's one and only purpose is to persist form values and page
variables across postbacks.

You as the programmer know what's supposed to happen next, so go to it -
that's your job! :-)

[kpg]

As Mark Rae once said in microsoft.public.dotnet.framework.aspnet

You as the programmer know what's supposed to happen next, so go to it
- that's your job! :-)

Point taken, but of course languages do indeed provide much of
what programmers used to do. Case in point - tab order. In
DOS programming (I know, I go way back) the programmer had to
specify all possible movements based on left, right, up, down,
tab, CR. Then in windows programming, tab order was introduced,
and the run time system handled movement. Well, all that spoiled
me, so with web programming (which I'm new to, can you tell?) I
see many areas where we are taking a step backwards.

Well, I've ridden this point well into the ground so I'll stop.

Thanks for your help.

kpg