I have a problem with my GWT/libgdx app (GWT ver: 2.6.0, Gdx ver: 1.9.2) and I cannot find any recent solution, or something that match my issue, on the Internet. Short story is, sometimes, "randomly" (or inexplicably, to be honest), my app choose not to load on the first try (or second, third...), and then after one (or two, three) refresh, it works (... and sometimes it doesn't, at all). Sometimes it loads immediatly, too.
This behviour happens on various browser (firefox, chrome, chrome for mobile... Surprisingly enough IE is not the most problematic browser here), on various machines (and OS). So, on my Linux/firefox, I often have no problems (not always). But on my colleague Windows10/Chrome, we have to refresh the page two or three times, and on his phone (Android/Chrome) it never displays. I don't exactly know the versions.
On Firefox, I thought I had a hint first, because the blablabla.cache.html file seemed not to be loaded (in the sources page of the inspector) when the page refused to load (which would explains why, even if it would be totally not normal that this part would randomly be there or not!). But then, the .cache.html was here, and not my app...
All that I know for sure is that onModuleLoad() is never called when my app is not displayed. Neither is this part (from gdx):
public PreloaderCallback getPreloaderCallback() {
return new PreloaderCallback() {
#Override
public void error(String file) {
alert("error");
}
#Override
public void update(PreloaderState state) {
if (state.hasEnded()) {
alert("loaded");
}
}
};
}
So I know that, with these weird and little pieces of information, it will be impossible to know what is wrong. But did anyone get such a curious and untrusty behaviour with a GWT and / or gdx app?
EDIT : I noticed two possible explanations for my problem. Now it is mostly solved but I'd like to help anyone who could have the same trouble in the future.
The first one is in the html file. It was impossible for you to know because I did not think it was a possible cause for my issue. I was using React and GWT to display my app, and both React and GWT were rendered in a unique div.
When React is rendered first, the GWT part is added in the div, so everything works well. Yet, when GWT is rendered first, the React part replace it in the div. Most of the time React was faster and I did not see any problem. The solution was easy: I added another div specifically for React.
The second issue was on iOS10. Gdx uses an old version of SoundManager2 that needs a patch to work on iOS10, and even stops the application loading. I had to use more recent sources of SM2.
Related
I have read all the supported issues but not having right solution. I have updated flying-saucer dependency from 1 to 9 and finding the issue.
<version.oldc.flyingsaucer>1.0</version.oldc.flyingsaucer>
<version.oldc.flyingsaucer.itext>2.0.8</version.oldc.flyingsaucer.itext>
to this
<version.oldc.flying-saucer-core>9.0.9</version.oldc.flying-saucer-core>
<version.oldc.flying-saucer-pdf>9.0.9</version.oldc.flying-saucer-pdf>
and I have added this method in the interface because its not letting me to build successfully.
#Override
public void preWrite(ITextRenderer iTextRenderer, int pageCount) {
}
this is causing my pdf overllaped totally when I degrade the version its working fine but I cannot degrade it because there are other issues causing. i have tried all the css tricks which is not helpful. Am I missing anything else.
I am thinking its because of the method in the interface but its not happening in all pages its happening only for one page in entire document.
Previously, I've been able to create a method stub in Eclipse (Java) by typing the method name and pressing CTRL - SPACE. This would then give me the option of automatically generating a void method stub.
Unfortunately, recently I've been unable to do this for any method name longer than two characters. Once the word is longer than 2 chars, the option is no longer there.
I've looked at the templates in the options, and found the private_method and public_method templates, which are similar, but not quite right. The void method stub is nowhere in there. Also, the icon next to the void method stub is different to the templates, which leads me to believe that it is indeed something other than templates.
Can anyone point me in the right direction of why this isn't working for anything longer than two characters?
Here's an image of the code suggestion I'm looking for (the selected one):
EDIT: For clarification, I've added two more images showing the problem, and a further description:
In the case where there are two characters and I press CTRL - SPACE, I get the autocomplete option for creating the method stub (which is what I want). However, when pressing CTRL - SPACE with more than two characters before the cursor, there is no such suggestion. See the second image below and you'll see what I mean.
It's related to Code Recommenders, which is now enabled by default in Eclipse (as of the Mars release, I think). To me it looks like a bug, either behavioral or, if it's working as intended, it's a usability and/or UI bug, because it's difficult to understand the new behavior.
One workaround is to disable Code Recommenders for code completion; see this screen shot for where to do so in the Preferences.
If you want to keep Code Recommenders enabled (it does seem to provide some valuable functionality), is to tweak a particular setting so that the method template is included for more characters. I'm not exactly sure how or why it's related to what you're seeing, but it does seem to work. I'm also not sure of the performance impact of adjusting this too much, as indicated by the UI instructions.
Increasing the "Maximum prefix length" for the sub-words completion seems to allow larger numbers of characters to trigger the method template suggestion. Again, I'm not sure why but I strongly suspect it's a bug in Code Recommenders.
I suggest asking about it on their forum and/or entering a bug about this: https://www.eclipse.org/recommenders/community/
form the image I can tell that you are trying to write your code within the class block and not within a method block...
Example
class a {
// you are trying to write your code here
}
This issue has been fixed with Eclipse Code Recommenders 2.2.5.
You can download it from the Recommenders stable update site stable update site.
I just faced a strange behavior and I can't even say if it is a JavaFX specific problem, Eclipse problem or even where to start fixing first.
But first things first: I'm writing a JavaFX application (Eclipse Kepler/ Java 1.7), containing some extended ListViews. The program takes about 1sec to load.
The extended ListViews look something like that:
public class NewList<T extends Obj> extends ListView<T>{
public NewList(){
// addEventHandler(KeyEvent.KEY_RELEASED, new EventHandler<KeyEvent>(){
//
// #Override
// public void handle(KeyEvent arg0) {
// if(arg0.getText().equals(KeyCode.DELETE)){
// getItems().remove(getSelectionModel().getSelectedItem());
// }
// }
// });
}
}
There are also some MouseEvents (like drag and drop) inside the same constructor, and they are working as expected.
Now I want to add an EventHandler to my extended ListView (see commend in the code above).
The code takes now about 8sec to start aka 8 times longer as normal. To my surprise 90% of the loading time the program is inside the .show() method of my primaryStage (there is just one). After the loading time, the GUI is extreme slow and the cpu usage is on 100%.
Maybe the Handler is implemented wrongly and is doing some strange stuff during the whole time.
I can't find any solution or even comparable problem on the internet....but now the real problem just begun:
When I delete the Handler and run the program again, it will stay slow! So the program is in the same state as before - just still broken! That makes me crazy, because I can't see any logical explanation for that behavior.
What I have already tried:
delete the bin folder inside the repository and build the code again (+reboot)
reset the repository via git
throw half of the code away and started again. At any point it worked again, unfortunately I was not able to reproduce the effect. Then I implemented the Handler again and the problems started from the beginning...
edit: it looks like there goes something wrong during the building process/updating the binarys. I deleted 99% of the code (>5k LOC), then it worked. I copy/pasted the original project back into my workspace and the hole code worked smoothly - even with the Handler on. So I can't imagine a way to produce a minimalistic setup. btw: I'm not allowed to release the complete project folder (university stuff...)
edit2: I' using win7 64bit with java64. other javaFX programs are working (even then grafic intensive oracle samples). I'm not using any JavaFX specific repository setup or builder
Okay, I faced the same problem a few minutes ago and I think I found the source this time.
I'm running my code ALWAYS in debugging mode. To check the EventHandlers condition, I created some breakpoints in Eclipse. I also created a breakpoint at the following line of code (see above for more code)
public void handle(KeyEvent arg0) {
A mouseover over the breakpoint provides the following information:
Multiple markers at this line
Method breakpoint:NewList [Entry] - handle(KeyEvent)
implements:javafx.event.EventHandler .handle
I don't know what is happening here exactly but I think its something like this:
I'm overriding a JavaFX EventHandler Method and the debugger has to check the breakpoint on every single JavaFX interaction/EventHandler call. So Eclipse cant handle the flood of checks in a propper time and all seems to be very slow.
To clear that out: the breakpoint itself does not have to be called at any time, just the existing of it is enough to cause the problems.
Deactivating the breakpoint or running the application in a non-debugging mode will fix all problems. I think it should be a good idea to avoid all entry-breakpoints in any kind of Listener/EventHandler :)
I have a java applet I am using for uploading from interenet explorer in my web site.
when a button is presse on my site , a javascript function inits the applet and calls the applet's OpenPrivDialog() function.
public void OpenPrivDialog() {
AccessController.doPrivileged(new PrivilegedAction<Object>() {
#Override
public Object run() {
OpenDialog();
return true;
}
});
}
public void OpenDialog(){
JFileChooser fc = new JFileChooser();
fc.setFileSelectionMode(JFileChooser.FILES_AND_DIRECTORIES);
fc.setMultiSelectionEnabled(true);
Logger.getLogger(UploadApplet.class.getName()).log(Level.INFO, "Opening dialog", "fe");
int retVal = fc.showOpenDialog(f);
if (retVal == JFileChooser.APPROVE_OPTION) {
Logger.getLogger(UploadApplet.class.getName()).log(Level.INFO, "approved", "");
File[] files = fc.getSelectedFiles();
Logger.getLogger(UploadApplet.class.getName()).log(Level.INFO, "got " + files.length+" files", "");
AddFiles(files);
}
}
this code works, but is terribly slow the filechooser dilog opens, but for a minute is completely unresponsive and then just extremely slow -any idea why?
When I read this post I could picture a horrible experience I had. I needed to work in a software much more complex than yours but in essence it had the same principle: Interacting Java Applet with Javascript running on a web browser.
We faced several issues and I would highlight:
Slow response: similar to what you are experiencing.
Security issue: security checks asking the user to agree with
potentially dangerous code and other issues related with
zero-day-attacks.
Inoperative Javascript calls: rarely our applet could not reach the
javascript code, we never found the reason of this issue and it was
very hard to reproduce.
Browser compatibility: Firefox and Chrome were very standard, but we
faced several problems with Internet Explore and Safari.
It turns out that our applet code was ready in 5 days but the integration with javascript took about a month (we had 4 senior developers working on it) just because our stakeholder wanted it to work with some fancy jQuery components. It was just a nightmare!
Bottom line, we could not do it. Alternatively, we wrote everything within our applet and provided a series of properties that UI developers could use to change the appearance of our applet which worked great and everybody was happy with it.
Therefore, I would advice to do not use JavaScript + Java Applets. Yes, you can use some basic features, but do not go further with it.
Alright, let's talk about your issue. We noticed in some cases that javascript was very slow when calling Java Methods but was never slow when changing Java Propeties. So, we created some Java variables and changed it via Javascript. Next, we watched these variables (maybe in a thread). Finally, we could call the right methods based on these variables.
No, I do not like this approach. But was the only thing that worked for us before drooping the idea of using Javascript with Java Applets completely.
I hope it helps.
Cheers,
It is a little bit annoying to have the GWT hosted browser (on a Mac) pop up at always the same screen location and same size (that is: to small and at the wrong place!). In particular if you have two 24" monitors it couldn't be less annoying to always move the browser window and to resize it on startup. I know I could leave it open and reload, but I'm used to the cmd+shift+F11 and then cmd-Q to quit cycle as I do in other programs. Another reason is that in hosted mode GWT leaks memory and after a couple (about 20) reloads I have to quit anyway.
Does anybody know a way to tell the hosted mode app the initial size of the browser frame and possibly it's location? If not I will eventually file a feature request at GWT.
One thing you could try is to have a separate module class for hosted mode testing that is a subclass of your actual module. In the hosted mode version of the module, you could have some JSNI that resizes the window:
public class MyModule implements EntryPoint {
//...
}
public class HostedModeMyModule extends MyModule {
private native void resizeWindow() /*-{
$wnd.resizeTo(800, 600);
}-*/;
public void onModuleLoad() {
resizeWindow();
super.onModuleLoad();
}
}
You'll have to have two gwt.xml file of course, one for testing and one for compilation.
This isn't the most elegant approach, but is all I can come up with.
I don't think there is a way yet, but see this issue in the tracker for a possible patch (might not work anymore) and some explanation.