you need wizCreateBulk.FindControl("txtName") the wizard control is the parent control not the templates...

Ugghh sorry silly mistake
By the way, is it possible for one sub procedure in a.aspx.vb to call another sub procedure in b.aspx.vb ?
Thanks.

it is possible but a bit tricky. And depends if you want to send the client there or not. In all cases you need to pass a variable in the request to b and then on page load you would need to check for this variable and call your sub then decide if you need to call the rest of page load or not. To do it by sending the browser you would need to create a public property for the variable in page a and then call response redirect or server.transfer to b. in Page load for b you would need to get the context.handler and then cast it to page a and then get the public property you created.
to do it behind the scenes you would be best to use the HttpWebRequest and add your variable to the content then handle it in page b page load again.

All the ways are pretty messy and not advisable. I would recommend you create a class which has the subroutine in it and then you can call the subroutine from any page cleanly and quickly.

Thanks for your fast response.
I have thought of doing the global class thingy that you have mentioned.
Then I thought it's quite inappropriate.
Alright, the scenario is this, from b.aspx.vb (child window), I'd like to call a function in a.aspx.vb (parent window) to pass some information to a control inside a.aspx.

How's that f1 fan ?

Thats a whole different scenario and requirements First it is better practice for a child not to know about its parent unless it is essential (in fact it is better if neither knows about each other - see the mediator pattern) but that is another topic all together.
From my understanding you have a form a.aspx and the user clicks a link to go to b.aspx where they fill in some information. When they have completed that you want to use the information back in a.aspx?
There are a number of ways to achieve this and you should not call a.method1 to do it. Use any one of the following:
1. use the session and add the values from b.aspx then when you are back in a.aspx get them out of the session and use them. Remember session means the data is going back and forth with every request and postback not just between a and b so clear any session variables you do not need as soon as you have finished with them
2 add the data to the response in b.aspx and get the data when you go back to a.aspx
3. add the data to hidden fields in b.aspx and get them in a.aspx when you get back (the difference between 2 and 3 is Get vs Post)
4. Put the data in a public property in b.aspx and register b.aspx in a.aspx then cast the context.header to b.aspx and get the data from the property (this would not be the recommended way for your requirements but sometimes is the only way)

If you are not sure on any of the above or want more information just shout. I am guessing 2 or 3 would be your best choice but depends how long you need to be able to access the data - maybe the session will be better

Thanks once again.
Umm, yeah, guess I need more information on the 2nd and 3rd options.
I'm not quite sure how it can be done but I have a rough idea here, did you mean that the form action tag of b.aspx should point to a.aspx so that the response could be posted to a.aspx ?

Also, I have always thought of session as the first choice but what always pulled me back is, I always have thought that session variables are to hold login information or other user preferences information, not to hold form results etc.

Session state can be used to store anything you want between sessions for a user (remember it is for a user not the application - there is an application state for that). Session is usually used for shopping carts and things like that. What you have to remember with a session is that the data is sent back and forth with every request from your user, not just for a page, but EVERY page and postback while they are on your site. So as long as you remember that and clear out any session variables as you finish with them (much the same as you should with any variable you use) then you can use it as much as you like.

But if it is just getting information from a page then there is no need to use the session. So we are back to options 2 and 3 from my last post.

For option 2: lets say in b.aspx you had 2 variables you needed to pass back to a.aspx. All you need to do in your response.redirect is call Response.Redirect("a.aspx?value1=" + val1 + "&value2=" + val2, true/false); then in page load of a.aspx just get those 2 variables by doing the following
string value1 = Request.QueryString("value1"); string value2=Request.QueryString("value2");
The trouble with this is it appends it to the url so people can see it (the downside of a GET) so you can use a POST instead which uses hidden fields. This is option 3.

In b.aspx you need a hidden field for each value you want. You can do this either at designtime or runtime. Then when the user has finished you fill in the values hiddenfield1.value = txtbox1.value; etc etc

Then just do a normal Respons.Redirect(a.aspx, true/false); this time there are no extras in the url. Though they can view source to see the fields in the middle of it all. but no biggie.

Then in page load of a.aspx you need to get the Request.Form which is a specialized name value collection where name is the hiddenfield id you created and value is the value you put in it. one for each hidden field. so you would do the following :
string value1 = Request.Form("hiddenfield1"); string value2=Request.Form("hiddenfield1");

Hope that helps. Personally i would go for the post option (option 3) and keep things hidden

Wow, thanks for your thorough explanation.
All understood.
I will try that out.

Umm, I have another quick question here:-
I have been using the sqlDataSource control for about a week now but just recently came accross a situation whereby I need to build dynamic sql.
Initially, I opt to do things in the vb side where I'd do

However, one problem encountered is, when using manual data binding, extra codes are needed to handle pageIndexChanged exception
So, I changed the strategy to go into using an sqlDataSource object. My code is as per below:-


My question is, Is the sql part in the selectCommand okay (especially the part highlighted in red) ?
I have tried all sorts of ways but to no avail.
Results aren't coming out.
Sorry for the long-winded post.

Your select command is wrong... you have where vaNAME like '%@vaNAME%' and ... where it should be
where vaNAME like '%" + @vaNAME + "%' and ...
Just as a matter of advice try to ALWAYS use stored procedures instead of writing sql queries in code. a few reasons - the main one is security i can bet money that you dont verify the text in the textbox is not sql commands and i would be in your database within 10 seconds (you wont believe the number of websites you can get into just from the login page - it is called SQL Injection and is usually number 1 on the hackers try list as it is so easy). What if i typed in the textbox something like this (pay attention to the ' ) in the textbox when you asked for my name... fred ' delete from master .... your whole sql server is wiped out now. took me less than 10 seconds. my simple ' in there closed your where clause (if you dont believe me go look at the sql statement with my text substituted for the variable) and allowed me to run my delete sql statement (yes you can have multiple sql statements one after the other, they dont have to finish before sending the next one)
So that is the main reason to use stored procs - you dont put in the ' round text so no sql injection can take place. The second reason is performance. Stored procs are compiled and run on the server. This means they are quicker, can be cached, you can run index analysis on them etc. Also what if you needed to add a new where clause? You would have to send out your program to everyone again after rewriting the new where clause. Would you get everyone? If it was for a new column that didnt allow nulls these people couldnt use your app until you changed it (assuming a central database) so not backwards compatible. Whereas with a stored proc you have only one place to change it, it is backwards compatible (assuming you code it correctly) and it takes effect immediately.