Results 1 to 6 of 6

Thread: Uncaught Ext.Error: Registering duplicate id "XXXXXX" with this manager

  1. #1
    Ext JS Premium Member
    Join Date
    Mar 2010
    Location
    Switzerland
    Posts
    30
    Answers
    1

    Default Answered: Uncaught Ext.Error: Registering duplicate id "XXXXXX" with this manager

    Hi, I have developed an application that is in production use for about 9 months now and works very well. Recently, I upgraded it to ExtJS 4.1 without any major issues. I have now created a customized deploy version of the Ext JS library using the Sencha SDK Tools. When I run my application with the customized ExtJS library I observe an exception "Registering duplicate id":

    Uncaught Ext.Error: Registering duplicate id "email_admin_TEAMUP_SETTINGS_GENERAL_SETTINGS_EDITOR_FORM1" with this manager app-all.js:6


    The id shown in the exception message "email_admin_TEAMUP_SETTINGS_GENERAL_SETTINGS_EDITOR_FORM1" is the id of a text form field. So for some reason the same id seems to be used twice even though I don't see how or where. The really puzzling thing and the reason for my post is this: Why would this error only occur with the custom build of ExtJS and not when I load the entire ExtJS library? If this was a clear case of using the same ID twice I would expect to see this exception also with the full build of the ExtJS library. Both Firefox/Firebug and Chrome report this exception.

    Does anyone have an idea how this behavior can be explained? How come the custom build of ExtJS behaves differently? Could there be anything missing in the custom build of ExtJS? If so, wouldn't there be an error about a mssing class? Any ideas on how to further debug this?

    Thanks for any feedback
    Gabe
    Check out Teamup Calendar - Easy-to-use planner and calendar built on Ext JS

  2. Hi Evan and Scott,
    Thanks for your feedback. I was able to solve this issue. It was due to the fact that the Sencha SDK tool by default does not remove debug code when it generates a minimized and compressed build. This has to be configured explicitly.

    Another interesting discovery is that the extjs debug builds do not contain debug code. Only the dev build does.

    I posted my findings in more details in this post: http://www.sencha.com/forum/showthre...734#post845734

    Thanks for your help
    Gabe

  3. #2
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,250
    Answers
    758

    Default

    The built version doesn't have the warnings, only the dev versions.

    Would suggest you look at the stack trace when it throws the exception, should be easy enough to track down when it's being registered a second time.
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  4. #3
    Ext JS Premium Member
    Join Date
    Mar 2010
    Location
    Switzerland
    Posts
    30
    Answers
    1

    Default

    Hi Evan, thanks for your feedback.

    > The built version doesn't have the warnings, only the dev versions.

    What exactly do you mean? Do custom builds have certain classes missing related to warnings? Which ones? In production use the application has been using the minimized ext-all.js and that has been working flawlessly for months. So I am wondering why exactly is the exception thrown with a custom built library of extjs and not with the full ext-all.js?

    > Would suggest you look at the stack trace when it throws the exception,
    > should be easy enough to track down when it's being registered a second time.

    Unfortunately the duplicate id problem is related to a conceptual approach taken by the application and cannot be changed quickly. It is not a simple case of having two objects with the same id. Rather, an old form seems not to be cleaned up properly before a new instance of the same form is created. Since the application works with the full extjs library, redesigning it has low priority.

    Gabe
    Check out Teamup Calendar - Easy-to-use planner and calendar built on Ext JS

  5. #4
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,250
    Answers
    758

    Default

    Yes, warnings are stripped out of production builds. Not sure what you mean by "custom build", but the debug statements are stripped out of any compressed versions.

    As for the issue, it's certainly not ideal and you'll likely run into problems if you don't fix it.
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  6. #5
    Sencha - Support Team scottmartin's Avatar
    Join Date
    Jul 2010
    Location
    Houston, Tx
    Posts
    9,409
    Answers
    716

    Default

    Try using ext-all-dev.js to see warnings in development mode.

    Scott.

  7. #6
    Ext JS Premium Member
    Join Date
    Mar 2010
    Location
    Switzerland
    Posts
    30
    Answers
    1

    Default

    Hi Evan and Scott,
    Thanks for your feedback. I was able to solve this issue. It was due to the fact that the Sencha SDK tool by default does not remove debug code when it generates a minimized and compressed build. This has to be configured explicitly.

    Another interesting discovery is that the extjs debug builds do not contain debug code. Only the dev build does.

    I posted my findings in more details in this post: http://www.sencha.com/forum/showthre...734#post845734

    Thanks for your help
    Gabe
    Check out Teamup Calendar - Easy-to-use planner and calendar built on Ext JS

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •