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.
[ BUILD # : 200510122200 ] [ JDK VERSION : 1.5.0_04 ] Hi, When I open my Visual MIDlet in either the Screen designer or the Flow designer I get following AssertionError, and the screen stays empty. I can only change my MIDlet by hand coding, none of the Visual functionality is working. java.lang.AssertionError at org.netbeans.modules.mvd.codegenerator.CommandActionSection.<init>(CommandActionSection.java:55) at org.netbeans.modules.mvd.codegenerator.CommandActionGenerator.createCollector(CommandActionGenerator.java:173) at org.netbeans.modules.mvd.codegenerator.CodeResolver.resolveAction(CodeResolver.java:71) at org.netbeans.modules.mvd.codegenerator.CodeResolver.access$100(CodeResolver.java:21) at org.netbeans.modules.mvd.codegenerator.CodeResolver$1.run(CodeResolver.java:45) at org.netbeans.editor.GuardedDocument.runAtomic(GuardedDocument.java:219) at org.openide.text.NbDocument.runAtomic(NbDocument.java:357) at org.netbeans.modules.mvd.codegenerator.CodeResolver.resolve(CodeResolver.java:40) at org.netbeans.modules.mvd.model.midp2.Midp2CommandActionDC.setActionSource(Midp2CommandActionDC.java:54) at org.netbeans.modules.mvd.model.actions.DActionComponent.setProperty(DActionComponent.java:216) at org.netbeans.modules.mvd.model.midp.MidpActionDC.setProperty(MidpActionDC.java:97) at org.netbeans.modules.mvd.model.helpers.PropertyAccessor$Accessor.writeProperty(PropertyAccessor.java:173) at org.netbeans.modules.mvd.model.helpers.PropertyAccessor$Accessor.access$100(PropertyAccessor.java:107) at org.netbeans.modules.mvd.model.helpers.PropertyAccessor.writeProperty(PropertyAccessor.java:71) at org.netbeans.modules.mvd.model.DComponent.writeProperty(DComponent.java:319) at org.netbeans.modules.mvd.model.DDocument.loadCore(DDocument.java:1387) at org.netbeans.modules.mvd.model.DDocument.load(DDocument.java:1185) at org.netbeans.modules.mvd.ui.editors.Designer.loadDesignData(Designer.java:1029) at org.netbeans.modules.mvd.ui.editors.Designer$9.run(Designer.java:582) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:471) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:904) Iwan
Iwan, is it reproducible with fresh userdir? If it is reproducible could you attach(or send by email) the affected MIDlet? Breh, look at it please. I'm increasing priority - assertion means(for me) that something went in wrong way and we should avoid such situations...
I haven't checked with an empty userdir, but I will tonight and let you know.
This assertion fails when there is a problem with guarded blocks of commandAction method. Exactly: There are three initial guarded blocks related to this method: header, body-start, tail. All of them must exist or none of them must exist in the source. Other states are forbidden. Could you send me the java source file to confirm my theory? If it is like this then the problem is how to get into this state of broken java source file. Please, could you send me steps to reproduce, when it happens again (starting with a fresh userdir and a new MVD file). Thanks.
Created attachment 26392 [details] The MIDlet code that causes the problem
Created attachment 26393 [details] The meta data that doesn't show as stated in the issue
I've attached the problematic MIDlet and the VMD to this issue. I think it might be related to device-fragmentation. In a previous version of NB5 (when it was still called 4.2) I noticed that guarded blocks are not handled well in pre-processor blocks. But that seems to be solved, since I didn't get those problems anymore, or I might have worked around them unconsiouscly. Thanks, Iwan
The theory is confirmed. The device-fragmentation could be reason why gurded-blocks are incorrect. Have you mentioned any changes in the guarded-blocks positions during/after writing the preprocessor directives or before/after saving the file?
Hmmm, I'm not aware of any changes in the guarded blocks vs. de pre-processor blocks, but then again, I might have. I've been working mainly in the source- editor, but had to change a screen yesterday night and that's when I noticed this. But on the other hand, I didn't get any error during compilations, so my guess is that the code is still valid, the functionality of the MMIDlet is at least. I am not aware to have placed guarded blocks in pre-processor blocks. What do you propose to be done? For one I think that it is not desirable to have these two major features of NB MobPack to invalidate eachother, and in the meantime I'm not able to change my form. If you could point me into the direction as to how to fix my MIDlet, I'll fix it and maybe you guys can prevent this from happening in the future? Iwan
That's weird because I think that the guarded-blocks have to be broken before you have switched to Screen Designer. Is the source code (in the attachment) of the state (saved) before you have switched to Screen Designer? I have corrected your file - see attachment. You have to open the file in IDE, do some change in designer (best if you just move one node in Flow), switch to the Source tab, and save the file. I did not test, whether the whole is correct because I do not have all your custom components. I hope I did not make a mistake. If you will experience any problem, let me know. When I was looking at the changes in the file, I saw: All GEN-BEGIN, GEN-LINE and some GEN-END markers of guarded-blocks were moved one or more lines up and some GEN-LINE have grown one or more lines up. This looks like a problem in java module. Maybe it could be caused by a race-condition in java when a file is modified by preprocessor modules.
Created attachment 26398 [details] Corrected source file - some parts has to generated again by IDE
This issue is 100% reproducible: 1) Have a project with two different configuration 2) Create a MVD file. 3) Add a preprocessor block before guarded blocks. The preprocessor block must be active in default and inactive in second configuration. Bigger is better. 4) Close Editor 5) Restart IDE 6) Open the file 7) NOTE - at this time the document is opened but guarded-block positions are loaded incorrectly. 8) Move a screen node in the flow. 9) Switch to Source tab. 10) ERROR - Guarded-blocks are broken. This could be fixed by a change in J2MEEditorSupport.loadFromStreamToKit method. The method must create a new inputstream that will contain valid/preprocessed text from the original stream and use this new stream for super.loadFromStreamToKit method call.
fixed J2MEEditorSupport.loadFromStreamToKit method
Sorry for not setting this one to verified sooner.
close old issues