Mar 03, 2020, 6:24 PM
Glad to see we may be making progress. I'll try to answer the topics, following the logic of the last post.
We would be quite willing to address this issue if you opened a dedicated thread for it. I see old reports of the issue but it hardly looks like the same, and they come from before Ext.NET 2.5.0, so it really does not look like the exact same issue. May be worth some investigation.
~
Step thru the returned javascript code and note the moments where the component shows being loaded twice. The commented code for stop layout and then resume layouts seems like might have been a workaround back in 2.x to prevent layout updates until the reconfigure was triggered -- maybe you can delay the resume layouts bit to happen after the reconfigure (probable)
You may experiment with just keeping the
If this delayed call of Ext.resumeLayouts() seems fruitful, you may want to consider converting the DirectMethod into a DirectEvent, and having Before= and After= handlers commanding the layout freeze and resume; optionally applying a mask on the screen during the server side call, should it take long enough to look "strange" to the interface.
The SourceFormatting setting could work better with a proper JS beautifier, which was not available or mature when the feature was developed; but the way it is is really better than nothing. You can improve it even further if you use that little lower-left corner button that reads
The whole extnet/extnet-all-debug-js embedded resource (extnet-all-debug.js) is made of overrides for the extjs/ext-all-debug-js one. Here's how you would override the grid panel's reconfigure() client-side method.
I could copy the whole code (it's pretty long) so, for brevity, I'll show another usage: calling its overridden method.
Not for me, from here. I don't see how I could pinpoint the code line that fills the grid as there may be so many different ways for that to trigger. But if I had a runnable test case here, what I would do would be, step thru the returned code from the direct method. If adding a breakpoint is not feasible (as new code comes from the server every request), you could add a callback and break in it, or just add a raw
Yes, you've been missing the direct method result all the time by ignoring the network tab. Experiment with loading the page (lots of output), clear output right before you do whatever it takes for the direct method to be run. You'll see a non-parsed JSON or Javascript return as the response body; in this scope you can't step thru the code as it is but text that will be eval'd (or expanded) by Ext.NET's ajax handlers.
Hope this helps!
Originally Posted by rgraham
Originally Posted by rgraham
Step thru the returned javascript code and note the moments where the component shows being loaded twice. The commented code for stop layout and then resume layouts seems like might have been a workaround back in 2.x to prevent layout updates until the reconfigure was triggered -- maybe you can delay the resume layouts bit to happen after the reconfigure (probable)
defer()
'ed load happens.You may experiment with just keeping the
X.Js.Call("Ext.suspendLayouts");
in the direct method, and then manually calling the counterpart (resumeLayouts) in developer tools, and check if this results in only one "flash" of the screen. It may be "flashing" when (a) it gets its store wiped to comport the new layout and (b) when the new layout is input and it loads its data. It is not necessarily "dual-loading" (although you might be seeing something that ensures you it is double-loading, of course).If this delayed call of Ext.resumeLayouts() seems fruitful, you may want to consider converting the DirectMethod into a DirectEvent, and having Before= and After= handlers commanding the layout freeze and resume; optionally applying a mask on the screen during the server side call, should it take long enough to look "strange" to the interface.
Originally Posted by rgraham
{ }
in Google's Chrome developer tools to properly indent any code in source tab.
Originally Posted by rgraham
I could copy the whole code (it's pretty long) so, for brevity, I'll show another usage: calling its overridden method.
Ext.defined('thread62850', {
override: 'Ext.grid.Panel',
reconfigure: function(store, columns, allowUnbind, applyState) {
var me = this;
Ext.toast("Before I run original reconfigure.");
me.callParent(arguments);
Ext.toast("After I run original reconfigure.");
}
});
As you may have figured, if you don't want the original code to run, and change something inside it, instead of the callParent(), just paste its code and change what is needed. In case the code you pasted had a callParent()
(and you don't want the parent to be called, but the "parent's parent", there's the callSuper() to call its superclass (parent class). You probably won't need to worry with this for now, but it is good to know.
Originally Posted by rgraham
debugger;
call from the direct method (X.AddScript("debugger;");
in code behind should do) and let it stop there; then step thru.
Originally Posted by rgraham
Hope this helps!