Ulf Dittmer wrote:Comparing strings using the "==" operator ...
If the jar file was signed, no security exception would be happening in the first place.
Ulf Dittmer wrote:
Since the library is open source you could check out why it's performing this operation, and maybe patch that out; if you're just wanting to use some of its GUI features, then I agree there should be a way to do that without resorting to potentially forbidden reflection features.
getDeclaredMethod
public Method getDeclaredMethod(String name,
Class<?>... parameterTypes)
throws NoSuchMethodException,
SecurityException
Returns a Method object that reflects the specified declared method of the class or interface represented by this Class object. The name parameter is a String that specifies the simple name of the desired method, and the parameterTypes parameter is an array of Class objects that identify the method's formal parameter types, in declared order. If more than one method with the same parameter types is declared in a class, and one of these methods has a return type that is more specific than any of the others, that method is returned; otherwise one of the methods is chosen arbitrarily. If the name is "<init>"or "<clinit>" a NoSuchMethodException is raised.
Parameters:
name - the name of the method
parameterTypes - the parameter array
Returns:
the Method object for the method of this class matching the specified name and parameters
Throws:
NoSuchMethodException - if a matching method is not found.
NullPointerException - if name is null
SecurityException - If a security manager, s, is present and any of the following conditions is met:
* invocation of s.checkMemberAccess(this, Member.DECLARED) denies access to the declared method
* the caller's class loader is not the same as or an ancestor of the class loader for the current class and invocation of s.checkPackageAccess() denies access to the package of this class
Since:
JDK1.1
Ulf Dittmer wrote:That class can be found at https://swing-layout.dev.java.net/servlets/ProjectDocumentList?folderID=11880&expandFolder=11880&folderID=0.
As an aside, Java 6 is available on Intel Macs running OS X 10.6 (a.k.a Snow Leopard), but there are still many OS X users who don't have that, so it seems wise not to assume that Java 6 is available on OS X.
Rob Camick wrote:
I wish that JButton had a method pressButton() that I could call from within the program
Michelle Kyamo wrote:It seems I can only make the attributes in StyleConstants work, not anything in TextAttribute.
I reduced the font size of the superscript a little, which makes the problem a little less (the underlines are offset still, but less so).
Darryl Burke wrote:If all else fails, you could try applying the UNDERLINE_LOW_ONE_PIXEL / UNDERLINE_LOW_TWO_PIXEL attribute to the superscripted text.
Paul Clapham wrote:I don't know but I'm going to speculate.
What you are seeing is superscripted underlined characters. (Which is something that I have seen in print.) What you want to see is underlined superscripted characters. (I haven't seen that in print but it seems like a reasonable thing to want.) Perhaps the order in which you set up the styling makes a difference? Perhaps not, that's just a guess.
pete stein wrote:
Michelle Kyamo wrote:Thanks, I will read that tomorrow. Does that mean it's a bad idea to be using Swing and non-Swing things in the same applet?
Yes, in general it's a bad idea, unless you have a darn good reason for doing so, and really know what you are doing and why.