Bug 26938 - wizard for importing forms from other ide
wizard for importing forms from other ide
Status: NEW
Product: guibuilder
Classification: Unclassified
Component: Code
3.x
PC Windows ME/2000
: P3 with 10 votes (vote)
: 6.x
Assigned To: issues@guibuilder
issues@guibuilder
sp_review_61
:
: 35647 49563 60421 67950 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-01 13:51 UTC by matteo porta
Modified: 2008-04-28 16:37 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description matteo porta 2002-09-01 13:51:39 UTC
since borland jbuilder and oracle jdeveloper don't use 
special comments for the gui, it is generally possible to 
import into these ides a form designed in netbeans, 
however the reverse isn't possible at all.
please can you add a wizard to import the form from other 
ide so that can be used in netbeans form editor?
thanks.
Comment 1 Tomas Pavek 2004-08-11 09:22:22 UTC
*** Issue 35647 has been marked as a duplicate of this issue. ***
Comment 2 Tomas Pavek 2004-09-29 10:09:13 UTC
*** Issue 49563 has been marked as a duplicate of this issue. ***
Comment 3 Tomas Pavek 2005-05-16 16:12:30 UTC
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.
Comment 4 reedb2005 2005-06-14 14:58:40 UTC
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).
Comment 5 krahe 2005-06-14 18:55:16 UTC
Perhaps the following could be used in some way to accomplish this:

http://contrib.netbeans.org/files/documents/130/271/FormGenerator2.zip
Comment 6 alskor 2005-06-23 10:10:26 UTC
*** Issue 60421 has been marked as a duplicate of this issue. ***
Comment 7 Unknown 2006-01-08 00:18:32 UTC
This issue has also been reported in:
http://swforum.sun.com/jive/thread.jspa?threadID=61275
Comment 8 Jesse Glick 2006-03-03 19:40:05 UTC
*** Issue 67950 has been marked as a duplicate of this issue. ***
Comment 9 _ tboudreau 2008-03-21 02:24:34 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo