I try to handle a Summernote Keyup event with this:
myEditor.addSummernoteKeyUpHandler(new SummernoteKeyUpHandler() {
#Override
public void onSummernoteKeyUp(final SummernoteKeyUpEvent event) {
// TODO Auto-generated method stub
log.fine("hello");
}
});
I get a UmbrellaException which is IMHO a class cast exception.
This is the call stack
I identified the following spot where te cast failes:
#HasNoSideEffects
static native boolean canCast(Object src, JavaScriptObject dstId) /*-{
if (#com.google.gwt.lang.Cast::instanceOfString(*)(src)) {
return !!#com.google.gwt.lang.Cast::stringCastMap[dstId];
} else if (src.#java.lang.Object::castableTypeMap) {
return !!src.#java.lang.Object::castableTypeMap[dstId]; //<-- this returns false!!!
} else if (#com.google.gwt.lang.Cast::instanceOfDouble(*)(src)) {
return !!#com.google.gwt.lang.Cast::doubleCastMap[dstId];
} else if (#com.google.gwt.lang.Cast::instanceOfBoolean(*)(src)) {
return !!#com.google.gwt.lang.Cast::booleanCastMap[dstId];
}
return false;
}-*/;
dstId contains:
Any help greatly appreciated!
I tested this with a small demo which actually works. But in my large application, I get this exception and I don't see why.
Do you have any idea whats wrong here?
Best regards
Hannes
As Andrei suggested I set the style to DETAILED. I use Eclipse as a development environment. I decided to clean build the system (which I had done before). Now the problem has simply vanished !! Furthermore, I use SDBG (see: https://sdbg.github.io/) to debug my GWT application. This works pretty well (even without -style DETAILED). Now the very very strange thing remains. I can set breakpoints for my application and they all work well, except setting a breakpoint within the event handling method. I use a logger to print some text to the console, so I see that the event handler for summernote is actually called but the debugger will not stop. I checked whether the breakpoint is listed in the tab "Breakpoints" and it is and it is checked. I don't get it. Perhaps I have to rebuild all again.
But to keep long things short:
The solution to the problem is probably to really issue a clean build and then hope for the best.
Related
I'm coding in IntelliJ IDEA. When debugging my application, I can't use some default method implementations in Watches.
Here is a condensed example:
public class Friendship {
interface Friend {
default void sayHiTo(Friend friend) {
System.out.println("Hi, " + friend.hashCode());
}
default int amountOfHands() {
return 2;
}
}
public static class BasicFriend implements Friend {
int numberOfFaces() {
return 1;
}
}
public static void main(String[] args) {
System.out.println("Put a breakpoint here");
}
}
In main() method I put a breakpoint and set up three watches:
// Default interface method with dependency
new BasicFriend().sayHiTo(new BasicFriend())
// Default interface method without dependency
new BasicFriend().amountOfHands()
// Class method
new BasicFriend().numberOfFaces()
The first watch throws NoSuchMethodException complaining that method Friendship$BasicFriend.sayHiTo() doesn't exist.
The second watch runs successfully, but strangely it reports a boxed object
{java.lang.Integer#537} "2" instead of just a primitive 2.
The third watch reports a primitive 1, just as expected.
Why is the first watch not working? Is this a bug? Is this actually IDE related? Is it because of some conceptual flaw of default methods? Should it be working as I want it to in the first place? Is the strange result of the second watch somehow related to the issue in the first watch?
Prior to JDK 8u40, default and static interface methods were not supported by JDI (Java Debugger Interface), JDWP (Java Debugger Wire Protocol) and JDB (the standard Java debugger). This is bug JDK-8042123, which is recorded as fixed in 8u40 and a corresponding blurb appears in the 8u40 release notes.
Update to 8u40 or later to fix this issue, at least on the JDK side.
From the bug description, it looks like debugger-side changes are also required, to avoid casting com.sun.jdi.InterfaceType objects to com.sun.jdi.ClassType, but instead call InterfaceType.invokeMethod() directly.
In the specific case of IntelliJ, Suseika confirmed in a comment that 14.1.2 has mostly fixed the issue (except the unexpected boxing), though Mike Kobit still experiences this problem on that version with a ClassCastException suggestive of the incorrect cast above.
I am trying to display ads from pubcetner in XNA game for WP. I am using DrawableAd class as it is written here:
http://msdn.microsoft.com/en-us/library/advertising-mobile-windows-phone-xna-silverlight-hybrid-walkthrough-ads%28v=msads.20%29.aspx
But I can't see any ads rendering. Is it works? Or is there any other way to display ads? I wanted to try Adrotator, but I can't
get NuGet Package for this
Ok, I had a lot of problems with this in my game.
Without seeing your code, it's hard to actually diagnose, so without posting that from your Game.cs (assuming it's in Game.cs), you will need to make sure to test the following things.
//Global variable area
DrawableAd bannerAd;
string applicationID = "test_client"; //Or insert your actual ID. I recommend you first do with test client
//ie. 1234567-d123-1234-a12b-1a23b4567890
string adUnitID = "Image480_80"; //Or the actual unit ID. ie. 123456
//Initialization
protected override void Initialize(){
AdGameComponent.Initialize(this, applicationId);
AdGameComponent.Current.CountryOrRegion = System.Globalization.RegionInfo.CurrentRegion.TwoLetterISORegionName;
bannerAd = AdGameComponent.Current.CreateAd(adUnitId, new Rectangle(0,400, 480, 80), true);
AdGameComponent.Current.Enabled = true;
AdGameComponent.Current.Visible = true;
base.Initialize();
}
The part that got me by surprise was that I got rid of my base.Update(...) and base.Draw(...) calls and it actually prevented anything from ever being updated or called with the Ad. I also remember through my endeavor that the region was apparently important in some cases. Can't find the source for that. You might be able to get rid of it.
protected override void Update(GameTime gameTime)
{
//Your code here...
base.Update(gameTime);
}
protected override void Draw(GameTime gameTime)
{
//Your code here...
base.Draw(gameTime);
}
Hope that helps! Good luck. I know I had a pretty nasty time figuring out why mine didn't work. Make sure your render order is correct to. I'm not sure, but perhaps you might be drawing everything ON the ad. I haven't looked into whether you could actually do that or if the depth field of the ad was always on top. I just leave my base.Draw(gameTime) at the bottom of everything else.
I am using this example:
Android - Setting a Timeout for an AsyncTask?
in the following way:
al.setOnClickListener(new OnClickListener(){
public void onClick(View w)
{
final AlogLoader loader = new AlogLoader();
loader.execute();
Handler handler = new Handler();
handler.postDelayed(new Runnable()
{
public void run()
{
if(loader.getStatus() == AsyncTask.Status.RUNNING)
{
loader.cancel(true);
}
}
}, 1);
}
});
I set it to "1" because I wanted to see if I can stop it practically before it even starts - to see if my handler is working - in reality I would probably set it to 15000 (15 seconds).
However what happens is confusing:
Running the application, causes my onPreExecute() to draw a loading screen, which doesn't ever exit, so the user just sees a loading screen perpetually.
Running it in the debugger with the breakpoint at loader.cancel(true) -> Causes the debugger to stop at that line, which is expected because its only allowed to run for 1 millisecond. However, when I hit the resume button in the debugger after that - my onPostExecute() is called... How is that possible?
Clearly, I'm very new to timing out asynctasks - after some research, I found the example above and it seemed to make the most sense to me, definitely more then
loader.get(15000, TimeUnit.MILLISECONDS);, since that blocks the UI Thread.
Any help is appreciated...even an explanation on the process..
Okay,
So I essentially solved my problem but I am still confused... Don't know if that's all good.
I was unclear on how loader.cancel(true) actually works. Based on the API level (read this question : AsyncTask.onCancelled() not being called after cancel(true)) you need to have an onCancelled() or onCancelled(params) method, or both in your AsyncTask.
I did not have this, so this explains why I saw a loading screen forever. Okay Good.
Yet, it doesn't explain how in the debugger, I managed to still call the onPostExecute(), because according to Android API's, onPostExecute is never called once cancel(true) has been called...
The answer is:
Add this to your AsyncTask-
#Override
protected void onCancelled()
{
Toast.makeText(FriendsActivity.this,"Blah- reason", Toast.LENGTH_LONG).show();
loadingScreen.dismiss();
}
I have a BlackBerry App that has a Listener for the Send Button implemented in the CheckIn Screen. Data is sent through a web service. If the data is sent successfully, a confirmation message of "OK" is received. I am trying to switch screens in my BlackBerry App depending on the response received.
FieldChangeListener sendBtnListener = new FieldChangeListener() {
public void fieldChanged(Field field, int context)
{
try {
String alertMsg=sendTextCheckIn();
if(alertMsg.equals("OK"))
{
UiApplication.getUiApplication().invokeLater( new Runnable()
{
public void run ()
{
UiApplication.getUiApplication().pushScreen(new MyScreen());
}
} );
}
} catch (UnsupportedEncodingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
};
However, the above is throwing an App Error 104: IllegalStateException. Can anyone please guide on how to switch screens between a BlackBerry App.
EDIT: I can switch to any other screen but I CAN NOT switch to MyScreen. NOTE: MyScreen is the main (first) screen of the App. The above method sendTextCheckIn() calls another method that is placed inside MyScreen. Has this got anything to do with the error? Please advice.
The 'fieldChanged' event is already running on the UI event thread, so you shouldn't need to do the invokeLater call within it, just call pushScreen directly.
You mention that your problem with IllegalStateException only happens for MyScreen. That makes it sound like something specific with the implementation of MyScreen. Start narrowing down the problem - look at what happens in the constructor of MyScreen, and any events that might get called before the screen is visible. Some of that code is what is causing the problem.
Wrap everything that could possibly raise in exception in try/catch.
Don't do e.printStackTrace() - that won't give you much.
Instead do something like System.err.println ("KABOOM in method abc() - " + e); - seems like more effort, but trust me, that becomes INVALUABLE when debugging issues like this.
Catch Exception, unless you have a VERY good reason to catch a specific a subtype - otherwise you WILL end up with unexpected, and uncaught exceptions, which you will hunt for DAYS.
I try to reload a Web page using (JavaXPCOM):
nsIWebBrowser webBrowser = (nsIWebBrowser) browser
.getWebBrowser();
nsIWebNavigation webNavigation = (nsIWebNavigation) webBrowser.queryInterface(nsIWebNavigation.NS_IWEBNAVIGATION_IID);
try {
nsISHistory sessionHistory = webNavigation.getSessionHistory();
if (sessionHistory != null) {
webNavigation = (nsIWebNavigation) sessionHistory.queryInterface(nsIWebNavigation.NS_IWEBNAVIGATION_IID);
}
} catch (XPCOMException e) {
}
webNavigation.reload(nsIWebNavigation.LOAD_FLAGS_NONE);
But reload doesn't happen at all. I tried force it by using the following flags, but page doesn't refresh as well:
nsIWebNavigation.LOAD_FLAGS_BYPASS_PROXY|nsIWebNavigation.LOAD_FLAGS_BYPASS_CACHE
Anyone knows what can be the reason for that?
Thanks!
Did you try checking Error Console for syntax errors? You seem to be trying to use C++ type casts in JavaScript. That cannot work. Assuming that browser is a <browser> element, this should work:
browser.reload();
Or:
browser.reloadWithFlags(Components.interfaces.nsIWebNavigation.LOAD_FLAGS_BYPASS_PROXY|Components.interfaces.nsIWebNavigation.LOAD_FLAGS_BYPASS_CACHE);
See https://developer.mozilla.org/en/XUL/browser for documentation on the <browser> element.
Edit: Given that this is apparently using JavaXPCOM the code seems to be correct with the exception that the entire try .. catch block should be removed. The only flag should be LOAD_FLAGS_BYPASS_CACHE to make sure you don't get a cached response.