I'm having a problem with some code I've written. I've had to anonymize it, but I can give the problem. This javascript runs inside an iframe, and is part of an object that gets instantiated. The problem in particular is that I get a repeating error every time that "Type 'Object' Cannot be converted to type 'Function'" in the invoke() call. However, in the IE8 developer addon, checking the typeof of the function I pass (this.AJAXCallback), it clearly says that it's a function being passed. Is there any particular reason this error might be occurring?
MyObject.prototype.AJAXCallback=function(Data, e){
//snip
};
MyObject.prototype.Init=function(){
var a = window.top.window.Sys.Net.WebServiceProxy.invoke('/Data.asmx', 'GetData', false, { "IDCode":0 }, this.AJAXCallback, null);
//snip
};
I found the problem, and it doesn't seem to be on my part. I disabled debugging in the web.config file, and the error stopped. It also came back after debug was turned on, so I think it's safe to say that the debug code didn't work as well with what I wrote as the non-debug code did. In particular, it was one of the scriptmanager's JS files.
It may be giving issues because the Callback is a prototype. Have you tried wrapping the callback in an anonymous function call.
MyObject.prototype.Init=function(){
var a = window.top.window.Sys.Net.WebServiceProxy.invoke('/Data.asmx', 'GetData', false, { "IDCode":0 }, function(data,e) {
this.AJAXCallback(data,e);
}, null);
//snip
};
Related
I response this error when get JSON data by retrofit.
List<NewLicense> result = null;
Call<List<NewLicense>> serviceResult = ShahrdariApp.getShahrdariWebService().getLicenses(Configuration.getInstance().getString(SharedPrefs.MAC_ADDRESS), id);
try {
Response<List<NewLicense>> response = serviceResult.execute();
result = response.body();
Log.d("responseCode", String.valueOf(response.code()) );
} catch (Exception e) {
exceptionHandling(e);
Log.d("responseCode", String.valueOf(e.getMessage()) );
}
return result;
I had the same issue and forgot to set the Project SDK added this and it resolved the issue.
Simply restarting the IDE via File -> Invalidate caches can often solve this issue.
I faced the message
Unable to evaluate the expression Cannot find source class for
java.util.List
in hovering a List field while debugging in IntelliJ IDEA 2022.1.3 (UltimateEdition).
Even though an SDK was assigned to my Project, it helped to visit
IDEA ->File ->Project Structure -> Platform Settings ->SDKs and re-assign the SDK already visible in the list.
Namely I assigned openjdk-1.8.0.302-1, applied "OK", after that it was possible to debug a List foo.
IDE restart after that may additionally be necessary.
Take MenuItem as an example, normally in QML, specifying the handler for the triggered signal is simple:
MenuItem {
onTriggered: {
console.log("Hey");
}
}
Now if I want to do the same thing, but instead to a dynamically created MenuItem, e.g. via Menu.addItem(), then what is the syntax like to connect and specify the signal handler?
I didn't expect this to work, but here is a working solution:
function onTriggered() {
console.log("Hey");
}
var newItem = myMenu.addItem("Item 1");
newItem.triggered.connect(onTriggered);
Nevertheless is there a better way? Above I defined a custom function that happened to be named onTriggered, but it can be named anything, right? So this code piece doesn't make use of the built-in handler, that's why I'm wondering if there's a neater solution?
More importantly, later on I've noticed further problems with this approach: in a for loop, if there is a temporary variable used by the handler, things don't work any more:
for (var i = 0; i < myArray.length; i ++) {
var info = myArray[i];
var newItem = myMenu.addItem("Item " + i);
newItem.triggered.connect(function() {
console.log(info);
});
}
Here you'll see that console prints the last info in myArray for all added menu items when triggered. How can I properly set up independent handlers for each individual menu item?
In addition to the comments, you can easily make it "easier":
Menu {
id: myMenu
function add(text, handler) {
var newItem = addItem(text)
newItem.triggered.connect(handler)
}
}
And there you have it, problem solved, now you can simply myMeny.add("Item 1", onTriggered)
As for the result you get in the loop and functor, that's because of JS's scoping rules. Check the linked answer for details how to work around that.
So this code piece doesn't make use of the built-in handler
Don't think of onSignal as a handler, it is just a hook to attach a handler. Think of it as the declarative connection syntax. Sure, you can also use the Connection element in declarative, but it only makes sense when the situation actually merits it.
I think this confusion stems from some other language / framework which does generate handler methods for you. A onSignal is different from function onSignal() { expression } - the latter is a handler function, the former is handler hook, which just connects the signal to the bound expression.eval(). The Qt documentation too refers to onSignal as a handler, which IMO is technically and conceptually wrong, since the handler is the code which gets executed, the handler is whatever you bind to onSignal.
So you can rest easy, the code you are worried about does not result in any sort of redundancy or inefficiency and doesn't leave anything unused and is in fact the correct way to do things in QML.
All that being said, you can have "built in handlers", but it is a very different thing:
// SomeItem.qml
Item {
signal someSignal
onSomeSignal: console.log("I am a built in handler")
}
// main.qml
SomeItem {
onSomeSignal: console.log("I am another handler")
Component.onCompleted: {
someSignal.connect(function(){console.log("Yet another handler")})
someSignal()
}
}
And the output in the console will say:
qml: I am a built in handler
qml: I am another handler
qml: Yet another handler
As you see, it not really a handler, but a connection hook. There is no shadowing, no "replacing / not using the built in handler", there is just a signal with 3 connections to the evaluation of three expressions.
Using signal.connect() with a named function does come with one advantage, you can later signal.disconnect(namedFunction) if you need to remove a built in or another handler. I am not sure if you can do this if you use onSignal: expr since you don't have a way to reference that anonymous expression. Note that if you use onSignal: namedFunction() this will not work, you will not be able to signal.disconnect(namedFunction) because the signal is not directly connected to that function, but to an anonymous expression invoking it.
I can't catch the thrown error in my simplified code below. Why is that?
According to requirements of the stackoverflow I must insert some more info but this example is very simple. Can you help me with this example?
package com.myserver {
public class ReturnInfo extends Sprite {
public function ReturnInfo(urlParamsArr:Array) {
try {
var client:HttpClient = new HttpClient();
var uri:URI = new URI("http://valid-url.com/aaa.php");
client.listener.onData = function(event:HttpDataEvent):void {
throw new Error();
};
client.listener.onError = function(event:IOErrorEvent):void {
trace("error");
};
client.postFormData(uri, variables);
}
catch (e:Error){
trace("Error was caught.");
}
}
} //class
} //package
I tried also:
try {
new ReturnInfo(urlParamsArr);
}
catch(e:Error){
trace("caught error");
}
It didn't work either.
The code does not work because the code that throws error is executed later, so you need to use try-catch in the client.listener.onData handler. That handler I assume is called sometimes later so there when you parse or handle the data,make sure to catch/handle the errors
Adding on to what Simion said, the problem is method closure. In order for an exception to be caught somewhere in the "food chain" the catch needs to be in the stack - you will know what is in the current stack by getStackTrace(). In this example, there is no stack pointer that sits at the constructor (or any method) like there is one for client.listener.onData - which is why the postFormData will execute. When the event is triggered it's stack pointer goes back to the origination point of what actually started the event trigger in the first place (not the method that declared it). This is also why the 2nd attempt was unsuccessful.
Add on to the fact that the FP executes discrete chunks in frames (think of this like a heap), anything that executes in the scope of the dispatchEvent will generally have a very small or no stack at all (eg the first stack pointer is usually the dispatcher itself - not a method that actually called it).
try-catch is best attempted within the same scope of a method.
A pseudo example:
function getOrCreateWidget():Widget {
var a:Widget;
try {
a = getWidet();
}
catch(e:TypeError) {
a = createNewWidget();
}
//finally can be debatable - most of us leave it off
//bc it executes anyway just as it would in the function scope.
finally {
a.property = 'foo';
}
return a;
}
If this isn't possible - a last ditch effort is to attach a listener to the loaderInfo.uncaughtErrorEvents. Generally associating this with the systemManager is the best option because the SM knows about every branch of the display tree right down to the root stage. It's neither good practice nor practical to assign all deviations in this method because a lot of context to the programmer is usually lost. It's more an "oh S#!) sorry user, our app just verped."
So I have a class where I instantiate a variable callback like so:
public var callback:Function;
So far so good. Now, I want to add an event listener to this class and test for existence of the callback. I'm doing like so:
this.addEventListener(MouseEvent.MOUSE_OVER, function(event:MouseEvent) : void {
if (callback) {
// do some things
}
});
This works great, doesn't throw any errors, but everywhere I test for callback I get the following warning:
3553: Function value used where type Boolean was expected.
Possibly the parentheses () are missing after this function reference.
That bugged me, so I tried to get rid of the warning by testing for null and undefined. Those caused errors. I can't instantiate a Function as null, either.
I know, I know, real programmers only care about errors, not warnings. I will survive if this situation is not resolved. But it bothers me! :) Am I just being neurotic, or is there actually some way to test whether a real Function has been created without the IDE bitching about it?
Similar to using typeof:
if(callback is Function){
}
I believe should evaluate to true if the function exists and is a function and false if it is null or is not a function. (although if that doesn't work try if(callback && callback is function){}
if( !(callback == null)){
// do something
}
There's already an answer that works, but I thought I'd mention that you can also stop the warning from occurring by explicitly casting the result to a Boolean.
if (Boolean(callback)) {
// do something
}
Have you tried:
if (typeof callback == "function") {
// do some things
}
?
http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/operators.html#typeof
I'm trying to use callLater with FlexUnit v0.9:
public function testCallLater():void {
Application.application.callLater( addAsync(function():void {
assertTrue(true);
}, 1000));
}
but when it runs I get this error:
ArgumentError: Error #1063: Argument count mismatch on flexunit.framework::AsyncTestHelper/handleEvent(). Expected 1, got 0.
at Function/http://adobe.com/AS3/2006/builtin::apply()
at mx.core::UIComponent/callLaterDispatcher2()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\core\UIComponent.as:8628]
at mx.core::UIComponent/callLaterDispatcher()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\core\UIComponent.as:8568]
I'm not sure what the problem is. Is callLater incompatible with FlexUnit?
First, you should really consider migrating to FlexUnit 4.0: http://blogs.digitalprimates.net/codeSlinger/index.cfm/2009/5/3/FlexUnit-4-in-360-seconds
Second, callLater is meant to be used to delay processing until the next frame in visual classes. Your test case class is not a visual class extending UIComponent, therefore you should not try to use callLater.
Third, addAsync is use to test the results of an asynchronous operation. This is typically used in testing the results of a network request, of a file read, of a timer event, etc. That is why normally you see an "event" as a parameter in the addAsync test function (because asynchronous requests use events to process results). In your case, you're not responding to an asynchronous operation with your addAsync call, and therefore you shouldn't be looking for an event in your test function. Remove the event:Event parameter and the error will go away.
However, perhaps you can re-phrase this question to state what you're trying to accomplish? The code sample that you've indicated is not really doing anything useful. If you can be a little more specific we can help you write a better test case.
For help with using addAsync with older versions of FlexUnit, see this tutorial: http://life.neophi.com/danielr/2007/03/asynchronous_testing_with_flex.html
It looks like you are expecting an event, but not getting one. I imagine the following code would work.
public function testCallLater():void {
Application.application.callLater( addAsync(function(/*removed event declaration*/):void {
assertTrue(true);
}, 1000));
}
Just in case someone needs it, this works :
private function testCallLater():void {
Application.application.callLater(doCallLater, [ addAsync(funcUnderTest, 1000) ]);
}
private function doCallLater(testFunc:Function):void {
testFunc(null); // Dummy arg necessary because of addAsync expecting one arg
}
private function funcUnderTest(e:Object = null):void {
assertTrue(true);
}