Firing JavaScript methods from code behind

[Guest]

Group,

How would I go about firing a JavaScript method from a C# method in the aspx code behind file? It seems as though this could not be done since JavaScript is executed from within the Web browser and C# is executed on the server.

Thanks for your consideration,
Jim

 

[Peter Rilling]

You are correct. But, you can add some conditions to your code-behind that
will output the correct JavaScript calls so that when the page renders, it
can run your code.

Group,

How would I go about firing a JavaScript method from a C# method in the

aspx code behind file? It seems as though this could not be done since
JavaScript is executed from within the Web browser and C# is executed on the
server.

 

[Guest]

One solution is to add an JavaScript onLoad event to the BodyTag of the Page. This gets messy quickly as you have to get rid of the onLoad as the page posts-back or it will keep firing repeatedly.

Best practice is try to not mix the two contexts. Coordinating the form submit, client side JavaScript, .NET's own JavaScript that it renders with certain controls, and server side page processing is dicey at best. Try to keep it simple and use multiple pages or something unless the boss demands that it "pop-up" just so...

Andyz MCSD.NET

 

[Eliyahu Goldin]

Strongly disagree with the last paragraph. It's impossible to make a fast
ASP.NET application without good deal of client scripting and client-server
coordination.

Eliyahu

One solution is to add an JavaScript onLoad event to the BodyTag of the

Page. This gets messy quickly as you have to get rid of the onLoad as the
page posts-back or it will keep firing repeatedly.

Best practice is try to not mix the two contexts. Coordinating the form

submit, client side JavaScript, .NET's own JavaScript that it renders with
certain controls, and server side page processing is dicey at best. Try to
keep it simple and use multiple pages or something unless the boss demands
that it "pop-up" just so...

 

[Guest]

I agree with you, but I beg to differ. Take a quick look at a public domain solution to the pop-up calendar problem.

REF: http://www.csharphelp.com/archives3/archive563.html
This author has made a pretty good use of the coordination between contexts. But, as you notice, and not horrendously, but he is already using the __doPostBack functions. I urge you to find the Microsoft documentation that references this function publicly. I think that going deep into those .NET internal functions is just asking for trouble as the framework is enhanced and changed and your code breaks due to "__DoPostBack" being deprecated.

I agree the "power" apps are going to push the limits and use all kinds of techniques to achieve the desired effect. I think the compromise must be made between development time, functionality and future compatibility/maintainability.

My bet is on using what Microsoft has provided (namely CodeBehind) which allows for an Object Oriented view of an inherently 'chatty' client-server browser based application.

Andrew

 

[Guest]

Notice that changes in the framework are making these kinds of tricks unnecessary and true to form, the __DoPostBack was changed in 1.1 causing some kind of problem...


http://weblogs.asp.net/vga/archive/2004/03/01/NoMoreHijackingOfDoPostBackInWhidbey.aspx

http://devhawk.net/art_submitfirefixup.aspx

Andrew S.

 

[Eliyahu Goldin]

Andrew,

I agree with you, one should avoid hacker-style programming. I actually
never use __doPostBack. My ASP.NET experience started from writing a few
heavily server- and code behind-oriented applications. They were slow and
GUI was bad. That was due to lack of experience with client side and clear
understanding client-server coordination. Now I tend to load the client-side
with more and more tasks. My client-side is evolving from just a set of
separate scripts to a design layer with its own infrastructure. The improve
is dramatic. My web apps are comparable to window forms ones in speed and
more attractive in GUI. The development indeed takes longer, but I am sure
the development tools for client side will improve.

Happy programming,

Eliyahu

I agree with you, but I beg to differ. Take a quick look at a public

domain solution to the pop-up calendar problem.

REF: http://www.csharphelp.com/archives3/archive563.html
This author has made a pretty good use of the coordination between

contexts. But, as you notice, and not horrendously, but he is already using
the __doPostBack functions. I urge you to find the Microsoft documentation
that references this function publicly. I think that going deep into those
..NET internal functions is just asking for trouble as the framework is
enhanced and changed and your code breaks due to "__DoPostBack" being
deprecated.

I agree the "power" apps are going to push the limits and use all kinds of

techniques to achieve the desired effect. I think the compromise must be
made between development time, functionality and future
compatibility/maintainability.

My bet is on using what Microsoft has provided (namely CodeBehind) which

allows for an Object Oriented view of an inherently 'chatty' client-server
browser based application.