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.
| Summary: | wizard for importing forms from other ide | ||
|---|---|---|---|
| Product: | guibuilder | Reporter: | matteo porta <mporta> |
| Component: | Code | Assignee: | issues@guibuilder <issues> |
| Status: | NEW --- | ||
| Severity: | blocker | CC: | mmirilovic, rstrobl |
| Priority: | P3 | ||
| Version: | 3.x | ||
| Hardware: | PC | ||
| OS: | Windows ME/2000 | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
|
Description
matteo porta
2002-09-01 13:51:39 UTC
*** Issue 35647 has been marked as a duplicate of this issue. *** *** Issue 49563 has been marked as a duplicate of this issue. *** We'd like to have such import wizard. Just not decided yet to go and implement it. But this is clearly a highly requested and strategic feature. Related to issue 35849. The absence of any ability to migrate existing source code (GUI forms) to NetBeans is the only reason my software shop has not made the transition to NetBeans. Management simply refuses to support two IDE's and since our codebase is written in JBuilder, that is where we will stay even if NetBeans is a better product for our needs. Please implement this feature - my team wants to use NetBeans!!! (By migrate, I obviously mean that we need to be able to visually edit/update gui forms written in JBuilder and/or other IDE's. Everyone knows that simple code level migration/editing/compilation can be done in any editor including notepad,pico,vi,watever). Perhaps the following could be used in some way to accomplish this: http://contrib.netbeans.org/files/documents/130/271/FormGenerator2.zip *** Issue 60421 has been marked as a duplicate of this issue. *** This issue has also been reported in: http://swforum.sun.com/jive/thread.jspa?threadID=61275 *** Issue 67950 has been marked as a duplicate of this issue. *** FWIW, I recently wrote some analysis code for the Wicket module that examines the closure of a Wicket panel's constructor, finds all the adds and builds a tree of data from that. It's not very hard to do (for inspiration, see the javac package in http://nbwicketsupport.dev.java.net ). The point being, with the javac APIs it wouldn't be very hard to: - Scan for constructors; for each constructor - Visit each method invocation and its closure. For each method invocation - See if it's an invocation of add() or something that calls add() and if the thing it's being called on is a subclass of java.awt.Container (you could borrow my code and change a couple of strings for this). - If yes, add it to the component metadata tree you're building - If no, see if it's a method on a component or subclass. If yes, remember this info to see if it is the setting of a property later Random code that can't be identified in the constructor could either be left there, or converted to pre/post-init blocks. Eventually, generate a new Java source file + form file, use the data gathered tree to populate the form XML file and trigger generating the initComponents() the same way the form editor does when you change something. The hard part for me to try to do this is that AFAIK the form XML format is undocumented. I don't think something like this has to (or can) work in 100% of the cases, but 80-90% would make a lot of people pretty happy - being able to use Matisse with existing UI code is a big deal. |