Showing posts with label section. Show all posts
Showing posts with label section. Show all posts

Wednesday, March 28, 2012

Accessing values from dynamically created controls

Hi. I'm writing a web application that uses Atlas todynamically create controls in a specific section of a web page. I have 2 update panels. One of them contains a DropDownList. The other one will contain thedynamically created controls. The controls are created in the SelectedIndexChanged event of the DropDownList, and I coded that in the server side. All those controls are arranged in a table server control, which is also created in the SelectedIndexChanged event. The page also has a Button server control that will allow me to start processing the values entered by the user in the created controls. Of course this processing will be done in the server side. This button is not part of either update panel.

Now, the problem is that when I try to get the values of the controls in the Button Click server event, using the table.FindControl() function, I see that the table itself is null, so I cannot access any control value. I think the problem has to do with the fact that the table and its controls are created in the update panel, and for some reason everything created there is not available for my Button Click server event.

How can I solve this scenario?

Thanks,

Julio

Modifying the controls colletion during a postback is generally not a good idea in ASP.NET. Additionally, dynamically added controls will not persist through viewstate so you'll have to re-create and add them to the container on each postback.

Instead of adding/removing controls, I suggest you use the "Visible" property of the control. You can set the control.Visible=false, which will prevent it from rendering down to the client.

Hope this helps,

-Tony


Thanks a lot Tony. The problem is that the user can choose 25 different elements in my combobox, and each element will require to create/show from 1 to 20 new controls on the dynamic section of the page. So if I take your advise and just put all possible controls on the page on design view, hidding or showing them asappropriate, wouldn't it be too much overhead for my page?

Julio


Julio,

Any way you choose is going to require quite a bit of code on your end to determine when to show/hide or create/destroy controls. You are correct in that should you choose to instantiate all controls on the page load, it will indeed add extra overhead.

To acheive the results you are looking for, you'll need to test for which item is selected, and fill the update panel accordingly. The earlier this happens in the page lifecycle the better off you are. The one problem you might encounter is that replacing a control on the fly like this, could cause viewstate errors since the control which saved its viewstate in the previous response, has now been replaced with a completely different control.

We've actually built the behavior you're looking for directly into the Infragistics WebTab. It provides LoadOnDemand behavior though an AJAX mechanism. Using a Tab Interface also speeds up the development since you can separate your content into individual tabs, displaying only the relevant tab. In most cases the performance overhead incurred is well worth the development time saved. Of course, you'd need to make that call based on your own project requirements.

Hope this helps,
-Tony


Hi Tony. You are completely right. I have just found that viewstate error you mention. I have tried to control that error, but I just keep getting errors when adding/removing controls. I would like to try using Infragistics WebTab, as our company has full licenses for the NetAdvantage suite. Could you please show me a small example of how could I achieve this behavior with the WebTab and the LoadOnDemand behavior? Or maybe give me a link to an example? I would reallyappreciate it.

Thanks a lot for your help,

Julio


Hi Julio,

You'll need to getNetAdvantage 2006 Volume 2 if you don't already have it. On the WebTab, set AsyncMode=On, and AsyncOptions.EnableLoadOnDemand=True. Next, using the interactive design surface, simply drag and drop your content into the desired Tab pane. You can even switch between tabs by clicking the desired tab on the design-surface. The WebTab has UpdatePanel-like behavior built directly into it, so postbacks will automatically be turned into AJAX callbacks. The LoadOnDemand behavior will also enable the initial page load to contain only the content for the selected tab, all other tab content will be dynamically retrieved as necessary.

Hope this helps,
-Tony


Hi Tony. It seems likeUltraWebTabAJAX features won't help me. Theasync behavior I'm looking for starts outside the tab control, but not in the tabs itself. My UltraWebTab has 25 tabs inside it. I also have a dropdownlist which is outside my UltraWebTab. Now, without any AJAX behavior, what my page does is that, when you select an element in the dropdownlist I hide all the tabs except for the one that is related to the selected value on the dropdownlist. This of course causes a full roundtrip to the server.

So, what I'd like to happen is that, when I change my selection on the dropdownlist, all the not related tabs just become invisible, but with no roundtrip. I enabled all the async options you mentioned, but I thing they are mostly targeted for the scenarios where the user navigates between tabs, and no with my particular scenario. So I just thought I could solve this by adding an Atlas UpdatePanel and putting the UltraWebTab inside it. I also added a trigger to the panel so that any time the dropdownlist change its value, the updatePanel would update its contents.

Here is the code for my DropDownList:

<table>

<tr>

<tdstyle="width: 3px"valign="top">

<asp:DropDownListID="MyDropDownList"runat="server"AutoPostBack="True"DataSourceID="MyDataSource"DataTextField="Description"DataValueField="Id"></asp:DropDownList><asp:ObjectDataSourceID="MyDataSource"runat="server"SelectMethod="GetMyItems"TypeName="MyProduct.MyClass"></asp:ObjectDataSource></td>

</tr>

</table>

...And this is the code for the UltraWebTab and the UpdatePanel:

<table>

<tr><tdstyle="width: 239px; height: 101%;"valign="top"><atlas:UpdatePanelID="Up1"runat="server"Mode="conditional"><ContentTemplate><igtab:UltraWebTabID="MyUltraWebTab"runat="server"BorderColor="#949878"BorderStyle="Solid"BorderWidth="1px"ThreeDEffect="False"SelectedTab="16"AsyncMode="On"><DefaultTabStyleBackColor="#FEFCFD"Font-Names="Microsoft Sans Serif"Font-Size="8pt"ForeColor="Black"Height="22px"><PaddingTop="2px"/></DefaultTabStyle><Tabs>

<!--Here comes my Tabs and controls -->

</Tabs><RoundedImageFillStyle="LeftMergedWithCenter"HoverImage="[ig_tab_winXP2.gif]"LeftSideWidth="7"NormalImage="[ig_tab_winXP3.gif]"RightSideWidth="6"SelectedImage="[ig_tab_winXP1.gif]"ShiftOfImages="2"/><SelectedTabStyle><PaddingBottom="2px"/></SelectedTabStyle><BorderDetailsColorBottom="90, 120, 160"ColorRight="90, 120, 160"/><AsyncOptionsEnableLoadOnDemand="True"/></igtab:UltraWebTab></ContentTemplate><Triggers><atlas:ControlValueTriggerControlID="MyDropDownList"PropertyName="SelectedValue"/></Triggers></atlas:UpdatePanel></td>

</tr>

But now I'm just getting an "Unknown Error" popup window every time I change my selection in the dropdownlist. It seems like any combination of UltraWebTab and UpdatePanel just does not work. I have already written Atlas apps with my current installation (June CTP) and they work fine until I add an UltraWebTab. All Atlas configurations in the web.config and the script manager are on place, so it should work.

Is there a known compability issue between UltraWebTab and UpdatePanel? If it is, is there any way I could achieve my desired behavior with UltraWebTab async and loadOnDemand options?

Thanks a lot,

Julio


Hi Julio,

You should contact Infragistics Developer Support and provide them the details above. A hotfix was made available on Friday, July 28th which may address this issue.

-Tony

Monday, March 26, 2012

Accessibility

When people talk about Accessibility, I think of Section 508 and allowing
blind/disabled people to use an application. I put this small test of Atlas
together for a blind friend of mine to test. It is at
http://216.187.235.116/atlassection508test/. It seems that the applications
runs find and he is able to see/hear the content using JAWS
(www.freedomscientific.com). So, the question is, what's the cause of the
accessibility discussion with Atlas? What are the issues? I hear
discussion but not statement of the issues.

Wally

--
Wallace B. McClure
"The Harder I Work, the Luckier I Get."
Listen to "The ASP.NET Podcast" at http://www.aspnetpodcast.com/
Database Award: http://url123.com/vc3er
Microsoft MVP - Visual Developer ASP/ASP.NET
AspInsider
"AJAX for ASP.NET" Coming Soon!
ADO.NET Book: http://url123.com/vc2bu
865-693-3004
118 Durwood Rd.
Knoxville, TN 37922
http://www.scalabledevelopment.com/
Blog: http://weblogs.asp.net/wallym/Oops, I missed Bertrand's post on the subject. Thanks.

Wally

wrote in message news:1155492@.66.129.67.202...
> When people talk about Accessibility, I think of Section 508 and allowing
> blind/disabled people to use an application. I put this small test of
> Atlas
> together for a blind friend of mine to test. It is at
> http://216.187.235.116/atlassection508test/. It seems that the
> applications
> runs find and he is able to see/hear the content using JAWS
> (www.freedomscientific.com). So, the question is, what's the cause of the
> accessibility discussion with Atlas? What are the issues? I hear
> discussion but not statement of the issues.
>
> Wally
>
> --
> Wallace B. McClure
> "The Harder I Work, the Luckier I Get."
> Listen to "The ASP.NET Podcast" at http://www.aspnetpodcast.com/
> Database Award: http://url123.com/vc3er
> Microsoft MVP - Visual Developer ASP/ASP.NET
> AspInsider
> "AJAX for ASP.NET" Coming Soon!
> ADO.NET Book: http://url123.com/vc2bu
> 865-693-3004
> 118 Durwood Rd.
> Knoxville, TN 37922
> http://www.scalabledevelopment.com/
> Blog: http://weblogs.asp.net/wallym/
>

Accessibility

I've been talking with a friend of mine that is involved with Section 508.
I have been reading about percieved issues with Section 508 accessibility
and developing ajax style applications. I have read percieved problems with
ajax style applications. does anyone have any experience in this area and
what info can you share?

Wally

Any web application that modifies the DOM dynamically faces a few accessibility challenges.

For example, it's not easy to tell the screen reader that parts of the display changed. Some screen readers and browsers will actually cache parts of the page, which makes it almost impossible to get the updated display to be read. We're actively working on this problem.

The postback situation of non-Ajax application is actually not much better as the screen reader is faced with a completely new page all the time and it's difficult for the user to figure out what he needs to re-read.

Keyboard accessibility can actually be made much better by using a framework like Atlas. For example, the listView and itemView controls are keyboard accessible by default and behave like their Windows equivalents as much as possible. Unfortunately, this only works on IE for the moment. We're working on Firefox 1.5 support (other browsers for the moment don't have the necessary infrastructure).

All in all, I'd say that accessibility problems are only starting to get solved on the Web (Firefox only included accessibility features in version 1.5, which is only a few weeks old, and Safari to this day still ignores the issue). There are some cases where the Atlas framework can actually make things much better, but we'll also need improvements in browser and screen reader technology.


Bertrand,

Thanks for the info! :-)

I have had a discussion with Freedom Scientific, the makers of JAWS, about
accessibility with Atlas. They said that JAWS will use what they call
"forms mode." when working with forms. In forms mode, JAWS does not cache
the page. I put together a very small sample at
http://216.187.235.116/atlassection508test/. Some blind friends of mine at
the US Government looked through the application and felt that things were
find. If you have any suggestions regarding things to do, I would love to
hear them.

Wally

wrote in message news:1153749@.66.129.67.202...
> Any web application that modifies the DOM dynamically faces a few
> accessibility challenges.
>
> For example, it's not easy to tell the screen reader that parts of the
> display changed. Some screen readers and browsers will actually cache
> parts of the page, which makes it almost impossible to get the updated
> display to be read. We're actively working on this problem.
>
> The postback situation of non-Ajax application is actually not much better
> as the screen reader is faced with a completely new page all the time and
> it's difficult for the user to figure out what he needs to re-read.
>
> Keyboard accessibility can actually be made much better by using a
> framework like Atlas. For example, the listView and itemView controls are
> keyboard accessible by default and behave like their Windows equivalents
> as much as possible. Unfortunately, this only works on IE for the moment.
> We're working on Firefox 1.5 support (other browsers for the moment don't
> have the necessary infrastructure).
>
> All in all, I'd say that accessibility problems are only starting to get
> solved on the Web (Firefox only included accessibility features in version
> 1.5, which is only a few weeks old, and Safari to this day still ignores
> the issue). There are some cases where the Atlas framework can actually
> make things much better, but we'll also need improvements in browser and
> screen reader technology.
>

That is very interesting information. We're still figuring all this out. I'd also say that with any Web technology, an application that cares about accessibility should be structured differently, more hierarchically, with shorter screens that present less information units at a time.

About Jaws, did your contact mention how to switch to forms mode? Is it something that needs to be enforced by the screen reader authors or something that the page itself can suggest through markup? Is it just triggered by the presence of form fields on the page (because if that's the case I think I have a bug report for them...)?