Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-2916 in 3.1 beta.
  1. #11
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,634
    Vote Rating
    79
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    Have you tried with a newer version? I'm unable to reproduce this in GXT 3.0.4 with the following test case:

    Code:
    public class DisabledHtmlEditorInDialog implements EntryPoint {
    
      @Override
      public void onModuleLoad() {
        final Dialog d = new Dialog();
        final HtmlEditor e = new HtmlEditor();
        d.setWidget(e);
    
        RootPanel.get().add(new TextButton("Disable HtmlEditor", new SelectHandler() {
          @Override
          public void onSelect(SelectEvent event) {
            e.setEnabled(false);
          }
        }));
        RootPanel.get().add(new TextButton("Enable HtmlEditor", new SelectHandler() {
          @Override
          public void onSelect(SelectEvent event) {
            e.setEnabled(true);
          }
        }));
        RootPanel.get().add(new TextButton("Show Dialog", new SelectHandler() {
          @Override
          public void onSelect(SelectEvent event) {
            d.show();
          }
        }));
    
      }
    
    }
    Tested in Chrome and Firefox.

    That said, in my initial testing, I also can't reproduce this issue in 3.0.1 with the above test case. To be clear, my steps to reproduce are this:
    1) Click Disable HtmlEditor
    2) Click Show Dialog
    3) Observe that the dialog shows without any error
    4) Click Enable HtmlEditor, Disable HtmlEditor to verify these operations work without issue after visible as well.
    5) Click the X icon to close the dialog, and once again try each action before opening the dialog again.

    Am I missing a step, or are there specifics about your use case that cause this to happen, such as configuration options?

  2. #12
    Sencha User
    Join Date
    Nov 2010
    Posts
    90
    Vote Rating
    0
    atrubka is on a distinguished road

      0  

    Default


    setEnabled() has to be invoked before the first show and it must be compiled. Dev version works fine.

  3. #13
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,634
    Vote Rating
    79
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    Sorry about that, my first round of tests was dropping the errors instead of reporting them. I've confirmed the issue, and moved this thread to the bug forum. It will be updated when we have a fix to report.

    For now, here is a workaround. Override onDisabled of HtmlEditor, and replace it with these contents:
    Code:
      @Override
      protected void onDisable() {
        //Component.onDisable
        if (disabledStyle != null) {
          addStyleName(disabledStyle);
        }
        if (toolTip != null) {
          toolTip.disable();
        }
        //tweaked HtmlEditor.onDisable
        XElement textAreaElement = getElement().selectNode("textarea");
        if (textAreaElement != null) {
          textAreaElement.disable();
        }
        textArea.setEnabled(false);
      }
    Simplified test case with workaround:

    Code:
    public class DisabledHtmlEditorInDialog implements EntryPoint {
    
      @Override
      public void onModuleLoad() {
        final Dialog d = new Dialog();
        final HtmlEditor e = new HtmlEditor() {
          @Override
          protected void onDisable() {
            //Component.onDisable
            if (disabledStyle != null) {
              addStyleName(disabledStyle);
            }
            if (toolTip != null) {
              toolTip.disable();
            }
            //tweaked HtmlEditor.onDisable
            XElement textAreaElement = getElement().selectNode("textarea");
            if (textAreaElement != null) {
              textAreaElement.disable();
            }
            textArea.setEnabled(false);
          }
        };
        d.setWidget(e);
    
        e.setEnabled(false);
        d.show();
      }
    }

  4. #14
    Sencha User
    Join Date
    Nov 2010
    Posts
    90
    Vote Rating
    0
    atrubka is on a distinguished road

      0  

    Default


    The patch allows HtmlEditor to work without exceptions, but the editor doesn't actually get disabled.
    One can type in there.

  5. #15
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,634
    Vote Rating
    79
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    Thanks for the feedback - it turns out that the select("textarea") is trying to clean up the 'source mode' view, which may or may not exist yet, which is why that NPEs.

    The new issue, that it is still editable even when disabled, is due to the underlying RichTextArea widget re-setting itself back to enabled when it is added to the page and focused. This is a defect in GWT itself - I'm looking to see if there is a clean way to work around this in the library, otherwise I'll submit a patch to GWT and try to make another workaround here.

    The bug only occurs in firefox (at least I can't reproduce this part of the bug in IE or Chrome) because the issue is in the mozilla-specific implementation of RichTextArea. com.google.gwt.user.client.ui.impl.RichTextAreaImplMozilla.initElement():
    Code:
      @Override
      public native void initElement() /*-{
        // Mozilla doesn't allow designMode to be set reliably until the iframe is
        // fully loaded.
        var _this = this;
        var iframe = _this.@com.google.gwt.user.client.ui.impl.RichTextAreaImpl::elem;
        _this.@com.google.gwt.user.client.ui.impl.RichTextAreaImplStandard::onElementInitializing()();
        _this.@com.google.gwt.user.client.ui.impl.RichTextAreaImplMozilla::isFirstFocus = true;
    
        iframe.onload = $entry(function() {
          // Some Mozillae have the nasty habit of calling onload again when you set
          // designMode, so let's avoid doing it more than once.
          iframe.onload = null;
    
          // Don't set designMode until the RTA is targeted by an event. This is
          // necessary because editing won't work on Mozilla if the iframe is
          // *hidden, but attached*. Waiting for an event gets around this issue.
          //
          // Note: These events will not conflict with the
          // addEventListener('oneventtype', ...) in RichTextAreaImplStandard.
          iframe.contentWindow.onfocus = function() {
            iframe.contentWindow.onfocus = null;
            iframe.contentWindow.onmouseover = null;
            iframe.contentWindow.document.designMode = 'On';
          };
    
          // Issue 1441: we also need to catch the onmouseover event because focus
          // occurs after mouse down, so the cursor will not appear until the user
          // clicks twice, making the RichTextArea look uneditable. Catching the
          // mouseover event allows us to set design mode earlier. The focus event
          // is still needed to handle tab selection.
          iframe.contentWindow.onmouseover = iframe.contentWindow.onfocus;
    
          // Send notification that the iframe has finished loading.
          _this.@com.google.gwt.user.client.ui.impl.RichTextAreaImplStandard::onElementInitialized()();
        });
      }-*/;
    The bolded lines are the ones that are causing this particular case. You can confirm this through the following steps (assuming you have spell check enabled in your browser) using the sample app I've mentioned already (with the null check workaround in place):
    * Draw the HtmlEditor/RichTextArea, and allow it to be edited
    * Type in something which is spelled wrong - observe that it is underlined
    * Disable the editor, observe that the underline goes away
    * Hide the dialog and then show it again - observe that the underline is gone
    * Mouse over the editor - as soon as the mouse gets over it, the underline will reappear, indicating that the above handler has gone off and the bug has occurred.

  6. #16
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,634
    Vote Rating
    79
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    We've made some specific changes to GXT to work around the GWT issue that should ensure that this always work correctly. These changes are in SVN and will be in tonight's nightly build, as well as the upcoming 3.1 beta release.

  7. #17
    Sencha User
    Join Date
    Nov 2010
    Posts
    90
    Vote Rating
    0
    atrubka is on a distinguished road

      0  

    Default


    Thanks a lot. I look forward to that!

Thread Participants: 2

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar