Update() seems to do the trick, but I'm confused. I thought Render() for a component was supposed to render the control as it was, but it's appearing to only useful for containers. And if so, why is it supported at the BaseControl level?
Hi @michaeld,
Yes, the Render method should work on the BaseControl level. Though, in this case with Buttons it cannot determine a correct container to render it to.
We will investigate a possibility to do something with that.
There are two options for now:
1. Use ReRender instead.
2. Specifying more explicit container for the Button. I.e. using DockedItems instead of Buttons.
Code:<DockedItems>
<ext:Toolbar ID="Toolbar1" runat="server" Dock="Bottom" UI="footer">
<Items>
<ext:Component runat="server" Flex="1" />
<ext:Button ID="Button1" runat="server" Text="Click" OnClientClick="App.direct.Click();" />
</Items>
</ext:Toolbar>
</DockedItems>
I'm guessing this is an issue at the extjs or ext.net level?
The only way I can figure you'll be able to overcome this difficulty is pass an added variable to the client response for all buttons in the buttons collection that you can test and handle. You are still considering a solution? I wasn't sure after your last msg.
I assume you mean of the entire LP container. That's not always possible if the contents
Honestly, I hope they get rid of the buttons, topbar, and bottombar sections in extjs because it seems an obsolete concept since dockeditems.
On the Ext.NET level.
Yes, I think there is a solution.
I am not sure. There are many places that would require a similar change. For example, if you call the Render method on a Toolbar inside a Panel's TopBar, it will probably break as well. So, it is not that easy to fix it across all the library.
No, I meant calling that on the Button. It appears to be working, doesn't?
Well, they are just shorthands to go to DockedItems. Could you, please, clarify, why do you hope it will go away?
The shorthands are fine but I think it makes us lazy. Plus it makes it possible to duplicate sections (eg. bottombar and buttons). And most importantly because you said this. "So, it is not that easy to fix it across all the library." If it's shorthand for dockeditems, I'm still confused how the items then are not in the Items section making the bug go away? I suspect that the reason is because it only does it sorta.
Anyway, this isn't a big deal for me personally. It is far from pressing as there are solutions. I just wanted you guys to at least know about the inconsistency and the issue. I doubt someone else will run into this one for awhile, but if they do, maybe consider it higher priority then?
Fair enough. Though, there are many other similar collections which are not just shorthands.
Because there is already a certain container with the representation on server:
The Button is rendered to this Toolbar1.Code:<ext:Toolbar ID="Toolbar1" runat="server">
Yes, you are right. If this appears again on the forums, we will re-consider it. Though, it is quite rare case when someone re-renders such a little UI things as Buttons.
I think from reading other posts in the forums by some of the advanced users, it's not as uncommon as you may think. A few are rerendering buttons to update listeners. I know we together worked through getting some additions to allow the direct update of listeners, but still, the consensus seemed that the fastest most reliable way was rerendering the entire component, especially if there were other changes (like to Text) as well. Also, I'm doing it a lot more since switching to No-refresh pages and full ajax replacement of containers (destroy-and-render) and individual controls more too when I want faster performance and smaller responses.
Yes, just re-rendering a Button is not that rare. But re-rendering it when it is in a Buttons collection is quite rare:)