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.
A JFrame file created in Matisse contains a JPanel file also created in Matisse. For a couple of days now, attempting to edit these files will hang NetBeans. The EDT thread is in a waiting state. The first time it happened, I was attempting to visually edit the JFrame, and selected the internal JPanel in hte form. At this point, NB hung. I now find that this will occur at various poins during the editing of these files. I have removed the JFame, and recreated a new JFrame, but when I include the JPanel, I again experience freezes. I have tried the project on a different machine, but it also hangs. I have been working with these files intensively for some weeks now, and this problem has only occurred within the last two or three days. Has there been any upgrade to these components recently? The log file contains logging output from the _execution_ of code in the JPanel, which makes no sense at all, but would explain why the GUI freezes. The JPanel is not meant to be run in isolation. Note: I can provide the whole porject if need be. I suspect this issue may be the same as #157060.
Created attachment 76326 [details] NetBeans log file
Created attachment 76327 [details] Thread dump
The interesting part of the log file is this: INFO [au.id.pbw.linefold.tests]: ParagraphLayoutPanel.paintComponent LineBox list is null. ResizeDimensions constructor available_width, height seq 408.0, 454.0 1 AWT-EventQueue-1 INFO [au.id.pbw.linefold.tests]: ParagraphLayoutPanel.paintComponent LineBox list is null. INFO [au.id.pbw.linefold.tests]: ParagraphLayoutPanel.paintComponent LineBox list is null. INFO [au.id.pbw.linefold.tests]: ParagraphLayoutPanel.paintComponent LineBox list is null. INFO [au.id.pbw.linefold.tests]: ParagraphLayoutPanel.paintComponent LineBox list is null. INFO [au.id.pbw.linefold.tests]: ParagraphLayoutPanel.paintComponent LineBox list is null. INFO [au.id.pbw.linefold.tests]: ParagraphLayoutPanel.paintComponent LineBox list is null. INFO [au.id.pbw.linefold.tests]: ParagraphLayoutPanel.paintComponent LineBox list is null. In get_last_resize This is runtime information from the JPanel, whcih should nto be executing at all.
The thread dump shows that EDT thread is locked after calling au.id.pbw.linefold.tests.ParagraphLayoutPanel.getLast_resize. So it seems the ParagraphLayoutPanel is responsible for that. It is part of the GUI form, so it gets instantiated when the form is opened. It seems the last_resize property is set, the GUI builder tries to check its current value, but calling the getter method hangs. Please check ParagraphLayoutPanel's code to see what it is doing - I think the problem is there. Closing this report as invalid as it does not seem to be a bug in GUI builder. Please attach here your GUI form and the component with full source code if you think otherwise.
Re-opening. I don't know what Matisse is doing, but it's not what it used to do. The project I will attach is called LineFold. There are support jars which I will attach in hyfo.tar.gz. The project can be built and run, by running ParagraphDisplay in au.id.pbw.linefold.tests. The project has bugs, but it will display paragraph data, providing you have the following files available. private String arial = "/usr/share/fonts/truetype/arial.ttf"; private String arial_it = "/usr/share/fonts/truetype/ariali.ttf"; private String micross = "/usr/share/fonts/truetype/micross.ttf"; private String lucida_uni = "/usr/share/fonts/truetype/l_10646.ttf"; private String raghu = "/usr/share/fonts/truetype/raghu.ttf"; private String luxi = "/usr/share/fonts/truetype/luxirr.ttf"; private String luxi_it = "/usr/share/fonts/truetype/luxirri.ttf"; You can resize the form and the paragraph data will re-display. If I go to the ParagraphDisplay design window, and try to change the default value of the tolerance slider to 10, NB hangs. In some circumstances, if I make changes to the source text of ParagraphDisplay or ParagraphLayoutPanel, NB will hang. By running ParagraphDisplay, I see that the interactions between the two forms are working when run i the order I specify. How am I supposed to design form elements with complex timing relationships if Matisse goes off an executes one or other component independently? How am I supposed to design such forms when Matisse executes in the EDT code which is designed specifically to run in a separate thread, to prevent hanging in the EDT? Until recently, I was able to make changes to the form in ParagraphDisplay without such problems. Changes included the introduction of the tolerance slider. However, I cannot say that changes to synchronization, etc, did not happen after my last changes to the form.
Created attachment 76424 [details] Project containing the form
Created attachment 76425 [details] Support jars for project
Pavel, could you test this with attached project/jars ? Thanks in advance.
Tested on NetBeans IDE 6.5 (Build 200811100001) Java: 1.6.0_07; Java HotSpot(TM) Client VM 10.0-b23 Ubuntu 8.04 and Windows XP I can confirm the reported behavior. It is easily reproducible. The IDE hangs after changing a property of a component (e.g. the slider), or after modifying the form's source code and saving the file.
In the code I have sent you, the method ParagraphLayoutPanel.init_para() is called from the ParagraphDisplay constructor, after the initComponents() call. I have modified it so that ParagraphLayoutPanel.init_para() is called from within the constructor of ParagraphLayoutPanel itself, following initComponents(). The behaviour differs. The text of the paragraph now displays in the panel in design view. I was able to modify the value field of the toleranceSlider from 40 to 10 in display mode, and the change was accepted. However, when I tried to change to source view, the hang occurred again. The messages.log includes SizeChangeMonitor.run propertyChange AWT-EventQueue-1 SizeChangeMonitor.run get a resize event In ParagraphLayoutPanel.get_last_resize SizeChangeMonitor.run propertyChange worker is done AWT-EventQueue-1 ParagraphLayoutPanel.get_last_resize pool-3-thread-1 In paintComponent In paintComponent (.. an number of these...) In paintComponent In paintComponent WARNING [org.openide.util.WeakListenerImpl]: Can't remove java.beans.PropertyChangeListener using method removePropertyChangeListener from sun.awt.X11.XToolkit@f84386 In paintComponent In paintComponent In paintComponent In paintComponent ParagraphLayoutPanel.get_last_resize AWT-EventQueue-1In ParagraphLayoutPanel.get_last_resize ParagraphLayoutPanel.get_last_resize AWT-EventQueue-1 Note the initial instances of ParagraphLayoutPanel.get_last_resize pool-3-thread-1 in a pool thread. At the time of the hang, this becomes ParagraphLayoutPanel.get_last_resize AWT-EventQueue-1 Now it's running in the EDT. ??
> How am I supposed to design form elements with complex timing relationships if Matisse > goes off an executes one or other component independently? How am I supposed to design > such forms when Matisse executes in the EDT code which is designed specifically to run > in a separate thread, to prevent hanging in the EDT? It's actually pretty simple, let me explain how the GUI builder works. It only calls constructors of components and gets/sets their properties. It's a standard way of working with JavaBeans. You have ParagraphDisplay GUI form in which you have the ParagraphLayoutPanel component. To show ParagraphDisplay form, the GUI builder must instantiate ParagraphLayoutPanel (as a JavaBean), add it to the form and display. So the constructor gets called, also methods needed by Swing to create the hierarchy and do painting. This does not seem to cause any problems. The GUI builder then expects that the component (as a JavaBean) has some properties - to display the properties in the property sheet. According to JavaBean spec, getting/setting the property values should be possible and order- independent. Now the problem is that your 'get_last_resize' method is considered a property - because it matches the usual patter of a property getter. GUI builder then tries to get the value which causes the hang - because this method is not a property at all (it has some queue behind which gets blocked when empty). The GUI should not consider this method a property and should not call it at all. You have several options to fix it: - Name the method differently, so it does not start with 'get'. - Make the method private. - Write a proper BeanInfo class for your component which enumerates only the valid properties. - Use java.beans.Beans.isDesignTime() method which returns true if the code is running inside GUI builder - do some things differently in such case. This way the method still would be called as a property, but you could avoid the hang. It's more a workaround than solution for this case - but you might find it useful in some other cases when you can't run some code inside GUI builder. Let us know if this help. Closing the issue as invalid again - the GUI builder can't expect a property getter may hang.