In this page the CheerpJ conversion of the applet in this page (with identical byte-code) does not seem to recognize mouse dragging past the applet frame boundary. It would be nice if that were possible.
Is this just a problem with my client-side setup (Linux Debian 9.2), or do others see the same behvior?
What is very strange, is that the original behavior is converted correctly on the not-supported-by-CheerpJ iphone browsers (I have checked safari and firefox there). Could investigation of this fact help CheerpJ developers understand how to make the MouseMotionListener interface recognize mouse dragging anywhere on the screen, not just within the applet frame?
Maybe this is impossible, but I thought it was worth asking.
Edit: Changed title to be less negative about CheerpJ (which overall I find almost too cool to be true!) and more reflective of actual the question.
The mouseDragged method is correctly implemented to the best of our understanding. The Java event is derived from the mousemove JavaScript event which is not delivered when the mouse is outside of the applet surface. With the legacy plugin applets are displayed on native windows which have different behavior.
It could be possible that using different JavaScript events, like mousedrag would make CheerpJ behavior more similar to native, but reworking this without causing regressions would require significant work and it is not currently a priority for us. Especially considering that our customers normally have full screen Swing applets which cannot exhibit the problem
On mobile devices the touchmove event is used, which is probably what causes the difference you see.
If you want to report a bug you can do it here: https://github.com/leaningtech/cheerpj-meta/issues
Related
I have a web application (struts 1.3, Weblogic 10.3.0, Toplink, Oracle) that has a Java applet which isn’t working in the browser (IE7/8) when the Next-Generation Plug-in setting is enabled in the Java control panel but works fine when it’s disabled. The trouble is that this setting is set to disappear in an upcoming Java release meaning that my users would have to keep using Java 1.6_xx on their workstations as they are currently. I have little influence over which version they use because they are all governed by their local IT departments across the country. So, either I have to find a simple fix to allow the Next-Generation setting to work, or we have to look at replacing/rewriting the applet with something else (but would be a last resort due to funding constraints), most likely something AJAX-friendly so as to avoid the need for a plugin. This application is quite old, written around 2001 before AJAX was really around.
The main window has a left, right, and top frame (JSP’s), as well as a center frame which is where the applet is. The applet has a main content area in the middle and a lower panel at the bottom which has some buttons. The buttons tell the content area (which is basically a treegrid) what to do (Save, Copy, change status, etc ). When I press one of the buttons the entire window (surrounding frames plus the applet itself) repeat inside the area where the applet is. It’s like a kaleidoscope or like a repeating fractal pattern kind of thing, or like when you take a picture of yourself in the mirror and you see the room repeated over and over in the mirror. In this case it repeats for each button press and the repeated set gets smaller each time. Weird!!
So, based on my research, the Java Next-Generation plugin works differently by allowing more than one process or thread whereas the classic plugin only uses a single thread. So my suspicion is that a new process is being spawned for each button press. I tried using the “separate_jvm” applet parameter but it made no difference whether it was set to true or false. I don’t see any other applet parameters which seem to be relevant.
Another idea I had is that maybe it’s something to do with the JSP frameset, maybe something like “target=_top” needs to be added somewhere…but I’m not sure how this relates to applet threads if at all.
Anyone have any suggestions, ideas or experiences that might help?
you can use velocity to handle these type of problem and it will also help you for future enhancement also.
The problem is not related to version of IE but rather to version of Java. Below excerpt from letter of certificate provider (they took it from some forum, so direct link to source cannot be provided):
For JDK version higher than 1.6.0 and below 1.6_15, you can just
clear all kinds of cache in web browser, java console and java control
panel. Then it should works fine!
For JDK version between 1.6_15 and 1.6_30, you should disable the "next-generation java" option in java control panel.
For JDK version higher than 1.6_30, you should turn on "next-generation java" option in java control panel.
First a disclaimer, I'm a Java programmer and have almost no idea about the Windows API. So please bear with me.
My goal is to use Java to capture a hidden window. My target platform is Windows. I do understand that the Robot class is used for capuring the visible part of the screen. After some browsing, I came across these three links, which seem to be relevant:
http://www.support.teamdev.com/thread/1930
http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.ui/2006-02/msg00204.html
http://www.fengyuan.com/article/wmprint.html
JxCapture is as bloodily expensive as Feng Yuan article is complicated. My question is this, if the gurus in this forum can help me find a reasonable solution. The approach suggested in JxCapture does not seem to be overly complex. Any hints? A visual basic script or some C# code that does this would be a good starting point.
I was of the belief that when the window is hidden, if I send a keypress event or a mouse press event to it, it would force it to redraw itself and hence allow itself to be captured even by java.awt.Robot. That was an illusion and it doesn't work.
On the other hand, the message in the JxCapture thread is from the year 2006; could it be that Sun has included such a feature since then and I'm just not aware of it?
I'm writing a genome browser designed primarily to view the history of chromosomal rearrangements. Right now the project is a series of proof-of-concept demos written using Processing. At this point if I don't make any radical changes the final application will be a web applet with a gui built of swing components that open PApplets to actually show the rearrangements happening.
My question is: Should I give up on processing and switch over to pure Swing/AWT? This is my first big java project. I'm building in eclipse, but I can use netbeans as well. If I could embed PApplet objects inside a JFrame, for example, that would make my day.
processing.core.PApplet extends java.applet.Applet, so it should be possible to embed
a PApplet in a java.awt.Frame, as discussed in the article Applet ⇒ application: Hybrid Switch Hitters. See also, Mixing heavy and light components.
Addendum: From the API, "Processing runs in a Frame and not a JFrame. However, there's nothing to prevent you from embedding a PApplet into a JFrame," except for the limitations mentioned above.
Keep in mind that I know almost nothing about either Processing or your project, so I can only give you general advice.
The question that you should ask yourself before every major design change: what problem am I trying to solve by making this change? If the current architecture works, then you should keep it. If it's not working, then you should start by defining the specific things that are wrong with it (which I notice you didn't do).
Some swing code I write in my computer behave different on my colleague's computer, and in my PC, and in my notebook.
I wonder, is there something I can do to my Swing applications behave the same in every computer?
I want to have sure a algorithm I've tested in my computer will work the same way in my clients computers.
E.g.
Problem to focus JTextField works fine in my notebook with Windows XP, but not in my collague's computer with Windows XP, nither in my work computer with Ubuntu.
obs. the specific JTextField problem is not the subject of this question.
Problems with Swing apps on different platforms are common and they are caused by the simple fact that no matter what level of abstraction Java offers it has to play ball at some point with the native components of the underlying operating system. Event though Swing only uses the windows(frame) and draw everything by itself - discrepancies are very very common.
I develop a mutliplatform Swing application - and users on Windows are reporting all sorts of issues that Linux users don't have and vice versa. Sadly there is no silver bullet for such problems - extensive testing and nasty fixes are the only game in town.
And everything come exceptionally buggy and dirty in the area of pluggable look and feels. For example - resizing a JSplitPane with metal or nimbus is super fast(as expected), but if you use GTK+ plaf, everything goes to hell. This is a more serious(performance) problem - visual problems(missing borders, components not fitting properly containers, etc) have no end... Despite all of this Swing continues to be one of the best bet for multiplatform desktop applications.
I wonder, is there something I can do
to my Swing applications behave the
same in every computer?
I'm working on a complex Java Swing app that is shipped on OS X / Windows / Linux so just like Bozhidar answered, the issues are all far too real.
For some components, if you happen to have some UI design/programming skills, you can simply write your own component: I realize it's probably not a helpful answer, but it works.
For example, we wanted a drop-down "find-as-you-type" popup list (like the one that appears when you start a search on Google's main search page) that would look and work the same on Linux/Windows/OS X. After trying countless of "solutions" full of Swing idiosynchrasies that would not work everywhere (like, guess what, focus issues ; ) we decided to simply write our own component "from scractch".
We can intercept mouse and keyboard events on both OS X / Windows / Linux: we can write a component that not only looks but also behaves identically on all three platforms.
In addition to the "find-as-you-type", we also wrote our own tooltip-popup component, a dual progress bar (to progress bar in one to show producer/consumer style progress in a single bar) and a complex component involving several "text fields" which was absurdly complex and broken when we tried to do it using Swing (and broken in different ways on different platforms, like weird focus issues or caret not showing, etc.). So we "went dirty" and rewrote the entire component ourselves.
Result? Working identically on all platforms where Java can give you notifications about mouse and keyboard events...
I realize this may not be what you want to hear: I happen to have worked on both games UI and mobile apps UI back in the days and I have some graphic skills so it's not "hard" for me to write good looking UI components.
Sadly if you want some Java UI component to look and behave identically on all platforms, it's sometimes your only alternative...
I want to have sure a algorithm I've
tested in my computer will work the
same way in my clients computers
An "algorithm" should work fine.
You get problems when you rely on the ordering of events, which may be different on various platforms. One of the most common I know about is holding down a key so that is repeats:
a) on Windows you get keyPressed, keyPressed, keyPressed, .... keyReleased.
b) on Unix you get keyPressed, keyReleased, keyPressed, keyReleased ...
By the way a comment would be nice as to whether my suggestion in your "textfield" posting works or not. As I mentioned, I don't have a Ubuntu platform to test it on, so I'm curious as to the result.
We have a Java Applet built using AWT. This applet lets you select pictures from your hard drive and upload them to a server. The applet includes a scrollable list of pictures, which works fine in Windows, Linux and Mac OS X 10.5. We launch this applet via Java Web Start or within a web page.
Our applet does not behave properly in Mac OS X 10.4, regardless of the version of Java (1.4 or 1.5). You can find a screenshot of the incorrect behaviour, when scrolling, here:
http://www.lavablast.com/tmp/ui_error.png
Simply put, sometimes when scrolling the pictures end up overlapping the header or footer of the application. This behaviour does not occur on other platforms. On Mac OS X 10.4, it shows the pictures in the incorrect location when scrolling, which would not be so bad if it refreshed the screen after painting the image at that location. However, it does not appear that the application knows it painted it incorrectly and thus does not refresh.
If the window is minimized, resized or even moved, the application is refreshed and the incorrectly positioned elements vanish and the application resumes normally. I spent quite some time trying to force a refresh of the background image unsuccessfully. (the repaint the image directly, repaint all children of a few panels, etc. ) Thus, I am looking for any tips that would help me resolve this problem under Mac OS X 10.4 or, in the worst case, simply simulate a full applet refresh.
Until recently, everything was compatible with Java 1.1 but this has changed in a few locations which now require 1.4. I don't feel these changes created the issue, I am just providing this as extra information. If you are interested in implementation details of the scroll panel, I will investigate, but I am assuming this is a common platform bug for which workarounds must be known.
To replicate the problem, open the following Java Web Start application:
http://www.lavablast.com/tmp/opal-webstart.php.jnlp
Select a folder containing lots of images and play with the scrollbar. At some point (fairly quickly), you should get the refresh problem.
Edit: I followed the first suggestion here and replaced all my controls that feature background images with a Swing equivalent and the issue is still there. (Plus, there are numerous other fixes I would need to do to do a complete change). Any other ideas? A simple one line of code that forces a full refresh would be great :)
Edit2: The main thread creates the panels and launches X threads. Using an observer/notifier pattern, the threads complete and notify the main control, which adds a panel to the page. This is done via an EventQueue.invokeLater which, unless I am mistaken, should run on the right thread. The issue is at its most severe when scrolling even if no extra threads are running (as during the loading).
It does look like mixing lightweight (usually Swing) and heavyweight (AWT) components together. Moving to Swing you need to replace every last AWT component Swing equivalents (hint: avoid import java.awt.*).
Threading is often a potential problem for odd bugs. Swing components must always be used on the EDT (use java.awt.EventQueue.invokeLater). AWT is thread-safe is theory, but not in practice - also restrict usage to the EDT.
As you already require Java 1.4 you should consider some small changes to take into use SWING GUI instead, it solved our Applet refresh issues with AWT. (Mac, Linux etc)
If you have e.g. Panel, you need to replace it with JPanel etc.
You need this:
import javax.swing.*;