I just completed the export of my RCP application for Windows and I noticed some strange behavior when testing the app on computer with 2 monitors.
The first time the application is launched, the splash screen and the main apllication windows are displayed on the primary monitor => it's ok !!!
Then I move my application on the second monitor and close it. Relaunch the app displays the splash screen on the second monitor, it's perfect, but it then brings the application window on the first monitor => it's boring and not the expected behavior ...
My Eclipse SDK doesn't have this problem, it simply opens at the last location. I guess I am missing something in my RCP in order to have the same behavior.
Any idea on the subject will be really helpful for me because after many "googling" I was not able to solve my issue.
Thanks in advance for your help
Manu
Did you try some kind of workbench customization, using the IWorkbenchConfigurer like in this example?
// in preWindowOpen(IWorkbenchWindowConfigurer configurer)
Dimension dim = java.awt.Toolkit.getDefaultToolkit().getScreenSize();
configurer.setInitialSize(new Point((int)dim.getWidth(),
(int)dim.getHeight()));
Or:
if you use configurer.setSaveAndRestore(true); in your initialize() then the rcp re-opens in the last used size.
Since it only set the size, it may not be enough in your (double-screen) case though.
Related
I'm using xcuitest framework to automate mac application. I get system dialogs when the app is opened again after it crashes. I want to handle the dialog programmatically. But the dialog appears under the process `UserNotificationCenter' instead of the application under test. How can I handle the alert in such case?
You have two options:
Use InterruptionMonitor (documentation, use-case). This
approach is however kinda old and I found, that it does not work for
all dialogs and situations.
Create a method, which will wait for some regular app's button. If the app's button (or tab bar or other such XCUIElement) is visible and hittable after your app started, you can proceed with your test and if it's not, you can wait for the UserNotificationCenter dialog's button and identify&tap it by its string/position.
I'm using the second approach and its working much better, than the InterruptionMonitor. But it really depends on your app layout and use-case.
You should be able to revent it from appearing in the first place. Something like:
defaults write com.apple.CrashReporter DialogType none
I am moving my e4 rcp application( SWT + jface) to pure e(fx)clipse (JavaFX) and I want a splash screen in application with progress bar like eclipse do have.
Can anyone suggest what should i do?
I Checked this answer from tom but I didn't understand where I can load stage in e(fx)clipse application?
[Edit:1]
As of now there is not Progress bar support for e(fx)clipse. And This helps to load splash with minimum efforts for novice.
[Edit:2]
One more thing i have observed as mentioned in forum.
Splash screen is visible at background to application.
First of all yes OSGi-Application built on e4-JavaFX don't implement the Application class themselves because this needs to be done as part of the OSGi-Lifecycle.
Once you accepted this situation you have multiple choices:
you bring up a kind of splash through the lifecycle hook with the caveat that it gets up after JavaFX and OSGi have been initialized which might take some time
if you are on windows/linux you can still use the equinox hook with the only caveat that we bring this one done very early because we can not bring it down on the JavaFX thread
you adjust the bootstrapping of Equinox-OSGi-Applications and do the launch yourself
If you really want to discuss this stuff in depth than I suggest you post to our forum - https://www.eclipse.org/forums/index.php/f/259/
I have a GWT application, with some buttons. These buttons seem to be unresponsive sometimes, i.e., clicking on them does nothing. Has anyone faced this problem before ? is it to do with the browser compatibility ?
PS: I am running the GWT development mode on MAC OS if that is relevant at all.
I encountered this in the past when an element in the widget hierarchy was added via getElement().appendChild() instead of .add()
See http://comments.gmane.org/gmane.org.google.gwt/78360 for a related thread.
-Clint
...and this broken state persisting until a device restart, since a naive attempt to restart an app would not work. Many users are not savvy enough to know how to terminate services/backgrounded apps. If the user can't (or doesn't 'need to') close apps, then what about restarting apps which have gone wrong? ( It can happen :) ) If my app goes wrong on someone's phone and they cannot easily restart the app without restarting the phone, that seems like a problem. I am aware that apps and services can be terminated by navigating system menus or double tapping the home button etc. but - many users are not aware of these features. For this reason I am thinking of adding an explicit close button to my app which will kill everything to the best of my ability, such that on a subsequent launch the program runs from the beginning again. I realise this is not the 'recommended' approach. Thoughts?
Thoughts?
Don't do it. Instead you should put a FAQ entry on your apps website that says.
Q: My app does not run anymore. HELP!
A: First you should try to restart the app. If that doesn't work feel
free to contact me.
Here is how you do this on the iPhone,
iPad or iPod.
double press the home button. the
multi tasking bar appears.
[ some screen shots ]
long press the app icon and press the
little x that appears on the icon.
[ more screenshots ]
If you want to put buttons for functions that are not obvious for many users you end up with a button for everything. And I (as somebody who knows every function) don't want a button cluttered user interface.
You would be surprised how many emails I get about "how can I zoom?" (A: Pinch your fingers) or "how do I delete an entry (in a tableview)" (A: Swipe your finger over the entry from left to right, and press the red delete button).
If I get an email about this I just point them to the faq which has some nice screenshots.
Btw, if the "broken state" happens so often that you would consider adding a special button I would check my code for bugs again.
I have an iphone app with a modal view. The app crashes when the modal view get dismissed.
As soon as the modal disappear at the bottom of the screen, and consequently the original view is shown behind, then the app crashes with no entry in console view.
I have tried to switch debugger on and I discovered that the app just run fine, with no crashes at all.
-First, I would like to know why such behaviour, shouldn't the debugger sit just on top without "disturbing" the app ?
-Second, without debugger, can you point out what should I look at to solve my problem ? Or if you encounter something similiar ? Please be as much specific you can, because I am not an expert in objective-c programming.
I don't know what details to give you, the app is a normal one with standard iphone component, but for start I can say the modal view (which is built with IB) is called inside a NavigationBar system.
thanks
When these types of things happen, it is almost always because of memory allocation issues. The first step I would take is to do a "Clean All" and a "Build and Analyze", and look at all the analysis warnings. Analyze is very good at finding basic "use before allocate", "use after deallocate", or "wrong number of retains/releases" types of problems.
The next step is to turn on "Zombie" detection mode, which looks for accesses on memory that has already been deleted (in other words, killed objects coming back from the dead.) To do this, get info on your executable, go to the Arguments tab, and add a "variable to be set in the environment" of "NSZombieEnabled" to value "YES". Then look in the console when you run to see if something looks off.
Finally, you might try creating a new configuration where you use all the release mode settings for optimization, but add debug symbols. Maybe that will shake up the allocation disbursement in memory enough to trigger the bug in debug mode.