Home » Eclipse Projects » Riena » [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen(This problem seems to be SWT-specific, but still...)
| |
Re: [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #542679 is a reply to message #542409] |
Fri, 25 June 2010 15:32 |
Christian Kesselheim Messages: 59 Registered: June 2010 |
Member |
|
|
Sorry for not making myself clear. The problem's that - on my particular MacOSX/Cocoa machine at least - the Widget-to-Ridget binding (e.g. Text.getText() <-> ITextRidget.getText()) does not seem to work for views implemented as a sub-class of org.eclipse.riena.navigation.ui.swt.login.AbstractLoginSplas hView.
Example:
// View.java
Text userWidget = UIControlsFactory.createText(inputArea);
addUIControl(userWidget, LoginController.RIDGET_ID_USER);
// Controller.java
ITextRidget userRidget = (ITextRidget) getRidget(RIDGET_ID_USER);
String ridgetText = userRidget.getText();
String widgetText = ((Text)userRidget.getUIControl()).getText(); // Don't do this in production code
On my Windows machine, the strings ridgetText and widgetText will be identical as soon as change propagation from widget to ridget has been properly triggered (e.g. the user has pressed enter or simply left the text field in question).
On my MacOSX, I found that this would only work for "standard" views displayed somewhere with the main shell. For views displayed from inside a splash handler though, changes are never propagated from widget to ridget unless the user really hits enter or "direct writing" has previously been set to true.
userRidget.setDirectWriting(true); // Now it works!
Wondering where this deviation in behavior between MacOSX and Windows originates from, I fired up the debugger and stepped through the code. What I found was that - on MacOSX/Cocoa and for views displayed form within a splash handler - the focusLost/focusGained events of the SWT Text widget where never raised reliably at the appropriate places (which is bad, because e.g. TextRidget relies on them to know when its internal textValue field should be updated):
// View.java
Text userWidget = UIControlsFactory.createText(inputArea);
addUIControl(userWidget, LoginController.RIDGET_ID_USER);
userWidget.addFocusListener(new FocusListener() {
@Override
public void focusGained(FocusEvent e) {
System.out.println("The focus has been gained!");
}
@Override
public void focusLost(FocusEvent e) {
System.out.println("The focus has been lost!");
}
});
Starting up the application, then using the keyboard or mouse to continuously move in and out of the text box created above, here's what's being displayed on Windows Vista 32bit:
... (the application starts, displaying the splash screen) ...
The focus has been gained!
The focus has been lost!
... (I start moving in and out of the field) ...
The focus has been gained!
The focus has been lost!
The focus has been gained!
The focus has been lost!
...
On MacOSX, only a singly focusGained()/focusLost() event gets raised when the splash screen is initially displayed (but NOT when I move the cursor in and out of the field after that):
... (the application starts, displaying the splash screen) ...
The focus has been gained!
The focus has been lost!
... (I start moving in and out of the field) ...
I have some ideas why this may be, all untested/nothing more than me taking a wild guess:
* Perhaps there's some special combination of SWT style bits or parent/child relationships that can trigger this behavior?
* I've seen (while digging deeper into Eclipse) that there's some special and especially nasty SWT Shell handling implemented for SWT widgets that are being displayed from within an Eclipse splash handler (e.g. see org.eclipse.ui.internal.WorkbenchPlugin.getSplashShell(displ ay)). For example, they seem to directly call Shell.internal_new(..) instead of going via the public constructor.
* Perhaps Cocoa itself is not reliably raising the focus events at times it should do so?
So far, I'm using the setDirectWriting work-around explained above, since the problem seems to only manifest itself within a splash handler. I just wanted to check with you if this was a "known issue" with Riena on MacOSX/Cocoa and whether or not there's a better work-around than mine.
Thanks again,
Chris
|
|
|
Re: [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #542756 is a reply to message #542679] |
Fri, 25 June 2010 21:12 |
Christian Campo Messages: 597 Registered: July 2009 |
Senior Member |
|
|
Am 25.06.10 17:32, schrieb Christian Kesselheim:
> Sorry for not making myself clear. The problem's that - on my particular
> MacOSX/Cocoa machine at least - the Widget-to-Ridget binding (e.g.
> Text.getText() <-> ITextRidget.getText()) does not seem to work for
> views implemented as a sub-class of
> org.eclipse.riena.navigation.ui.swt.login.AbstractLoginSplas hView.
> Example:
>
>
> // View.java
> Text userWidget = UIControlsFactory.createText(inputArea);
> addUIControl(userWidget, LoginController.RIDGET_ID_USER);
>
>
>
> // Controller.java
> ITextRidget userRidget = (ITextRidget) getRidget(RIDGET_ID_USER);
> String ridgetText = userRidget.getText();
> String widgetText = ((Text)userRidget.getUIControl()).getText(); //
> Don't do this in production code
>
>
> On my Windows machine, the strings ridgetText and widgetText will be
> identical as soon as change propagation from widget to ridget has been
> properly triggered (e.g. the user has pressed enter or simply left the
> text field in question).
>
> On my MacOSX, I found that this would only work for "standard" views
> displayed somewhere with the main shell. For views displayed from inside
> a splash handler though, changes are never propagated from widget to
> ridget unless the user really hits enter or "direct writing" has
> previously been set to true.
>
> userRidget.setDirectWriting(true); // Now it works!
>
> Wondering where this deviation in behavior between MacOSX and Windows
> originates from, I fired up the debugger and stepped through the code.
> What I found was that - on MacOSX/Cocoa and for views displayed form
> within a splash handler - the focusLost/focusGained events of the SWT
> Text widget where never raised reliably at the appropriate places (which
> is bad, because e.g. TextRidget relies on them to know when its internal
> textValue field should be updated):
>
>
> // View.java
> Text userWidget = UIControlsFactory.createText(inputArea);
> addUIControl(userWidget, LoginController.RIDGET_ID_USER);
> userWidget.addFocusListener(new FocusListener() {
> @Override
> public void focusGained(FocusEvent e) {
> System.out.println("The focus has been gained!");
> }
>
> @Override
> public void focusLost(FocusEvent e) {
> System.out.println("The focus has been lost!");
> }
> });
>
>
> Starting up the application, then using the keyboard or mouse to
> continuously move in and out of the text box created above, here's
> what's being displayed on Windows Vista 32bit:
>
>
> .. (the application starts, displaying the splash screen) ...
> The focus has been gained!
> The focus has been lost!
> .. (I start moving in and out of the field) ...
> The focus has been gained!
> The focus has been lost!
> The focus has been gained!
> The focus has been lost!
> ..
>
>
> On MacOSX, only a singly focusGained()/focusLost() event gets raised
> when the splash screen is initially displayed (but NOT when I move the
> cursor in and out of the field after that):
>
>
> .. (the application starts, displaying the splash screen) ...
> The focus has been gained!
> The focus has been lost!
> .. (I start moving in and out of the field) ...
>
>
> I have some ideas why this may be, all untested/nothing more than me
> taking a wild guess:
>
> * Perhaps there's some special combination of SWT style bits or
> parent/child relationships that can trigger this behavior?
> * I've seen (while digging deeper into Eclipse) that there's some
> special and especially nasty SWT Shell handling implemented for SWT
> widgets that are being displayed from within an Eclipse splash handler
> (e.g. see org.eclipse.ui.internal.WorkbenchPlugin.getSplashShell(displ
> ay)). For example, they seem to directly call Shell.internal_new(..)
> instead of going via the public constructor.
> * Perhaps Cocoa itself is not reliably raising the focus events at times
> it should do so?
>
> So far, I'm using the setDirectWriting work-around explained above,
> since the problem seems to only manifest itself within a splash handler.
> I just wanted to check with you if this was a "known issue" with Riena
> on MacOSX/Cocoa and whether or not there's a better work-around than mine.
>
> Thanks again,
>
> Chris
>
I had Elias, one of our committers, have a look at your mail and he is quit confident that this is a SWT problem. There
is nothing in Riena about it. You are observing a different behaviour on 2 platformss in SWT. That should not be so.
So we recommend that you create an SWT bug and attach an example that does not use Riena but just plain SWT. It should
have the same problem and its easier this way for the SWT team to reproduce the problem.....
christian
|
|
| |
Re: [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #586057 is a reply to message #542409] |
Fri, 25 June 2010 15:32 |
Christian Kesselheim Messages: 59 Registered: June 2010 |
Member |
|
|
Sorry for not making myself clear. The problem's that - on my particular MacOSX/Cocoa machine at least - the Widget-to-Ridget binding (e.g. Text.getText() <-> ITextRidget.getText()) does not seem to work for views implemented as a sub-class of org.eclipse.riena.navigation.ui.swt.login.AbstractLoginSplas hView.
Example:
// View.java
Text userWidget = UIControlsFactory.createText(inputArea);
addUIControl(userWidget, LoginController.RIDGET_ID_USER);
// Controller.java
ITextRidget userRidget = (ITextRidget) getRidget(RIDGET_ID_USER);
String ridgetText = userRidget.getText();
String widgetText = ((Text)userRidget.getUIControl()).getText(); // Don't do this in production code
On my Windows machine, the strings ridgetText and widgetText will be identical as soon as change propagation from widget to ridget has been properly triggered (e.g. the user has pressed enter or simply left the text field in question).
On my MacOSX, I found that this would only work for "standard" views displayed somewhere with the main shell. For views displayed from inside a splash handler though, changes are never propagated from widget to ridget unless the user really hits enter or "direct writing" has previously been set to true.
userRidget.setDirectWriting(true); // Now it works!
Wondering where this deviation in behavior between MacOSX and Windows originates from, I fired up the debugger and stepped through the code. What I found was that - on MacOSX/Cocoa and for views displayed form within a splash handler - the focusLost/focusGained events of the SWT Text widget where never raised reliably at the appropriate places (which is bad, because e.g. TextRidget relies on them to know when its internal textValue field should be updated):
// View.java
Text userWidget = UIControlsFactory.createText(inputArea);
addUIControl(userWidget, LoginController.RIDGET_ID_USER);
userWidget.addFocusListener(new FocusListener() {
@Override
public void focusGained(FocusEvent e) {
System.out.println("The focus has been gained!");
}
@Override
public void focusLost(FocusEvent e) {
System.out.println("The focus has been lost!");
}
});
Starting up the application, then using the keyboard or mouse to continuously move in and out of the text box created above, here's what's being displayed on Windows Vista 32bit:
... (the application starts, displaying the splash screen) ...
The focus has been gained!
The focus has been lost!
... (I start moving in and out of the field) ...
The focus has been gained!
The focus has been lost!
The focus has been gained!
The focus has been lost!
...
On MacOSX, only a singly focusGained()/focusLost() event gets raised when the splash screen is initially displayed (but NOT when I move the cursor in and out of the field after that):
... (the application starts, displaying the splash screen) ...
The focus has been gained!
The focus has been lost!
... (I start moving in and out of the field) ...
I have some ideas why this may be, all untested/nothing more than me taking a wild guess:
* Perhaps there's some special combination of SWT style bits or parent/child relationships that can trigger this behavior?
* I've seen (while digging deeper into Eclipse) that there's some special and especially nasty SWT Shell handling implemented for SWT widgets that are being displayed from within an Eclipse splash handler (e.g. see org.eclipse.ui.internal.WorkbenchPlugin.getSplashShell(displ ay)). For example, they seem to directly call Shell.internal_new(..) instead of going via the public constructor.
* Perhaps Cocoa itself is not reliably raising the focus events at times it should do so?
So far, I'm using the setDirectWriting work-around explained above, since the problem seems to only manifest itself within a splash handler. I just wanted to check with you if this was a "known issue" with Riena on MacOSX/Cocoa and whether or not there's a better work-around than mine.
Thanks again,
Chris
|
|
|
Re: [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #586068 is a reply to message #542679] |
Fri, 25 June 2010 21:12 |
Christian Campo Messages: 597 Registered: July 2009 |
Senior Member |
|
|
Am 25.06.10 17:32, schrieb Christian Kesselheim:
> Sorry for not making myself clear. The problem's that - on my particular
> MacOSX/Cocoa machine at least - the Widget-to-Ridget binding (e.g.
> Text.getText() <-> ITextRidget.getText()) does not seem to work for
> views implemented as a sub-class of
> org.eclipse.riena.navigation.ui.swt.login.AbstractLoginSplas hView.
> Example:
>
>
> // View.java
> Text userWidget = UIControlsFactory.createText(inputArea);
> addUIControl(userWidget, LoginController.RIDGET_ID_USER);
>
>
>
> // Controller.java
> ITextRidget userRidget = (ITextRidget) getRidget(RIDGET_ID_USER);
> String ridgetText = userRidget.getText();
> String widgetText = ((Text)userRidget.getUIControl()).getText(); //
> Don't do this in production code
>
>
> On my Windows machine, the strings ridgetText and widgetText will be
> identical as soon as change propagation from widget to ridget has been
> properly triggered (e.g. the user has pressed enter or simply left the
> text field in question).
>
> On my MacOSX, I found that this would only work for "standard" views
> displayed somewhere with the main shell. For views displayed from inside
> a splash handler though, changes are never propagated from widget to
> ridget unless the user really hits enter or "direct writing" has
> previously been set to true.
>
> userRidget.setDirectWriting(true); // Now it works!
>
> Wondering where this deviation in behavior between MacOSX and Windows
> originates from, I fired up the debugger and stepped through the code.
> What I found was that - on MacOSX/Cocoa and for views displayed form
> within a splash handler - the focusLost/focusGained events of the SWT
> Text widget where never raised reliably at the appropriate places (which
> is bad, because e.g. TextRidget relies on them to know when its internal
> textValue field should be updated):
>
>
> // View.java
> Text userWidget = UIControlsFactory.createText(inputArea);
> addUIControl(userWidget, LoginController.RIDGET_ID_USER);
> userWidget.addFocusListener(new FocusListener() {
> @Override
> public void focusGained(FocusEvent e) {
> System.out.println("The focus has been gained!");
> }
>
> @Override
> public void focusLost(FocusEvent e) {
> System.out.println("The focus has been lost!");
> }
> });
>
>
> Starting up the application, then using the keyboard or mouse to
> continuously move in and out of the text box created above, here's
> what's being displayed on Windows Vista 32bit:
>
>
> .. (the application starts, displaying the splash screen) ...
> The focus has been gained!
> The focus has been lost!
> .. (I start moving in and out of the field) ...
> The focus has been gained!
> The focus has been lost!
> The focus has been gained!
> The focus has been lost!
> ..
>
>
> On MacOSX, only a singly focusGained()/focusLost() event gets raised
> when the splash screen is initially displayed (but NOT when I move the
> cursor in and out of the field after that):
>
>
> .. (the application starts, displaying the splash screen) ...
> The focus has been gained!
> The focus has been lost!
> .. (I start moving in and out of the field) ...
>
>
> I have some ideas why this may be, all untested/nothing more than me
> taking a wild guess:
>
> * Perhaps there's some special combination of SWT style bits or
> parent/child relationships that can trigger this behavior?
> * I've seen (while digging deeper into Eclipse) that there's some
> special and especially nasty SWT Shell handling implemented for SWT
> widgets that are being displayed from within an Eclipse splash handler
> (e.g. see org.eclipse.ui.internal.WorkbenchPlugin.getSplashShell(displ
> ay)). For example, they seem to directly call Shell.internal_new(..)
> instead of going via the public constructor.
> * Perhaps Cocoa itself is not reliably raising the focus events at times
> it should do so?
>
> So far, I'm using the setDirectWriting work-around explained above,
> since the problem seems to only manifest itself within a splash handler.
> I just wanted to check with you if this was a "known issue" with Riena
> on MacOSX/Cocoa and whether or not there's a better work-around than mine.
>
> Thanks again,
>
> Chris
>
I had Elias, one of our committers, have a look at your mail and he is quit confident that this is a SWT problem. There
is nothing in Riena about it. You are observing a different behaviour on 2 platformss in SWT. That should not be so.
So we recommend that you create an SWT bug and attach an example that does not use Riena but just plain SWT. It should
have the same problem and its easier this way for the SWT team to reproduce the problem.....
christian
|
|
|
Goto Forum:
Current Time: Fri Apr 26 13:50:14 GMT 2024
Powered by FUDForum. Page generated in 0.03509 seconds
|