Trying to find ClientID of web form - Solution Found

[Neo Geshel]

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.Cli entID %>. 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.Cli entID %>. 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("a dd_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 (onItemDataBoun d =
"dg_ItemDataBou nd") which calls the sub dg_ItemDataBoun d when the
DataGrid is being built.

From here, I created a Sub (Sub dg_itemDataBoun d()) in which I
contained my attempt to find the ClientID of the form field within the
footer:
If e.Item.ItemType = ListItemType.Fo oter And dg.ShowFooter = True then
Dim add_Date as TextBox = e.Item.Cells(1) .FindControl("a dd_Date")
End If
From here it was pretty easy to set up a RegisterStartup Script (inside
the IF) that made use of add_Date.Client ID. 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.Client ID 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.Cli entID %> 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.
*************** *************** *************** *************** **********

[intrader]

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.Cli entID %>. 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.Cli entID %>. 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("a dd_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 (onItemDataBoun d =
"dg_ItemDataBou nd") which calls the sub dg_ItemDataBoun d when the
DataGrid is being built.

From here, I created a Sub (Sub dg_itemDataBoun d()) in which I
contained my attempt to find the ClientID of the form field within the
footer:
If e.Item.ItemType = ListItemType.Fo oter And dg.ShowFooter = True then
Dim add_Date as TextBox = e.Item.Cells(1) .FindControl("a dd_Date")
End If
From here it was pretty easy to set up a RegisterStartup Script (inside
the IF) that made use of add_Date.Client ID. 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.Client ID 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.Cli entID %> 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.

[Teemu Keiski]

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.Fi ndControl("Form Field").ClientI d%>

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******** ******@TK2MSFTN GP10.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.Cli entID %>. 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.Cli entID %>. 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("a dd_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 (onItemDataBoun d =
"dg_ItemDataBou nd") which calls the sub dg_ItemDataBoun d when the DataGrid
is being built.

From here, I created a Sub (Sub dg_itemDataBoun d()) in which I contained
my attempt to find the ClientID of the form field within the footer:
If e.Item.ItemType = ListItemType.Fo oter And dg.ShowFooter = True then
Dim add_Date as TextBox = e.Item.Cells(1) .FindControl("a dd_Date")
End If
From here it was pretty easy to set up a RegisterStartup Script (inside the
IF) that made use of add_Date.Client ID. 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.Client ID 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.Cli entID %> 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.
*************** *************** *************** *************** **********