Screenspan with blockingRPC

Hi Isomorphic!

I’m trying out the server validation, but got stuck with the following stacktrace:
(using SmartGWT Pro 25/08/2011)

WARN:Log:TypeError: this.$m8 is undefined
EventHandler._adjustSpanZIndex({Obj}) @ application/sc/modules/ISC_Core.js:1830
[c]EventHandler.showClickMask(_1=>null,  _2=>"hard",  _3=>[object Array],  _4=>"blockingRPC") @ application/sc/modules/ISC_Core.js:1775
[c]RPCManager.doShowPrompt(_1=>{Obj},  _2=>"Validating...") @ application/sc/modules/ISC_DataBinding.js:1144
RPCManager._sendQueue(undef, "Validating...", "**** Our address ****/..."[ 130], {Obj}) @ application/sc/modules/ISC_DataBinding.js:1210
[c]RPCManager.sendQueue() @ application/sc/modules/ISC_DataBinding.js:1202
FormItem.validate() @ application/sc/modules/ISC_Forms.js:1412

I drilled down the problem to the following piece of code:

EventHandler.js:6514

// If this is the first mask being shown, show the screenSpan if necessary

if (this.maskNativeTargets) {

		if (topMask == null) {
				this.showScreenSpan(mask);

		// catch the case where the screenSpan is already showing and needs to be moved behind 
		// the top level unmasked target.
		} else if (isHardMask) {
				this._adjustSpanZIndex(mask._unmaskedTargets)
		}
}

At the bottom of the _adjustSpanZIndex method, the method ‘setZIndex’ or ‘bringToFront’ is being called on the undefined ‘this._screenSpan’ var.
This var is set in the method showScreenSpan (line 7120), but this method gets never called in the above stacktrace.

Thank you in advance for your assistance.
Wica

This suggests that you may be attempting some kind of manual cleanup and destroy()ing the global screenspan object. It should never be destroyed.

I’m sure we’re not manually setting/deleting isc.EventHandler.$m8 or creating a isc.ScreenSpan of our own.

I did found that we’re getting this problem only if a server validation operation did not return from the server (see validation_fail.PNG).

validation_fail.PNG

You wouldn’t have to specifically reference the screenSpan, if you were attempting to do some kind of global cleanup starting at the window, you could inadvertently find it and destroy it.

Regardless, what you’ve provided so far definitely doesn’t enable us to reproduce a problem - clearly just a validation failure won’t trigger it, and it still makes no sense that the screenspan has been destroyed. Let us know when you have more information.