Broken DevExtreme menu with NT14.29 - some insight

@Andy,

I know I said I wouldn’t bug you again about the broken DevExtreme menu I’ve been asking about since January, but I lied.

I spent some time this afternoon and tracked it down. Well, managed to get it to work, although I don’t understand exactly why.

Comparing netweb.clw between versions 14.27 and 14.27, I find that Bruce changed line 12149 in the NetWebServerWorkerBase.Script method from

!14.27  Works with DevExtreme
self._ResponseQueue.response.SetValue(clip(p_script) & self.CRLF)

to

!14.27  Try/catch breaks DevExtreme menus
self._ResponseQueue.response.SetValue('try{{' & clip(p_script) & '} catch(e){{};' & self.CRLF)

So the script version that doesn’t work is sent to the browser wrapped in try/catch

try{$(function() {
    const menu = $("#nysMenu").dxTreeView({
        searchEnabled: false,
        dataSource: pageheadertag_menuItems,

        onItemClick: function(e) {
            pageheadertag_optionSelected(e.itemData);
        },
    }).dxTreeView("instance");
});
} catch(e){};

Bruce’s NT History page documents the change in 14.29 on January 9:

Change: When sending a script in a response, script is wrapped in try{ } catch to prevent it stalling the rest of the response

Reverting my 14.29 netweb.clw to the 14.27 code on that one line enables the menus to work in your out-of-the-box demo app by removing the try/catch.
Or overriding the p_web.Script method in the WebHandler procedure works as well.

Perhaps someday you guys can figure out why Bruce’s change doesn’t work with your code. And maybe a better workaround than what I’ve done.

jf

Perhaps if you put some kind of log() in the catch(), it will provide a clue?

Good thought, Jeff, but sadly my js skills are so minimal that if I make anything work anyhoo I pat myself on the back. :frowning:

The console does show an error - which I showed to Andy in a webinar a few weeks back. I don’t know why it complains about that function not finding pageheadertag_menuItems. It runs without error when the same js snippet is on the page not wrapped in the try/catch. Perhaps some kind of race condition?

I’m just glad to have found a workaround and will leave it to those more skilled to suss out the underlying problem.

I appreciate the suggestion.

Actually. the try/catch block in my prior post is not the one that’s breaking the menu.
It’s the block above that which defines the menu, beginning with this:

If I remove the try/catch from that block I can leave the try/catch on the anonymous function.

1 Like