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.
When adding static list elements to a List in VMD then code is always generated for the conditions (via inices or string comparison). My experience is that such handling is done first when one presses OK or similar rather than on the spot, so I would like to be able to turn off this code creation. In that case it would still be interesting with a post-action "slot" for own code.
I do not know whether I did under you exactly. I think you would like to add/enter your own user code into commandAction method for a case where an user presses the select button in a list. In current Designer, there is no support for it. There is a strict code pattern used. Anyway you can workaround it using: Enter you user code (including the "if" checking) into global-pre-action-section at the begining of the commandAction method. For example: public void commandAction (...) { // global pre-action user code if (displayable == myList) if (command == myList.SELECT_COMMAND) { ...<MY_CODE>... return; } ...<AUTO_GENERATED_CODE>... }
No, that's not it, I think :). I make a list containing List Element 1 to 3. Then the following action code is generated, yet I'm not interested in this, as I will only perform any activities when Ok is selected. This is even more obvious if I have a form with multiple lists (typical case: application preferences). The typical case would be to not activate/save etc the preferences until Ok (or whatever) is selected or Cancel (when all settings should be ignored). public void commandAction(Command command, Displayable displayable) { // Insert global pre-action code here if (displayable == list1) { if (command == okCommand1) { // Insert pre-action code here exitMIDlet(); // Insert post-action code here } else if (command == list1.SELECT_COMMAND) { switch (get_list1().getSelectedIndex()) { case 0: // Insert pre-action code here // Do nothing // Insert post-action code here break; case 1: // Insert pre-action code here // Do nothing // Insert post-action code here break; case 2: // Insert pre-action code here // Do nothing // Insert post-action code here break; } } } // Insert global post-action code here }
All in all, it just generates code that is not used. The code generated is not buggy in any way. Ideal for late data validation is simply this code (based on the previously posted example): public void commandAction(Command command, Displayable displayable) { // Insert global pre-action code here if (displayable == list1) { if (command == okCommand1) { // Insert pre-action code here exitMIDlet(); // Insert post-action code here } } // Insert global post-action code here }
In this case we cannot remove "switch" statement because: 1) we have to allows users to write their own code (pre-action, post-action) to each case. 2) it is automatically generated for each list, It would be possible to introduce List.globalAction boolean property that would represent whether there should be a single global handler or a handler per each switch case. It is not easy implement because it affects Model/Flow/Properties parts of Designer. We are planning to implement this missing functionality in future versions.
I work around this now by not inserting any static list elements, and I then append list elements in code instead. That's in any case better from a future translation point-of-view.
I think that you can leave these list elements there as before. If you do not enter any user code into any of switch cases, then everything is an "empty" code, which is automatically removed by obfuscator. It has just one negative thing: the source code contains a few redundant empty-code lines.
Right, but by leaving the lists empty (from VMD's point-of-view), I don't even get redundant empty code.
Yes, I know. Your code is correct. I just wanted to say: Since VMD does not know about it, you have to care_about/manage these list elements completely without any support.
moving to mobility component