Code-Behind variables

[Marco]

Is it possible to access an variables' value, using javascript
The variable is created on the code behind
What i want to know is if i give a value to an variable created in the code behind, is it possible to retvrive its value directel
, in the .aspx file by using for eg javascript

Thanks in advance

[Dan Brussee]

Server side code and client side code is totally different and
seperate. You will need to provide a client side variable with the
value from the server side. Maybe a hidden form variable?

On Fri, 5 Mar 2004 17:56:07 -0800, "Marco"
<an*******@discussions.microsoft.com> wrote:

Is it possible to access an variables' value, using javascript.
The variable is created on the code behind.
What i want to know is if i give a value to an variable created in the code behind, is it possible to retvrive its value directely
, in the .aspx file by using for eg javascript.

Thanks in advance

[Marco]

i woust to be an asp programmer, and that was i woust to do, hidden textboxes to set some values, i also know the difference between server and client code. But i tought it was possible for eg, get an variable's value in the .aspx page by using the viewsatate(), even if that variables was created in the server

Thanks again mat
;
Marco

[Scott M.]

In the code-behind:

Dim x as Integer = 10
response.write "<SCRIPT LANGUAGE='JavaScript'>"
response.write "var x = " & x
response.write "alert('The server side variable x was passed to the client
and its value is ' + x)"
response.write "</SCRIPT>"
"Marco" <an*******@discussions.microsoft.com> wrote in message
news:5D**********************************@microsof t.com...

i woust to be an asp programmer, and that was i woust to do, hidden textboxes to set some values, i also know the difference between server and
client code. But i tought it was possible for eg, get an variable's value in
the .aspx page by using the viewsatate(), even if that variables was created
in the server.
Thanks again mate
;)
Marco

[Marco]

I dont understand what you have said, its not possible to use the response.write object in the code-behind page. In my case the that page is called chat.aspx.cs, using c#.

Thanks again,
Marco

[Dan Brussee]

Notice that it is using Response.Write calls, which generates HTML. In
this case, it's Javascript code. Response.Write was used a LOT in
original ASP coding. The tags <%= and %> are actually just a shortcut
for Response.Write the code inside.

Viewstate is used by the server, and is not available for use on the
client. Modifying it's value will result in errors on the server. The
values in Viewstate are Base64 encoded, which means although it
"could" be read, it's not very easy - to put it mildly. Look at <input
type=hidden> tags. If you add the runat="server" property, you get a
..NET object to code against, but you will have to use it's Attributes
collection rather than just setting it's Value property.
On Fri, 5 Mar 2004 19:31:06 -0800, "Marco"
<an*******@discussions.microsoft.com> wrote:

I dont understand what you have said, its not possible to use the response.write object in the code-behind page. In my case the that page is called chat.aspx.cs, using c#.

Thanks again,
Marco

[Scott M.]

Of course you can use Response.Write from the code behind. Response is the
HTTPResponse object and is native to .NET. Write will write the string into
the Response stream that is being sent to the client browser. Since what
I'm writing is JavaScript, it will be sent to the browser and then the
browser will insert it into what it winds up rendering. It will function as
normal JavaScript, except that the variable "x" will have gotten its value
from the server variable "x".

It doesn't matter if you are using C# or VB.NET, the Response object is part
of the .NET Framework, not an element of any particular language.

The only thing you'd change in my code is you'd change how the server
variable was declared, capitalize according C# and add your semi-colons
where C# wants them.
"Marco" <an*******@discussions.microsoft.com> wrote in message
news:09**********************************@microsof t.com...

I dont understand what you have said, its not possible to use the response.write object in the code-behind page. In my case the that page is
called chat.aspx.cs, using c#.
Thanks again,
Marco

[Scott M.]

> Notice that it is using Response.Write calls, which generates HTML.

Well no, more accurately it simply sends TEXT to the browser (note: it may
be any value from any data-type, but it gets sent to the client as text).
The text could be anything at all (HTML, JavaScript, VBScript, XML, etc.).
The "Write" method of the "Response" object doesn't care what text you write
and it doesn't "generate" anything. It just sends what you tell it to.

The tags <%= and %> are actually just a shortcut for Response.Write the code inside.

More accurately, just the "=" used as a prefix for some expression that
results in a value that can be sent to the browser is a shortcut for
Response.Write. And, you could only use that shortcut when the script block
was only going to contain that one command (ie. <% ="Hello World" %>).

The <% and the %> are actually shorthand for <SCRIPT> and </SCRIPT>. They
are the way to indicate a server side script block.
Viewstate is used by the server, and is not available for use on the
client. Modifying it's value will result in errors on the server. The
values in Viewstate are Base64 encoded, which means although it
"could" be read, it's not very easy - to put it mildly.
It is very easy to add and read items to/from ViewState in the CodeBehind
using ViewState.Add(key, value) and ViewState.Item(key). The stored and
then read value can then be use in any way that you want to, including
sending down to the client.
Look at <input> type=hidden> tags. If you add the runat="server" property, you get a .NET object to code against, but you will have to use it's Attributes
collection rather than just setting it's Value property.

Um no. If you have marked the hidden form field as runat=server, you can
code against its .value property directly from the codebehind.

You've given several mistaken or misleading pieces of advice and/or facts
here. I suggest you read up on this or try it out before commenting.