Hidden variables would work. The ASP.NET ViewState mechanism is just a hidden variable.

In HTML, you simply create:

<input type="hidden" id="myHiddenVar">

To set it's value in javascript:

document.getElementById("myHiddenVar").value = "myValue"

In ASP.NET code-behind, you use the Request object to retrieve the value.

So many ASP.NET programmers waste hours trying to find the "ASP.NET" way to do things, even though the "right" way has been around since the web's inception. Whenever I'm confronted with the stereotypical ASP.NET-induced brain-lock, I try to clear my mind of all Microsoft knowledge (I call it "blue fuzz"), and ask how I'd do this with just regular HTML/JavaScript. That usually produces an answer. Barring that, I try to use Request/Response objects on the server, ViewState variables or Session variables, and only as a last resort look at dynamic ASP.NET Web Controls.

My site has a view articles on ASP.NET topics that might be helpful. Of course keep ASP.NET discussions right here on DaniWeb.

Hey Thomas,
Thanks for your reply.Sorry I did not get back to you soon,things have really got busy here.Read your article on Viewstate ,It was really helpful..

Yes,the hidden variable works,I tested it..

But Its not working on page load nor init()... I put a button and it worked fine on postback...
Not sure why?

But my application is now working.I did a work around to force the event and it works...

PS:I'll remember your advice on Bluefuzz...

It probably doesn't work on Page Load, because you have no hidden variable until you click the button. Without seeing your code, I can't be sure.

But always realize, that the controls on the page, manipulated in the browser, using JavaScript, don't automatically correspond to ASP.NET server-side web controls.

It only appears that way! If you drag a textbox onto a form in Visual Studio, you are creating a "TextBox" Server control. When the ASP.NET code runs, that control CREATES or RENDERS an HTML <input> element. They are two separate things.

When you postback the page, IIS/ASP.NET RECREATEs the TextBox control, every time, and then digs back through the HTTP headers to find the <input> element and synch the two back together.

That's all wonderful, until you try to do any standard JavaScript control manipulation, such as dyamically creating hidden elements or setting values. It's like ruining a magician's beautiful card trick by shuffling the deck before giving it back to him.

Two other approaches for you to consider:

1) Set your own ViewState variables. ViewState.Add(). Server-side, set or get the value of your viewstate variable, and based on that value, Register a Script (Page.RegisterStartupScript) that contains your JavaScript. In other words, dynamically create your JavaScripts, server-side, that will run once the page is served back to the user.

2) Use Session variables.

Thanks for the words of appreciation.

I got a quick doubt,
What exactly does Page.RegisterStartupScript do?
My guess is that..
It executes the Javascript code which is declared as a string on the server side!!!!!

Questions
1.Does Postback have anything to do with Page.RegisterStartupScript..

2.Is this the was to force a Javascript to execute from the server..

Repeat this to yourself 17 times in a row:

1. ASP.NET is Server side.
2. JavaScript is Client side.


JavaScript cannot execute on the server. Page.RegisterStartupScript() is extremely simplistic. All it does is add whatever is in your second parameter, as text, to the bottom of the response stream. So it's serving your page, right? And the last thing it puts on the page, is the string in RegisterStartupScript.

If that string is in the form "<script>alert('Hello');</script>", then what will happen? When that page loads in the users browser, that script will run, and "Hello" will popup. The script ran ON THE CLIENT. However, that script was put onto the page, via ASP.NET.

What does this have to do with PostBack? Absolutely nothing at all.

Now, go back and read those first two points aloud 17 more times.

And for further reading on the topic:
Integrating client-side scripts with ASP.NET.

Thanks
I'm learning a lot from you...

Regarding the first question..
1.Postback...thanks it has nothing to do with Registerstartupscript..

I think you misconstrued my second question...

2.Is this the was to force a Javascript to execute from the server

I asked

2.Is this the was(WAY) to force a Javascript to execute FROM the server.(ASP.NET)

I did not mention ON the server side.Perhaps I should be little more specific in my question by mentioning something like
Is this the way to force a Javascript to execute from the server(ASP.NET) on
Client side..
..Sorry my fault..

So I think the answer is YES.

Thomas, you gave a good explanation.You moderators(Yourself and Paladine) are doing a great Job.I appreciate that.I can understand how annoying it feels when people ask something ambiguous and doesnt make sense.No two people think the same things and there is no way for you guys to know whats happening on the user side..

From next time I'll make my questions clear and unambiguous.. :cheesy:

Have a great weekend..

Well, in that case, yes... RegisterStartupScript is ONE WAY to insert a script into the response stream. The script will execute as soon as the browser interprets it, because it isn't placed into the document HEAD nor as part of a function definition. The main point here is that the user's browser executes the script. Your ASP.NET code just puts the script on the page.

There are other ways to assign scripts to certain client-side events. The technique I like to use is to call the "Attributes.Add()" method of specific server controls.

Try this:
<input runat="server" type="hidden" id="myHiddenVar">

With the Runat="server" you will be able to see the myHiddenVar id in the code-behind!

<anything runat="server" id="something" />

With <a runat="server"></a> you can set the href from the code-behind


1. ASP.NET is Server side.
2. JavaScript is Client side.

Today, this rule is obsolete ehehehe