Announcement

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

    Cannot set property 'record' of null on isc.ListGrid.addMethods.updateRollOverCanvas

    I'm having this error on the devmode log when I mouse over some cells on a ListGrid (log collected with smartgwt power 3.1-p20130422, but problem persists with 3.1-p20131029).

    We override ListGrid.getRollOverCanvas and sometimes return null, when we don't want a roll over canvas to be displayed for a particular row/col. Can this be the cause? If so, what can we do. If not, what else could be wrong?

    [ERROR] [Main] - 12:14:30.507:MMV2:WARN:Log:TypeError: Cannot set property 'record' of null
    Stack from error.stack:
    isc.ListGrid.addMethods.updateRollOverCanvas() @ Main/sc/modules-debug/ISC_Grids.js:48618:27
    isc.defineClass.addProperties.updateRollOver() @ Main/sc/modules-debug/ISC_Grids.js:16379:20
    isc.GridRenderer.addMethods.mouseMove() @ Main/sc/modules-debug/ISC_Grids.js:13240:26
    isc.Canvas.addMethods.handleMouseMove() @ Main/sc/modules-debug/ISC_Core.js:53111:37
    isc.EventHandler.addClassMethods.bubbleEvent() @ Main/sc/modules-debug/ISC_Core.js:29250:40
    isc.EventHandler.addClassMethods.__handleMouseMove() @ Main/sc/modules-debug/ISC_Core.js:26710:8
    isc.EventHandler.addClassMethods._handleMouseMove() @ Main/sc/modules-debug/ISC_Core.js:26556:26
    isc.EventHandler.addClassMethods.handleMouseMove() @ Main/sc/modules-debug/ISC_Core.js:26529:21
    isc.EventHandler.addClassMethods.dispatch() @ Main/sc/modules-debug/ISC_Core.js:29969:34
    HTMLDocument.eval() @ eval at <anonymous> (http://localhost:7001/linker/Main/sc/modules-debug/ISC_Core.js:1263:54), <anonymous>:3:129

    #2
    We see the problem and have a developer taking a look

    Regards
    Isomorphic Software

    Comment


      #3
      A quick follow up question: You say you're using 3.1p. Is upgrading to 4.0p a possibility for you?
      It looks like there is a framework issue here we'll need to address, we're just trying to determine whether it can be backported to the 3.1 branch or not (and whether this is a requirement for you).

      Comment


        #4
        We do not have plans to upgrade to 4.0 yet.

        I should say we are living with this issue for a long time without much trouble. Apparently it does not cause any functional effect except for a CPU overhead on isc__debug__reportJSError.

        I am not sure it is related but there is a very annoying delay (caused by CPU usage) while hovering the cells that has rollovercanvas when there are many (~30) rows in the listgrid. See this chrome cpu profile: https://dl.dropboxusercontent.com/u/75515148/rollovercanvas.cpuprofile.zip

        Our requirement is to be able to display action buttons over some cells and currently we use rollovercanvas for that.

        Comment


          #5
          We have a developer looking into the reported issue. Once we have a fix we will be back-porting to the 3.1p branch if it is not prohibitively difficult to do so. Let's hold off on worrying about this performance issue until we have resolved the original issue. If it persists, and you can show us how to reproduce, we can take a look at that separately.

          We'll follow up when we have more information for you

          Thanks
          Isomorphic Software

          Comment


            #6
            We've now put a fix in for this so returning null in getRollOverCanvas or getRollUnderCanvas will be handled correctly (no more errors). We've managed to back-port it to 3.1p and it will be available in a nightly build in the next couple of days.

            Regards
            Isomorphic Software

            Comment


              #7
              Thank you. We'll test and report back as soon as it became available.

              The nightly build will be a development build, so 3.1d right? Where can I grab it? The expected dir is empty by now: http://smartclient.com/builds/SmartGWT/3.1d/PowerEdition

              Comment


                #8
                When 3.1p was released it was created from the 3.1d build at the time. Now only the 3.1p build is available and any bug fixes we decide to back-port to it will be included in a nightly of 3.1p, if that makes any sense.

                If you look at http://isomorphic.com/builds/ there is a description at the very top.

                Patch Builds: a "patch" build contains bugfixes, documentation updates and locale updates only - no new features. Patch builds should generally be used for development; do not use the original release builds or you will encounter already-fixed bugs. The letter "p" in a version (e.g. "9.0p") indicates a patch build.

                Development Builds: a development build includes progress toward a future release. The letter "d" in a version (e.g. "9.1d") indicates a development build, moving towards the release of the specified version (for example, 9.1d would indicate progress towards a future 9.1 release).
                So this fix will be included in the 3.1 patch build (3.1p), as well as 4.0p and 4.1d.

                Regards
                Isomorphic Software

                Comment


                  #9
                  Ok, thanks.

                  Comment


                    #10
                    Hello.

                    Upgraded to 3.1-p20131116. No more exception!

                    Can we take a look at that performance problem when scrolling?

                    Comment


                      #11
                      Have you tried profiling the new build and do you still see a similar problem?

                      We're not seeing profiling information similar to what you sent. There's no isc_debug_reportJSError going on. This suggests that something in the page is having a JS error, possibly something related to your use of JQuery, and not SmartGWT.

                      Comment


                        #12
                        I have tried and the profile has changed. No more reportJSError but still very CPU intensive and slower than expected.

                        The call stacks does not show a particular hotspot. But it appears to me that it is wasting much of the cycles redrawing the grid and adjusting for overflow.

                        In the attached file, there are 7 burst of scrolling events showing the same profile.

                        https://dl.dropboxusercontent.com/u/75515148/slow-scroll.cpuprofile.zip

                        Comment


                          #13
                          If you're scrolling new parts of a dataset into view, redraws are expected. That's part of the incremental rendering subsystem, which allows the grid to scrolling to millions of rows.

                          Comment

                          Working...
                          X