This series of articles is about ASP.NET. They are from my previous years, legacy notes on OneNote. Reviewing the concepts may be helpful even for our current programming because they have a lot of similar features, such as, Angular, React, and these modern "language".
A. Introduction
This is a debugging related to the Page Life Cycle that can be a good example to review the Page Life Cycle in time, even in space (distributed in code written and in code execution).
- A. Introduction
- B. Problem
- C. Solution in Concept and Issue
- D. Reason
- E. Solution
- F. Summary
B. Problem
This is a legacy ASP.NET application; it must be in ASP.NET 1 or 2. The requirement is to change the login layout; say, the tiny requirement is to make the password bottom line red when the error message is like "username or password is incorrect".
![pwd Incorrect]()
C. Solution in Concept and Issue
We need to catch the
- Condition, the words: "username or password is incorrect." and the
- Target element.
We had no difficulty catching the later one, however, we could not catch the first element. We search the words"username or password is incorrect." and the Element ID in
- .aspx page in the ASP.NET markup
- .aspx.vb, the code behind
- and globally for JavaScript
Even if we can get the Element ID, we cannot catch the words. One judgment is the words are stored in the Database. On the other hand, we made a dynamic search by debugging; we can catch Both Words and Element ID when debugging, such as like
![code]()
However, if we try to write JavaScript in the code, we can only get an empty Element without the error message words. Tricky? Right.
D. Reason
We used both server-side debugging and client-side debugging, then found out the error is handled by the code behind; the reason that we cannot catch it by search is because the code emitted
![ajaxRequest]()
The reason that we cannot catch it by search is because the code emitted is not according to the Element ID, but the class definition associated with the Element:
![requestAjax1]()
In this way, not only can the given login be handled by this error message, but all other logins in different places also can be handled, such as Mobil Access.
E. Solution
Finally, we found out the error message is not directly inserted into an Element, but a line of JavaScript, emitted into the frontend by ClientScript.RegisterStartuupScript method. That is the reason why we can catch the error message when using client-side debugging but never can handle it by any JavaScript written in the code.
In the Page Life Cycle, whatever happens at any time,
- RegisterStartupScript: Emits just before the closing tag of the Page object.
This ASP.NET application must be written in ASP.NET 2.0 or later; it has a master page with an html and body tag, while other pages are just inserted Control in the master page. So, in our case, we write any JavaScript error handling in the Login.aspx page, they are not at the position of the closing tag of the Page Object, and we cannot catch the emitted code byRegisterStartupScript.
Therefore, the solution is two, Writing the proposed error handling, either
- At the bottom of the master page, better below the Page tag, or
- Inserted from the location by the same method:RegisterStartupScript,that will be dynamically emitted into the code before the Page tag.
F. Summary
For an unkown app, from this example, we can get the debugging skils as
- Static Debugging --- Search in Space distribution
- in the .aspx Page for the either
- Server Side Controls --- ASP.NET Controls
- Client Side Controls --- HTML Controls
- in the Code behind page
- Server Control Definition
- Code in Event Handling
- in other files, such as independent .js file and .css file
- Element ID
- Class Name
- CSS Element, such as Background Color
- Dynamic Debugging --- Search in Time sequence distribution
- Server Side debugging --- Code Behind
- Client Side debugging --- JavaScript and DOM
- Time and Space of dynamic Emmited code
References