Community
Participate
Working Groups
Unless the user sets the base Eclipse debug settings correctly (see http://eclipseme.org/docs/configuring.html#step4), the KVM will not be debuggable and will likely just crash. It would be nice when debugging is launch on a MIDlet suite if we checked the current debug settings and warned the user if they are not set up correctly. The dialog should also have a "Don't warn me again" checkbox.
Created attachment 106379 [details] patch for this bug
Created attachment 106381 [details] patch for this bug
sorry for resumit, the above two patches are same
The code was committed to the project SVN and the IP Log entry was added.
Created attachment 109641 [details] patch for this bug according to Craig's suggestion I revise the code according to craig's suggestion in the mailing list, what I do is: Hook the debugger setting check in EmulatorLaunchConfigDelegate, and add an org.eclipse.debug.core.statusHandlers extention in org.eclipse.mtj.ui plugin. Craig's email for this bug: "I figured out what is going on with this one and why I didn't see it in the first place. Given that the functionality is implemented in the EmulatorLaunchShortcut, it only applies when the shortcut is used to create a new launch configuration for a midlet. The next time the midlet is launched, it doesn't come through this path. If you happen to already have launch configurations in place because of a previous Run As... this code will never be triggered. To improve on this is quite a bit more difficult. It involves hooking into the org.eclipse.mtj.core.internal.launching.EmulatorLaunchConfigDelegate class. This class is invoked on every run and debug. There is a method called "preLaunchCheck" that is already hooked up to verify some midlet settings. This would be the appropriate hook for the debugger settings. The tricky part is that this is in the core plugin that does not (should not) have direct access to the user interface. Thus, it needs to be handled by the UI plugin using an extension to the org.eclipse.debug.core.statusHandlers extension point. You can see where this is already done in the current code to handle some other communication places between the core and the UI plugins. Since I'm traveling this week, I didn't want to get into this and not get it completed. If someone is willing to make the changes, I think it would work much better from the user's perspective if it is handled in this way. It will be more consistent and work no matter what the circumstances. In fact, it will work even if the user changes the debug settings back after we've altered them. I should be able to offer a bit of development support if there is any question on how to do this. I remember when I first had to get this going that it was tough to figure out how the pieces fit together. One other comment. The error messages that are shown in the dialog concerning the debug settings should probably be more specific and call out that the problems are related to MTJ/Midlet debugging. As currently worded it sounds like things are much worse than they really are... That is personal opinion on that one. Thanks, Craig"
My quick scan of the patch code shows that this is the correct approach. Just one question... Should we stop the debug launch if they don't update the debug settings or allow them to go ahead and try it? For the Java-based emulators, these changes are not necessary, so not allowing the launch may be a bit heavy-handed.
Hi Craig, I think we may not stop debugging if they don't update the debug settings, as you said, it still works without changing debug settings for some SDKs. by the way, thanks a lot for your good suggestion, I once saw that hook, and tried to add code there, but I couldnot find ways to handle the UI code. (In reply to comment #6) > My quick scan of the patch code shows that this is the correct approach. Just > one question... Should we stop the debug launch if they don't update the debug > settings or allow them to go ahead and try it? For the Java-based emulators, > these changes are not necessary, so not allowing the launch may be a bit > heavy-handed.
New patch is under review
New patch integrated. It will be available on next Integration build today. Craig, I agree with your comment about the error message. Are you OK with the message contributed by this patch or do you have a better suggestion?
This text is better.
Changing text per Craig's request: http://dev.eclipse.org/mhonarc/lists/dsdp-mtj-dev/msg00494.html
all bugs we integrated and release on MTj 0.9
