a=edburns
This checkin mainly does two things:
1. Correctly populates the java.awt.event.MouseEvent subclass with the
correct modifiers, x, y, and clickCount for the mozilla mouse event.
2. Adds a performance optimization: previously, every mouse event was
causing a new instance of java.util.Properties to be created. Now,
only one Properties instance is created per-page, and it is cleared on
each mouse event.
Also, I made the DOMMouseListenerImpl constructor initialize the
refCount to 0. This allows the object to be correctly deleted.
M classes_spec/org/mozilla/webclient/test/EMWindow.java
M classes_spec/org/mozilla/webclient/wrapper_native/WCMouseListenerImpl.java
M src_moz/DOMMouseListenerImpl.cpp
M src_moz/DOMMouseListenerImpl.h
M src_moz/WindowControlImpl.cpp
M src_moz/jni_util.cpp
M src_moz/jni_util.h
M src_moz/jni_util_export.cpp
M src_moz/jni_util_export.h
M classes_spec/org/mozilla/webclient/test/EMWindow.java
* Added test code for MouseListener properties: buttons, modifiers, etc.
M classes_spec/org/mozilla/webclient/wrapper_native/WCMouseListenerImpl.java
* Added support for mouse modifiers. Pull values out of the hash table,
put them in the MouseEvent constructor.
M src_moz/DOMMouseListenerImpl.cpp
* Modified constructors so they initialize all ivars.
* changed usage model of properties object to share the lifetime of the
DOMMouseListenerImpl instance. Needed to make use of the new function
util_ClearPropertiesObject() to do this. Now we have only one call to
util_DestroyPropertiesObject(), in the DOMMouseListenerImpl
destructor.
M src_moz/DOMMouseListenerImpl.h
> virtual ~DOMMouseListenerImpl();
>
98a101
> protected:
100a104,105
>
> void JNICALL addMouseEventDataToProperties(nsIDOMEvent *aMouseEvent);
M src_moz/WindowControlImpl.cpp
* Initialize new WebShellInitConext member propertiesClass to nsnull
M src_moz/jni_util.cpp
* Added util_ClearPropertiesObject() an optimization.
* Store the jclass for java/util/Properties in an element in
WebShellInitContext. This prevents us from having to do FindClass
each time a mouse event occurs.
* Added a parameter to util_StoreIntoPropertiesObject.
M src_moz/jni_util.h
* Added propertiesClass to WebShellInitContext
* Added new method ClearPropertiesObject
* Added new last argument to DestroyPropertiesObject
M src_moz/jni_util_export.cpp
M src_moz/jni_util_export.h
* Added function pointer for util_ClearPropertiesObject.
1.Added Dave Lawrence's excellent RedHat Bugzilla differences section verbatim.
2.Added more information on Loki Bugzilla ("Fenris").
3.Added questions from some corporate customers
4.Removed unused text in API section
5.Added information about other documentation (pending)
6.Added a section for pointy-haired-bosses
7.This will be the last release in strictly HTML format. Source will be SGML shortly, with HTML and TXT versions
included with the package from this point on
Subject:
Odd behaviour on placement of .jar files?!
Date:
Mon, 05 Jun 2000 10:46:08 -0700
From:
John Raykowski <xski@xski.org>
To:
nboyd@atg.com
Hello,
I didn't want to post this directly as a rhino bug 'coz I think it may
be more of a JDK thing, but I thought I'd toss it to you as well.
The goal is to create a JavaScript object that implements a Java
interface. Straightforward enough and the example on the page using
ActionListener works without a hitch. However, when I try to do the
same with my own interface, I get an error message: error instantiating
({0}): class {1} is interface or abstract (coming from
NativeJavaClass.construct).
Here's where it gets a bit strange. Normally, I run with the jar files
in jre/lib/ext. When I remove the rhino files from jre/lib/ext and
reference them explicitly on the commandline with the -cp option, it
works as expected and my script can implement the interface just fine.
Go figure.
Anyhoo, there ya go. Like I said, I think its a JDK issue, but I
thought you'd be interested. The attached zipfile contains a set of
sample code to demonstrate this problem.
Thanks heaps,
-jmr