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.
- observed behavior Editing Table Columns using the Customizer Dialog corrupts table model. - expected behavior Change table columns titles or expressions - steps to reproduce -start IDE -create Java Desktop Database Application -create a form using Master/Details Sample Form -right click on the generated table and choose Table Contents... -click on the Columns tab -change a row Title (or Expresion) and Close -launch developed application -when the form should be shown an exception rises (see attached stack trace) - The bug is present on Netbeans 6.9 milestone too JDK version: 1.6.0_16
I found that the exception is not raised on new projects. I get it modifying an existing JTable content.
I am sorry, I am not able to reproduce this issue - the mentioned steps do not result in any exception on my machine. Could you, please, provide more details? You even forgot to attach your exception.
Created attachment 95516 [details] stack trace
If I try to change table columns titles or expressions on my existing JFrame, the exception is raised, even if I create a new JTable. If I create a new JFrame and I try the same steps, the exception is NOT raised. Then it seems that my JFrame was corrupted.
If you attach your problematic JFrame into this issue (or send it to me privately, in case you don't want to make it public) then I will try to find out where the problem is.
Created attachment 95556 [details] Exception involved GUI files
Thank you Jan, I attached files involved about the exception
The attached exception and the attached files do not match. The exception is thrown on line 1182 while the corresponding code in the attached file is on line 1136. Hence, I am not sure if the attached file is in the state that leads to an exception. In any case, I skimmed over it and I don't see the problem. The exception shows that the table column model is not initialized for some reason. Normally, it should be intialized by jTableBinding.bind() call if the table is bound to non-null list. Unfortunately, I cannot help you more because I am not able to execute this class. I suggest you to try to debug your class and any other form (that uses a JTable bound to a DB table) and try to find where is the difference. The first thing I would check are values of 'list' and 'masterTable.getColumnModel().getColumnCount()' expressions before and after execution of jTableBinding.bind() call.
I found the answer to this problem on this Netbeans Forum post http://forums.netbeans.org/viewtopic.php?p=62049. Here is the cause and the workaround: The ArrayIndexOutOfBoundsException is thrown because the ColumnModel of the detailTable is not initialized immediately (when the table is bound). This is a problem of the Beans Binding library. 1. Select the detailTable. 2. Select the elements property in the Binding section of the Proeperties window. 3. Invoke the binding customizer (e.g. press '...' button). 4. Switch to Advanced tab. 5. Press '...' button next to Unreadable Source Value. 6. Select 'Custom code' from the combo-box at the top. 7. Enter java.util.Collections.emptyList() into the Property Code text-field. 8. Press OK to close the property customizer for Unreadable Source Value. 9. Press OK to close the binding customizer. Note that the original code generated by NetBeans contains this workaround. You removed it by unbinding the table (in step 4 of your test-case).
> I found the answer to this problem on this Netbeans Forum post > http://forums.netbeans.org/viewtopic.php?p=62049. I know this workaround, it comes from me ;o). Does it really help in your case? It is designed for detailTable, not for masterTable. In general, the workaround is usefull when the table is bound to some expression that can have null value. Your masterTable is bound to 'list'. I don't see how it can be null. Hence, I don't see how the workaround can help in your case.
My problem was not only with masterTable... However thank you for this workaround! :-)