This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
After displaying the screen, the following exception comes. I looked at the source code and I haven't been able to figure out what can cause an NPE, all fonts are good. Is there any way I can run and install a custom version of the login screen? MIDlet: LoginScreenExample Exception in handleDisplayableEvent. Reason: NullPointerException source is : org.netbeans.microedition.lcdui.LoginScreen@7f487f48 p0 is : 360 p1 is : 240 p2 is : 0 java.lang.NullPointerException at org.netbeans.microedition.lcdui.LoginScreen.computeMetrics(Unknown Source) at org.netbeans.microedition.lcdui.LoginScreen.sizeChanged(Unknown Source) at javax.microedition.lcdui.Displayable.sizeChangedEvent(Displayable.java:263) at javax.microedition.lcdui.Canvas.sizeChangedEvent(Canvas.java:755) at javax.microedition.lcdui.Displayable.handleEvent(Displayable.java:163) at javax.microedition.lcdui.Canvas.handleEvent(Canvas.java:644) at javax.microedition.lcdui.Toolkit.handleDisplayableEvent(Toolkit.java:483) at com.symbian.lcdjava.lang.SystemExtensions._dispatchCallbacks(Native Method) at com.symbian.lcdjava.lang.SystemExtensions.dispatchCallbacks(SystemExtensions.java:35) at com.symbian.midp.runtime.KVMEventProcessor.run(KVMEventProcessor.java:23)
From the LoginScreen source the only potential source of NPE is inputFont or loinButtonFont manually set to null by calling setFonts(Font titleFont, Font inputFont, Font loginButtonFont). A risk might be usage of strong obfuscation, try to disable the obfuscation first and then try to find some lower level of obfuscation. A workaround might be to manually specify some fonts or tweak the LoginScreen component (sources are included in the library) and let me know. To reproduce the case I need to know what emulator (or real device) do you use.
I checked inputFont and loginButtonFont they are both non null and my app is only using netbeans generated code so I don't think that the cause is a setfont. I have obfuscation disabled. I found out the source but how can I use my own LoginScreen in conjunction with the generated code? This bug can be reproduced using both the symbian ^3 sdk and the S60 5th edition sdk.
I've just verified the behavior of LoginScreen on Symbian3 SDK and it works for me. I've also tested all combination of full screen, using the login button, adding ticker, lazy initialization as well as changing the screen layout. Also setting the fonts to null did not cause mentined NPE. Please add more information regarding the affected code or I'll have to close this issue as WORKSFORME.
Do you mind sharing your test project so that I can look at the differences with mine? Also I've seen another report of this bug in the nokia forums... I have a splash screen before I'm wondering if it is something else in the flow that might be the cause.
My test case is based on your issue description so I've just placed a login screen into a new mobile application flow and played with several options. If you have a case that is causing the NPE, please describe it here. If there are some other described cases on the Nokia forums, please link it here. I am sorry but without a reproducible case pointing to a bug in our login screen component I cannot help. LoginScreen.computeMetrics() method is pretty simple (about 30 lines of code) where I don't see any problem. You can also help us to locate the issue using debugger or by placing the source of the LoginScreen into your project and adding the debug outputs.
Created attachment 106892 [details] Repro for the bug 3 projects (1 main midlet - 1 dependent library - 1 test set)
I attached my projects that replicate the bug. The login screen displays correctly but throws that exception in the output window and I am not able to enter text in the login and password boxes. Starting the NToodledo midlet in the Symbian ^ 3 emulator should reproduce the problem (I just did a fresh install of Netbeans beta 2 and of the emulator).
Thanks for the use case. The NPE displays a race condition in the IBM T9 MIDP implementation inside the Symbian3. I found that sometimes a new Canvas (which is an ancestor of the LoginScreen) starts receiving resize events even before the constructor is finished. It is a critical bug in the MIDP implementation where the Canvas object is not yet initialized nor displayed and it receives some asynchronous calls. Canvas constructor performs some side registration before even finished so the fields (including fonts) are null or in undefined state during that time. This is a violation of basic object architectural rules. Interesting part is that a MIDlet originally constructed with 1 form and 1 canvas only does not throw NPE. Any more complex MIDlets can sometimes throw the NPE. According to my observations the NPE does not affect further functionality. I am keeping this issue open as we might find some workaround for the component to expect an unexpected call before the constructor is finished. Possible workaround would be to use an explicit construction flag for all components based on Canvas and test the flag in all potentially dangerous situations to avoid a premature calls of not-yet-initialized object. The other option is to ignore the NPE. By the way - a custom version of the LoginScreen can be placed directly into the project. The latest source can be taken from http://hg.netbeans.org/main/file/68830dcb1da5/vmd.components.midp/netbeans_midp_components_basic/src/org/netbeans/microedition/lcdui/LoginScreen.java
I am not able to enter data in the login and password field in the nokia emulator. It works fine on the official J2ME emulator. Are you able to enter data after the NPE? I did suspect it was a bug from the Nokia platform but since it happens on S60 and S^3, it would be nice to have a workaround. I haven't had much luch with a custom login form. Should I just copy the source and use the original package name? I tried doing so but the classpath seems to use the netbean class first. I also tried adding my own login form to the palette but then the generated code was wrong.
Entering the login credentials works for me even after the NPE. Key mapping is not perfect fitting the device but it works. Overriding of the classes from library path works. MIDP packaging requires to build a single Jar so the only one instance of the class file is always present on the classpath (in the application Jar). Libraries do not override application classes during the build.
Assigning to the new owner of javame modules.
Marking as WONTFIX, since no new Nokia S60 devices are being manufactured. Thanks for understanding.