> [weird] behavior when I tried to open a new project > What does the NetBeans FileChooser different than the default Java one?
The "Open Project" file chooser contains special logic to recognize NetBeans project folders as such, so that they can be displayed with a proper icon, and so that double-clicking said folders will open the project rather than descend into the folder. There's also a "Project Name" and "Open Required Projects" pane added to the file chooser. > Am I the only one with this problem? I managed to reproduce it on my Windows 10 machine. As you say, I had to use the latest OpenJDK 11.0.1 (from https://jdk.java.net/11/ ), and I had to create an intentionally broken shortcut (to a file or a folder--doesn't matter) on my desktop. Please feel free to add a JIRA issue for this (under the NETBEANS project at https://issues.apache.org ). To investigate a bug like this, first find the NetBeans module that implements the custom file chooser. The easiest way is to search for a UI string that occurs in said file chooser; I'd go for "Open Required Projects". Though if you look carefully, you'll see there's a mnemonic underline under the "R", so you'd have to search for a UI string matching "Open &Required Projects" in this case (there's a convention where an '&' symbol before a character in a UI string becomes that component's keyboard mnemonic character on WIndows). So I do: git grep 'Open &Required Projects' which gives me ide/projectui/src/org/netbeans/modules/project/ui/Bundle.properties:LBL_PrjChooser_Subprojects_CheckBox=Open &Required Projects\: So the module to investigate in is ide/projectui. If you do "ant" once in the incubator-netbeans folder, you'll build the entire IDE, after which you can run the freshly built IDE using "ant tryme". Subsequently, if you make changes in the ide/projectui module for testing purposes, it's sufficient to just run "ant" in that folder again to save time; "ant tryme" from the incubator-netbeans root will then use the updated code. I'd start by inserting print statements to try to localize the code that causes the dialog to pop up. -- Eirik -----Original Message----- From: Jens Hofschröer <[email protected]> Sent: Wednesday, October 17, 2018 8:48 AM To: [email protected] Subject: different FileChooser behavior with JDK 11.0.1 on Windows than with 11.0.0 Hi I wanted to test the current JDK 11.0.1 in our RCP application and found a wired behavior when I tried to open a new project. I got spammed with error messages that various (Windows-)links on my Desktop are no longer valid and if I want to remove them. These messages are OS-messages and occur normally when you try to open an file or application via a .lnk file and the destination does no longer exist. A valid message for an invalid file. But these messages only occur if you actively click on these abandoned shortcuts, never when you just view them in a directory listing. /!\ This behavior is specific to the NetBeans FileChooser and the 11.0.1 release. There is no regression in plain Swing applications and the default JFileChooser. There were no regressions with the JDK11+23 build of OpenJDK. I tried OpenJDK and OracleJDK since Azul and AdoptJDK do not provide a recent build. Java: 11.0.1; OpenJDK 64-Bit Server VM 11.0.1+13 Java: 11.0.1; Java HotSpot(TM) 64-Bit Server VM 11.0.1+13-LTS Also this is not specific to NB10. I tried NB8.2, NB9 and NB10 together with our RCP based on NB8.2 and NB9 System: Windows 7 Version 6.1 läuft auf amd64; Cp1252; de_DE I don't know where to start digging the problem. What does the NetBeans FileChooser different than the default Java one? What change was done to Java? I could not find a hint on this. Am I the only one with this problem? Greetings Jens -- http://blog.nigjo.de/netbeans/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
