You are currently browsing the category archive for the ‘.NET’ category.

I stumbled upon another issue. I am sure there is a good reason they decided to not allow this, but I found it quite frustrating to learn it the hard way. Server Control tags, like for a button, or TextBox or any other server control, can not contain .net code <% … %>. For example:

<asp:Button ID=”btnRefreshLayout” runat=”server” Text=”Refresh Layout” OnClientClick=”AdjustFrameDim(<%= _layout%>);” OnClick=”btnRefreshLayout_Click” />

The result is…

<input type=”submit” name=”btnRefreshLayout” value=”Refresh Layout” onclick=”AdjustFrameDim(<%= _layout%>);” id=”BI_TabControl1_ucLayout_btnRefreshLayout” />

It doesn’t seem to matter where in the server control code you put the <% … %>, it doesn’t work.

BUT, I have good news… If you need to dynamically add something to the properties of the server control, you could instead use the AddAttribute method of the server control and get the needed results that way.

btnRefreshLayout.Attributes.Add(“OnClick”, “AdjustFrameDim(“ + _layout + “);”);

Happy Coding.

Advertisements

I am not sure I gave this post an appropriate title, but it works for now.

The Problem:
ASP.Net gives a developer the opportunity to programmatically add controls to a web form using ParentControl.Controls.Add(new Control()); However, these controls are not persisted in any way thus having to be recreated for each subsequent request.

What I found:
On the page I have a PlaceHolder. Depending on the dynamic data at the time of processing, one of 10 “layout” UserControls need to be added to the PlaceHoder. And inside each of those “layouts” will be 2 to 4 “content” UserControls with dynamic data based on the data and properties set by the “layout” UserControl. While stepping Read the rest of this entry »

More issues with Atlas and your own client javascript.

Today I stumbled accross another isse of my own JavaScript causing errors with Atlas. Typically you place all your JavaScript in the HEAD of the document. So.. today I added the following function to my JavaScript in the HEAD of the page.

javascript_form_submit

Atlas - Unknown ErrorAfter adding this code, any click on the page that used an Atlas Update Panel, caused the discreet Unknown Error dialog box. After many attempts to discove what the problem may be, I moved the entire function to script tags with-in the BODY of the page. All worked fine, with no Atlas “Unknown Error”.

I decided to test another sceniario, and put all my JavaScript in an external file (I usually wait till I am finished with the page for this step) and included it from with-in the HEAD of the page. Again I tested the page and all worked fine with no Atlas “Unknown Error”.

I thought this error may have something to do with the partial rendering that Atlas is taking care of, but after my second test, I an not so sure any more. Either way, I believe it may be a better practice to put all JavaScript in an external .js file and include it in the HEAD of your page.

I found another issue using Atlas the other day. I was using Atlas UpdatePanel around a TreeView and had some java-script functions on the page elsewhere. All was going fine Tuesday evening, then Wednesday morning, I started getting a what appeared to be a java-script error message.

Atlas - Unknown Error

When debugging, I was able to confirm that Atlas was working, I could step through my server code and populate the tree, but when execution was back at the browser, I would get this error pop-up “Unknown Error”.

I had made very little changes that morning, but due to closing the file earlier, I was unable to use the Undo function. After much time and testing, I remembered that in the HEAD of the HTML document, I had added another java-script function and noticed that the <script> tag did not have the language set, so I had set language=javascript. In Visual Studio 2005, the context sensitive help is great, and after typing language= it prompts with a choice of languages, and when you choose the language it adds it to your code with out quotes.

Now most of the time I have found that it doesn’t matter if you have quotes or not around your values. But this time it made a big difference. I added the double quotes around javascript and tested the page again, and this time there was no error and everything worked fine.

Intrigued by this finding, I did some more testing and found that if I put the SCRIPT tags with java-script functions just below the BODY tag, it did not matter if I used language=javascript or language=”javascript”, both ways worked just fine with Atlas.

So, in the HEAD of the HTML document, I needed to use language=”javascript”, but in the BODY of the HTML, double quotes didn’t seem to matter.

Also, see my post in this thread:
http://forums.asp.net/thread/1363655.aspx

In the past few days I have learned that with Atlas, it makes a difference if you put your CSS style information in a class in an external CSS document or code it inline in the HTML element.

I had been using an Atlas UpdatePanel wrapper around a TreeView server control all inside a DIV tag. The DIV tag was using a CSS class to set the width, height and overflow styles. Durring testing, I noticed that when the tree expanded and the scroll bars apeared, every click of a node in the tree made scrolled the content back to the top of the tree. I had done a similar Atlas/TreeView in another page and it worked just fine. After some further debugging and code comparison line by line, the difference was that in my working example the CSS information was “in-line” with the DIV tag, but my recent code put the CSS style in an external class. So I moved the style from the class to “in-line” and it began to work just fine.

I am not sure if this is another IE bug, CSS bug or an Atlas bug. Either way, quite interesting and thought I would share it.

Also see my post in this thread:
http://forums.asp.net/2/1268514/ShowThread.aspx



Update
:

TreePopUpOverlay

It appears that the CSS can be inline or in external CSS file, it makes no difference, but the real issue was if the class with overflow=auto is inside or outside the Atlas UpdatePannel. IF you have a DIV with a CSS style setting overflow=auto inside the UpdatePannel, every click within that div will set the scroll to the top. IF you have put that DIV right outside the UpdatePannel, then it should work fine.This also goes for any parent/nested UpdatePanels. So, if the UpdatePannel I just refrenced in the last paragraph were nested inside another UpdatePanel, or I at a later date put that UpdatePannel inside another UpdatePanel, it would “break” the proper scrolling function.

So to produce the popup dialog on the right, and have the red X and the [Close] button work in an UpdatePannel, instead of wrapping everything inside another UpdatePannel, I would have to have one UpdatePannel for the red X close button and one UpdatePannel for the [Close] button at the bottom. See code image below.

treepopupoverlay.txt