By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,780 Members | 1,520 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,780 IT Pros & Developers. It's quick & easy.

Trying to find ClientID of web form - Solution Found

P: n/a
After pouring over about a dozen sites that clearly dealt with ClientID
all by itself, I came to the realization that about 2/3+ of them were
doing it wrong. It is indeed impossible to grab the Client ID of a form
field from within a DataGrid like this: <%= FormFieldID.ClientID %>. At
least, not without extra work.

How did I do this? I created a new DataGrid from scratch, with a form
above it and a form inside of it. This was a page about 50 lines long -
so, very short - with no user dependencies except for the initial
loading of the DG with content from the DB.

While I was able to get the ClientID of the form that was outside of the
DG, I was unable to do so for any form fields inside of the DG using <%=
FormFieldID.ClientID %>. Doing so threw the error.

That got me to thinking. Which, after nearly two days of rest from the
subject, was a wee bit clearer than before Sunday.

I decided to call the form field directly. I first Dim'd a name as a
textbox, and then I called the right textbox by catching it when the DG
was being created. Since it was in the footer (the footer is an "add"
row) simply calling like this:
Dim add_Date as TextBox = e.Item.Cells(1).FindControl("add_Date")
was a bit difficult. Which row would be referenced? How would the script
know to look in the footer? Since the footer comes and goes (I don't
need it during an edit), looking for it would have to be conditional.

In order to catch the right row (the footer) while the DG is being
built, I added a feature to the DataGrid itself (onItemDataBound =
"dg_ItemDataBound") which calls the sub dg_ItemDataBound when the
DataGrid is being built.

From here, I created a Sub (Sub dg_itemDataBound()) in which I
contained my attempt to find the ClientID of the form field within the
footer:
If e.Item.ItemType = ListItemType.Footer And dg.ShowFooter = True then
Dim add_Date as TextBox = e.Item.Cells(1).FindControl("add_Date")
End If
From here it was pretty easy to set up a RegisterStartupScript (inside
the IF) that made use of add_Date.ClientID. Since I had already defined
add_Date as the form field called "add_Date" in the second cell of the
footer row, the usage of add_Date.ClientID no longer threw an error.

I also had to implement this within the dg_Edit() Sub, in a slightly
different fashion, but that's because I allow rows to be edited.

***

What is really strange is the sheer number of sites that claim that
using <%= FormFieldID.ClientID %> will actually work inside of a
DataGrid without further modification or code. It certainly didn't work
for me.

I would also like to apologize to the community at large for my hissy
fit on the weekend. It had been a very long week, this was just one of
many problems I was still trying to solve, and Juan's reply seemed to be
mocking me for my lack of progress. Normally I'm much more mild
mannered, but something in me must have snapped from all the stress.
That should not have happened.

Gomen dasai.

TIA
....Geshel
--
************************************************** ********************
My reply-to is an automatically monitored spam honeypot. Do not use it
unless you want to be blacklisted by SpamCop. Please reply to my first
name at my last name dot org.
************************************************** ********************
Nov 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On Tue, 21 Jun 2005 22:00:10 -0700, Neo Geshel wrote:
After pouring over about a dozen sites that clearly dealt with ClientID
all by itself, I came to the realization that about 2/3+ of them were
doing it wrong. It is indeed impossible to grab the Client ID of a form
field from within a DataGrid like this: <%= FormFieldID.ClientID %>. At
least, not without extra work.

How did I do this? I created a new DataGrid from scratch, with a form
above it and a form inside of it. This was a page about 50 lines long -
so, very short - with no user dependencies except for the initial
loading of the DG with content from the DB.

While I was able to get the ClientID of the form that was outside of the
DG, I was unable to do so for any form fields inside of the DG using <%=
FormFieldID.ClientID %>. Doing so threw the error.

That got me to thinking. Which, after nearly two days of rest from the
subject, was a wee bit clearer than before Sunday.

I decided to call the form field directly. I first Dim'd a name as a
textbox, and then I called the right textbox by catching it when the DG
was being created. Since it was in the footer (the footer is an "add"
row) simply calling like this:
Dim add_Date as TextBox = e.Item.Cells(1).FindControl("add_Date")
was a bit difficult. Which row would be referenced? How would the script
know to look in the footer? Since the footer comes and goes (I don't
need it during an edit), looking for it would have to be conditional.

In order to catch the right row (the footer) while the DG is being
built, I added a feature to the DataGrid itself (onItemDataBound =
"dg_ItemDataBound") which calls the sub dg_ItemDataBound when the
DataGrid is being built.

From here, I created a Sub (Sub dg_itemDataBound()) in which I
contained my attempt to find the ClientID of the form field within the
footer:
If e.Item.ItemType = ListItemType.Footer And dg.ShowFooter = True then
Dim add_Date as TextBox = e.Item.Cells(1).FindControl("add_Date")
End If
From here it was pretty easy to set up a RegisterStartupScript (inside
the IF) that made use of add_Date.ClientID. Since I had already defined
add_Date as the form field called "add_Date" in the second cell of the
footer row, the usage of add_Date.ClientID no longer threw an error.

I also had to implement this within the dg_Edit() Sub, in a slightly
different fashion, but that's because I allow rows to be edited.

***

What is really strange is the sheer number of sites that claim that
using <%= FormFieldID.ClientID %> will actually work inside of a
DataGrid without further modification or code. It certainly didn't work
for me.

I would also like to apologize to the community at large for my hissy
fit on the weekend. It had been a very long week, this was just one of
many problems I was still trying to solve, and Juan's reply seemed to be
mocking me for my lack of progress. Normally I'm much more mild
mannered, but something in me must have snapped from all the stress.
That should not have happened.

Gomen dasai.

TIA
...Geshel

Thanks, I learned something from your post.

Nov 19 '05 #2

P: n/a
Hi,

alternative:

To get the ClientID of a control contained inside the DataGrid's item you
can create a databinding expression and run it like this

<%#Container.FindControl("FormField").ClientId%>

in the template (ClientID will be resolved every time when databinding
happens). <%=%> won't necessarily do here because they run at rendering
stage.

(I assume you use this to create js calls into/from the controls contained
in dg)

--
Teemu Keiski
ASP.NET MVP, AspInsider
Finland, EU
http://blogs.aspadvice.com/joteke

"Neo Geshel" <go****@geshel.org> wrote in message
news:uu**************@TK2MSFTNGP10.phx.gbl...
After pouring over about a dozen sites that clearly dealt with ClientID
all by itself, I came to the realization that about 2/3+ of them were
doing it wrong. It is indeed impossible to grab the Client ID of a form
field from within a DataGrid like this: <%= FormFieldID.ClientID %>. At
least, not without extra work.

How did I do this? I created a new DataGrid from scratch, with a form
above it and a form inside of it. This was a page about 50 lines long -
so, very short - with no user dependencies except for the initial loading
of the DG with content from the DB.

While I was able to get the ClientID of the form that was outside of the
DG, I was unable to do so for any form fields inside of the DG using <%=
FormFieldID.ClientID %>. Doing so threw the error.

That got me to thinking. Which, after nearly two days of rest from the
subject, was a wee bit clearer than before Sunday.

I decided to call the form field directly. I first Dim'd a name as a
textbox, and then I called the right textbox by catching it when the DG
was being created. Since it was in the footer (the footer is an "add" row)
simply calling like this:
Dim add_Date as TextBox = e.Item.Cells(1).FindControl("add_Date")
was a bit difficult. Which row would be referenced? How would the script
know to look in the footer? Since the footer comes and goes (I don't need
it during an edit), looking for it would have to be conditional.

In order to catch the right row (the footer) while the DG is being built,
I added a feature to the DataGrid itself (onItemDataBound =
"dg_ItemDataBound") which calls the sub dg_ItemDataBound when the DataGrid
is being built.

From here, I created a Sub (Sub dg_itemDataBound()) in which I contained
my attempt to find the ClientID of the form field within the footer:
If e.Item.ItemType = ListItemType.Footer And dg.ShowFooter = True then
Dim add_Date as TextBox = e.Item.Cells(1).FindControl("add_Date")
End If
From here it was pretty easy to set up a RegisterStartupScript (inside the
IF) that made use of add_Date.ClientID. Since I had already defined
add_Date as the form field called "add_Date" in the second cell of the
footer row, the usage of add_Date.ClientID no longer threw an error.

I also had to implement this within the dg_Edit() Sub, in a slightly
different fashion, but that's because I allow rows to be edited.

***

What is really strange is the sheer number of sites that claim that using
<%= FormFieldID.ClientID %> will actually work inside of a DataGrid
without further modification or code. It certainly didn't work for me.

I would also like to apologize to the community at large for my hissy fit
on the weekend. It had been a very long week, this was just one of many
problems I was still trying to solve, and Juan's reply seemed to be
mocking me for my lack of progress. Normally I'm much more mild mannered,
but something in me must have snapped from all the stress. That should not
have happened.

Gomen dasai.

TIA
...Geshel
--
************************************************** ********************
My reply-to is an automatically monitored spam honeypot. Do not use it
unless you want to be blacklisted by SpamCop. Please reply to my first
name at my last name dot org.
************************************************** ********************

Nov 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.