The fix looks fine to me. Thank you.
--
best regards,
Anthony
On 6/19/2012 8:41 PM, Leonid Romanov wrote:
Sounds like a good idea. Done:
http://cr.openjdk.java.net/~leonidr/7124239/webrev.02/
On 15.06.2012, at 23:02, Anthony Petrov wrote:
Hi Leonid,
93 NSApplicationAWT* theApp = (NSApplicationAWT*)[NSApplication
sharedApplication];
Actually, in case an SWT application is running, this conversion may
not work as expected. Should we possibly perform an isKindOfClass
check, and if it's not our application class, use the previous
approach (i.e. spin a single empty block through the event loop)?
Otherwise the fix looks fine.
--
best regards,
Anthony
On 6/15/2012 9:06 PM, Leonid Romanov wrote:
Hi,
I've adressed your comments in
http://cr.openjdk.java.net/~leonidr/7124239/webrev.01/
More specifically: 1. Removed )
2. After some consideration I've decided to use timestamp in order to
distinguish our event from others: seems like it's the most
bulletproof method. 3. You could be right. I've replaced the loop
with NSConditionLock machinery. On 14.06.2012, at 19:12, Anthony
Petrov wrote:
Hi Leonid,
1. In NSApplicationAWT: the NSLog("Here...") statements. I use such
debugging output, too! :) However, for production code please either
replace them with meaningful messages, or remove them altogether.
2.
344 - (void)sendEvent:(NSEvent *)event
I'm afraid that using the NSApplicationDefined and just skipping it
may conflict with other native toolkits, such as SWT, or some custom
native libraries. I think we should let such events go through the
[super sendEvent].
3. Isn't the loop in LWCToolkit.m too tight? There's an issue with
performSelector on the Mac in that selectors are processed strictly
before processing events. If the queue is flooded with posted
selectors, the event may never have a chance to be handled.
--
best regards,
Anthony
On 06/14/12 08:25, Leonid Romanov wrote:
Hi,
Please review a fix for 7124239: [macosx]
sun.awt.SunToolkit.InfiniteLoop exception in realSync called from
SwingTestHelper.
The problem is that syncNativeQueue() doesn't fully sync the native
queue. For example, if there are, say, 25 events in the native
queue waiting to be processed, nativeSyncQueue might return after
only one event has been processed. realSync() calls
syncNativeQueue() in a loop until nativeSyncQueue() reports that no
native events have been processed as the result of the call or the
maximum number of iterations (which is 20) has been exceeded (which
leads to the exception). And since there are more than 20 events in
the native queue, we get the exception.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124239
Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.00/
Thanks,
Leonid.
