Display sheet after drag?

Can you show us the bit of code where you show the sheet?

 

1) Are you sure encipherPanel!=null? Can you start a modal session for a sheet? Do you not start it for the window the sheet is attached to?

2) The docs do not say that the third parameter is optional.

 

The performSelector: methods simply send a message to an object just like you were calling the method directly, but they can do it after a delay, after the current method has exited the current scope, or from other threads and modes. I think you are right in thinking it's because you're inside a callback of an unconcluded drag operation. I have had instances where I needed to use this technique to get around calling from a method invoked by something else, including during sheet operations. In one app, I have a method that takes an NSTimer, invalidates it, and destroys it. But, it fails if I call that method from the method that the timer itself calls. That sounds like something similar to your drag callbacks. I would try using

Code:

[self performSelector:@selector(myDoStuffHereMethod) withObject:nil afterDelay:0];

-- or --

[[NSRunLoop currentRunLoop] performSelector:@selector(myDoStuffHereMethod) target:self argument:nil order:0 modes:[NSArray arrayWithObject:NSDefaultRunLoopMode]];

 

I think you're right, it doesn't seem to be available in Java.

You could probably achieve the same result using an NSTimer, just start a timer with a short interval, and when it fires, you can call the method in the normal way then.

 

Having checked the NSObject docs for Java and Objective-C there's a load missing from the Java version. The thing is Apple doesn't really care about the 'Java bridge' anymore. See this quote

which can be found here.

 

If performSelector: is not available, and using a timer doesn't work, maybe try to schedule the window action on the AWT event thread using the Java method SwingUtilities.invokeLater()? I know that (at least in the old days) there were some issues with calling Swing GUI components from the event thread. How Cocoa-Java works in this regard I have no idea, but maybe try something like this (called from your drag method):

Code:

Runnable doStuff = new Runnable() {
    public void run() {
        // do stuff here
    }
};

SwingUtilities.invokeLater(doStuff);

 

If it doesn't work with a timer, then something else must be wrong. You're definitely no longer in some kind of drag-mode.

 

Because you're a Java programmer? If you're Apple, wasting your time keeping up a Java bridge that very few people use for production apps seems a waste of time and money. Should they maintain a Cobol-bridge as well just to keep cobol old-timers happy?

 

According to Apple's "How to use Sheets documentation" your code isn't as it should be. Docs -> Cocoa -> User Experience -> Sheets

To show the sheet, just the two first lines should be sufficient.

To close the sheet, listen to actions from a button or something similar and call

Code:

nsapp.endSheet(encipherPanel)

there.

Then you need to order the sheet out when the endSheet is done, in Objective C you would have set a didEndSelector where this is done, but I don't know how to do that in Java.

Your third line shouldn't be anywhere at all if I read the docs correctly.

 

I'm not at all familiar with Java-Cocoa (nor much with sheets either), but the code above looks a little strange to me. runModalForWindow has been deprecated, and in the example above looks redundant. What occurs if you comment out that line?

Oops, gekko513 beat me to it..

 

Yeah, but have you tried writing it the way Apple describes on those pages?

 

But runModalForWindow was superceded by beginSheet; according to the documentation there's no need to call both. Even though the code you have may work in some cases, it still doesn't necessarily mean it's correct.

I'd try it as per Apple's docs, as gekko513 advises.

 

How do you keep the reference to the Window in question? Does the Cocoa-Java bridge require you to retain Cocoa objects you want to keep or is it all handled by Java's garbage collection?

 

Then I also see no reason why the references should all of a sudden be null. I can't see more solutions without seeing and playing with the code I think.

I still think the sheet code is a bit weird even if it works. Are you sure you need the line: nsapp.runModalForWindow(window1);?

 

How rude of it. Well, then I guess you have to keep it there. It's still strange, since it doesn't seem to be right according to the docs. (I sent you a PM)

 

I wasn't saying cobol was as modern as Java. I was trying to point out where do you draw the line on what languages you support. Apple supports two API's (Cocoa and Carbon) - one primarily for objective-C and the other primarily for C and C++ (I know you can mix and match if you want). There are a number of third party bridges to the Apple APIs (for example PyObjC) so you aren't exactly limited to just the languages Apple chooses to support. It is also worth bearing in mind that Microsoft has an awful lot more developers and money to throw at keeping their range of languages maintained. They also charge for their developer tools - hundreds of dollars if you want the grown up editions - whilst Apple gives it all away for nothing.

Besides I would have thought the main reason for using Java (other than you know it already or have assets already written in it) would be it's platform independence. By using java with Cocoa you've lost that advantage so all you're left with is it's disadvantages. There are alternatives to Cocoa you could use in Java that would retain your platform independence.

Cocoa is designed to be used by objective-C and it's littered with design decisions made on that assumption. Those assumptions don't necessarily apply to Java which has it's own way of doing things. Consequently the Java-cocoa bridge was always going to be the bastard child that no-one loved.