[CLOSED] Serious? Button not Rendering properly in DirectMethod.

  1. #1

    [CLOSED] Serious? Button not Rendering properly in DirectMethod.

    Last edited by Daniil; Feb 18, 2014 at 3:41 AM. Reason: [CLOSED]
  2. #2

    Confusion.

    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?
  3. #3
    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.
    <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>
  4. #4
    Quote Originally Posted by Daniil View Post
    Yes, the Render method should work on the BaseControl level.
    Discussed with Vladimir: it is supposed to be working inside the Items collection only.
  5. #5
    Quote Originally Posted by Daniil View Post
    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.
    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.

    Quote Originally Posted by Daniil View Post
    There are two options for now:
    1. Use ReRender instead.
    I assume you mean of the entire LP container. That's not always possible if the contents

    Quote Originally Posted by Daniil View Post
    2. Specifying more explicit container for the Button. I.e. using DockedItems instead of Buttons.
    <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>
    Honestly, I hope they get rid of the buttons, topbar, and bottombar sections in extjs because it seems an obsolete concept since dockeditems.
  6. #6
    Quote Originally Posted by michaeld View Post
    I'm guessing this is an issue at the extjs or ext.net level?
    On the Ext.NET level.

    Quote Originally Posted by michaeld View Post
    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.
    Yes, I think there is a solution.

    Quote Originally Posted by michaeld View Post
    You are still considering a solution? I wasn't sure after your last msg.
    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.

    Quote Originally Posted by michaeld View Post
    I assume you mean of the entire LP container. That's not always possible if the contents
    No, I meant calling that on the Button. It appears to be working, doesn't?

    Quote Originally Posted by michaeld View Post
    Honestly, I hope they get rid of the buttons, topbar, and bottombar sections in extjs because it seems an obsolete concept since dockeditems.
    Well, they are just shorthands to go to DockedItems. Could you, please, clarify, why do you hope it will go away?
  7. #7
    Quote Originally Posted by Daniil View Post
    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.

    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?
  8. #8
    Quote Originally Posted by michaeld View Post
    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."
    Fair enough. Though, there are many other similar collections which are not just shorthands.

    Quote Originally Posted by michaeld View Post
    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.
    Because there is already a certain container with the representation on server:
    <ext:Toolbar ID="Toolbar1" runat="server">
    The Button is rendered to this Toolbar1.

    Quote Originally Posted by michaeld View Post
    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?
    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.
  9. #9
    Quote Originally Posted by Daniil View Post
    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.
  10. #10
    Yes, just re-rendering a Button is not that rare. But re-rendering it when it is in a Buttons collection is quite rare:)

Similar Threads

  1. Replies: 7
    Last Post: May 22, 2015, 8:03 AM
  2. [CLOSED] Button Icon not rendering properly
    By pawangyanwali in forum 2.x Premium Help
    Replies: 4
    Last Post: Nov 13, 2012, 6:03 AM
  3. Replies: 2
    Last Post: Oct 01, 2012, 8:16 AM
  4. Replies: 2
    Last Post: Feb 21, 2011, 5:22 AM
  5. Replies: 3
    Last Post: Jan 12, 2010, 11:53 AM

Posting Permissions