No announcement yet.
  • Filter
  • Time
Clear All
new posts

    The SuperDevMode trace doesn't make sense to us. There should be a stack trace that includes frames from our framework code, but there are no such frames. Where did you set the breakpoint to collect the function call output we requested?

    Also, it appears you've ignored the request to switch over to a full debug configuration. Have you uncommented the lines we requested in build.xml? We can see that you're including the debug versions of the inherited modules in your gwt.xml module - these should actually be the debug no script versions since you don't want loadScriptTagFiles generated. (There's no need to manually remove it.) Then in your HTML, you need to pick up the framework modules from the modules-debug directory, as per the debugging help topic we linked above.

    After all those changes, you should not be seeing obfuscated symbols, like _9, in Legacy DevMode, though you won't get any stack frames from inside the framework.
    Last edited by Isomorphic; 1st Jun 2020, 13:52.


      Hi Team,

      Since BaseWidget.draw is a native method, i could not put debug point in that from eclipse. But if you notice, the first line of that method is a call to isConfigOnly() method. In that i put debug point to get the value of getID and getClassName

      Regarding style, loglevel and optiomize config, they have been set as expected by you. I can see the generated javascript files are not obfuscated anymore.


      I tried now with
      <inherits name="com.smartgwt.debug.SmartGwtNoScriptDebug" />
      And now i don't have to remove that loadScriptTag.js

      This time instead of _9, i got below message

      BaseWidget::draw()([]): member is undefined
      Hope this can help
      Attached Files
      Last edited by pratik.thaker; 2nd Jun 2020, 03:46.


        From what you say, the problem may be that you have a null member in your layout. You may want to check that (at the breakpoint or otherwise).

        However, note that Legacy DevMode is only supported in old browser versions, and will not report the JavaScript stack trace from the browser if an exception is hit. We'd be able to diagnose the situation easier if you provided a full stack trace, including SC Framework frames, from SuperDevMode (or even from an ant command-line build with the build.xml settings we suggested.)

        When you reported your SDM trace above, it was unrecognizable - none of our code was visible in the stack trace. To debug further, we're going to need a stack trace that reports a problem in our framework.


          Hi Isomorphic Team,

          I was able to find the issue with process of elimination. Below was the issue which was working fine in earlier version but breaking in 12.1,
          1. I had created one SearchForm
          2. Added that in a CanvasItem
          3. Added that CanvasItem in another SearchForm as a field.
          4. Added SearchForm created in #1 and #3 in a HLayout

          Issue got resolved when I stopped adding the SearchForm created in #1 in HLayout in #4.

          I still need to figure out the root cause behind another issue I am facing on another screen. Please see reply #8 of this thread.

          Thanks for your help.


            Post #8 is another Legacy DevMode capture, with only a few SGWT frames at the bottom of the stack. We really can't predict what might be going wrong from just the fact that ListGrid.setFields() is getting called.

            As we mentioned above, for these types of errors we really need to see the JavaScript stack frames from our framework, and for that you'll need SuperDevMode, or a command-line build with the build.xml options suggested. In post #5, you present a SuperDevMode stack trace, but something is wrong as still no JavaScript frames from our framework are present.
            Last edited by Isomorphic; 3rd Jun 2020, 17:29.


              I have one observation though, even after running in SuperDevMode, i was not getting any different stack trace. I can add debug points in my java classes using source maps in chrome browser itself. Still final stack trace which is shown in chrome's console is same. Also, the build options (-style, -optimize, -logLevel) are already in place and as I had attached file in post #17, I can see their effect in compiled js files.

              Can you please help why still I am not getting something which you are expecting ?


                Hi Team,

                I think i have some more details which can help you. I tried script level debugging to find out where it is failing in framework code.

                Please note that, issue occurs in a grid shown in screenshot 1, Please note that issue does not occur if i do setShowHeaderContextMenu(false) or setShowFilterEditor(false) on that grid.

                The grid has a fifth column which has datasource bound combobox as a cell editor. You can see that filter editor has been rendered to show same.

                Screenshot #2 shows the call where that field is being passed to a method

                Screenshot #3 shows the next method where that field is received as undefined

                Can you please let me know if it helps ?

                Click image for larger version  Name:	SS3.png Views:	0 Size:	51.0 KB ID:	262637Click image for larger version  Name:	SS1.png Views:	0 Size:	255.6 KB ID:	262638Click image for larger version  Name:	SS2.png Views:	0 Size:	264.6 KB ID:	262639
                Last edited by pratik.thaker; 4th Jun 2020, 03:07.


                  Sorry, that’s very ordinary use case, so it doesn’t help. We either need the stacks trace, as previously indicated, or you need to work toward building a test case.

                  We would suggest you work toward fixing your environment so that it produces normal stack traces, perhaps by revisiting the instructions to look carefully for steps you may have skipped, or you re-building your project. You are not going to be able to figure anything out with such basic debugging facilities broken.


                    Hi Isomorphic,

                    I am feeling very happy to inform you that i have been able to replicate the issue I had mentioned in reply #22, I am facing it when i am doing mouse over on Title column

                    I am attaching below files,

           (This is entry point class)
           (Datasource class for grid)
                    countryData.xml (Data for grid)
           (Datasource class for ComboBox)
                    countryData2.xml (Data for ComboBox)

                    I have been able to replicate exactly what I am facing as an issue. In my case, grid data is being loaded by server, and then upon edit, editor data is being loaded by another datasource with some other display field and value field values.

                    Please note that, in, i have added some comments to explain what happens if i do and don't set the properties.

                    Please let me know if more details required.
                    Attached Files
                    Last edited by pratik.thaker; 12th Jun 2020, 10:15.


                      We're able to reproduce a crash with your sample code by mousing over the filter row. Is that the issue you're seeing?

                      We'll update this thread when a fix has been applied.
                      Last edited by Isomorphic; 12th Jun 2020, 16:37.


                        Yes, that's the issue i am seeing. But in my project, it throws same exception without mouse over. As i had mentioned earlier, if i i disable filter or header context menu, than issue is not coming.


                          Your sample code provides a valid stack trace for command-line ant and SuperDevMode Eclipse builds, but your project doesn't. This means that there's a problem, a misconfiguration or some other issue, preventing proper error reporting there. You should prioritize solving this so that other crashes hit going forwar are not so difficult to pinpoint.

                          Looking more deeply at your sample code, we see a problem - even though you've not defined an optionDataSource directly on the "Job" field, its displayField is not defined in the TreeGrid's DataSource, ItemSupplyXmlDS, as is required in that situation. You may have configured the optionDataSource like that for efficiency as our docs recommend here, but they also point out the requirement of the displayField being defined on the grid's DataSource in this case, through a DataSourceField.includeFrom declaration or similar.

                          One SGWT Showcase sample where such a definition is required is the Large Value Map Sample, though it uses a slightly different approach for ensuring the required displayFIeld is in the grid's DataSource.

                          We've made a change to the logic that was crashing in this situation to generate a warning instead of crashing, but you still need to fix your code. This change should also improve the resolving of displayField in general. These fixes have been applied to SGWT 12.1 and newer branches and should be in the nightly builds dated 2020-06-14 and beyond.
                          Last edited by Isomorphic; 14th Jun 2020, 23:09.


                            Hi Isomorphic,

                            I sure am looking into the stack trace part. Can you please give me some information or document about getting stack trace using command line ?

                            I will look into other suggestions also.

                            Also, regarding nightly build, do you mean from below location ?



                              Originally posted by pratik.thaker View Post
                              Hi Isomorphic,

                              I sure am looking into the stack trace part. Can you please give me some information or document about getting stack trace using command line ?
                              You can build your project using the command line, but you'll still need the browser to see any crash reports. For our BuiltInDS sample project, take a look at the README.txt file in the project directory for instructions on doing an ant command-line build. If you've modified your build.xml and BuiltInDS.gwt.xml files as instructed earlier in this thread, you should see an informative stack trace reported in the browser console upon crashing.

                              Also, regarding nightly build, do you mean from below location ?
                              Yes, from for whatever version of the product you need and/or are licensed for.