I made a JTabbedPane using Netbeans 7.4. After adding a few things, I decided I didn't want all of the tabs I have created anymore. I then simply compied the JPanel inside of the JTabbedPane onto the same JFrame, and deleted the now unused JTabbedPane. Thing is, all the variables used are still being initialised in source code, even though they do not show up in the Design Navigator or on the JFrame in design mode.
I know I can simply edit this out with a external editor, but I am afraid that the Form data will be corrupted. (This has happened to me before and I lost the ability to edit using Design Mode.)
I used the inspector and FindBugs, but I failed to remove it from there.
"Why am I using Netbeans!?" - A question I won't be asking myself again after I sort this out.
Your first real problem is you are using the Design Mode. Netbeans isn't the problem as is is more than capable of working by itself with code only (I will always only use code).
It is really easy to break a program with a incorrect move within design view.
There isn't really an easy way to go about fixing it, although IMHO sift through the code and find what you need to remove. Make a copy of the .java file first so you have a backup if it breaks!
Related
I am trying to write a plugin for the Universal Gcode Sender (https://winder.github.io/ugs_website/), but when I try to create a JPanel in any directory except my module's main project directory and try to use the Design tab, it just shows the text "Loading..." and I can't do anything in the Design tab. This also happens when I create a new Netbeans Project and try to make a JPanel there.
I don't think this is because of an issue with UGS, rather a Netbeans issue or something.
I literally haven't been able to write any code because the first thing I need to do is make sure I can use the Design tab. Netbeans is entirely stock, I haven't changed anything to cause this.
I have tried multiple re installations of Netbeans and various other solutions. Nothing has worked.
I appreciate any help you can give. If I am missing any important info please tell me and I will supply it.
How can I make it so Eclipse automatically updates my code in a window as I edit it? I've seen the feature before in youtube videos but I cannot find it. For example : I change a JApplet rectangle width from 20 to 10, I want to see it update immediately.
I've seen Notch do this on development videos (Minecraft), it is awesome but I don't know exactly how he does it.
-- EDIT --
This has been bugging me so I went and googled "how does notch code" and found this on a blog page https://gun.io/blog/what-i-learned-from-watching-notch-code/. It doesn't say exactly how it was done but gives a good hint (HotSwap) and makes it seem like he set it up himself without external software. Here's the most relevant section:
Incredibly Fast Testing
He began by building the engine, and to do this he used the ‘HotSwap’ functionality of the Java JVM 1.4.2, which continuously updates the running code when it detects that a class has changed.
When building the engine, Notch wrote a function which would continuously pan the camera around and clip through the walls and keep the view on top, so he could make changes to the code and see the effects they made in real time. I’m used to testing by writing a function, building it, installing it on the device I’m testing on, and then seeing the result, which can take up to a minute at a time, so it’s easy to see how HotSwapping could save a lot of development time.
--- ORIGINAL POST CONTINUED ---
I get a similar effect by using groovysh though, works smoothly and can use all your java classes as is.
What I'll usually do is write all my code in java, then go and fire up "Groovysh" where it will give you a little window to enter commands (You may have to ensure the classpath works correctly outside of eclipse). I can then "new" any of my classes and call methods on them one line at a time. When you do myFrame.setSize([100,100]) you will see it change immediately.
A good test is to just run groovysh and type something like:
import javax.swing.*
f=new JFrame()
f.setVisible(true)
f.setSize(100,100)
or the groovier version:
f=new JFrame(visible:true, size:[100,100])
and you will see your frame resize on the screen. You can even drag it bigger and then do something like:
println f.getWidth()
to show your new width. It's fun to interact this way but it's more complicated if you want to actually change your class definition and see it pick up the change, I have no idea how Notch did that. I looked into it a little--it's possible he was using something like JRebel
It requires something special since you would have to dynamically reload the classfile into your running system on every save--something that should have serious classloader issues.
By the way there is also a way to get your Java program to throw out a little GroovyConsole which will allow you to inspect and modify all the variables in your running code (but again you can't replace definitions of existing classes).
Also see answer here:
Change a method at runtime via a hot swap mechanism
Lately, I've been working on a project in NetBeans using the GUI editor that's built in. Before I noticed that it generated an XML ".form" file that didn't appear in the Project Explorer Pane which makes sense. Earlier I was working on the form in the "Design" tab when it notified me about 15 updates. I just updated without reading anything which was probably a bad idea but when I restarted the IDE, it showed my GUI ".class" file and ".form" file separately in the Project Explorer and I couldn't switch between "Source" and "Design". I also noticed that the generated code that was usually not editable was now editable.
P.S. I'm able to create a new frame just fine and the design editor still works with new frame
I have encounter the same problem and I have solved it.
The key in this problem, I think, is particular plugins for JFrame in Netbeans are not active after updating, so we only need to activate them. The easiest way to achieve this is create a new JFrame class, so in this progress, NetBeans can activate all relevant plugins for us. Finally, restart NetBeans, then everything would be fine.
Thank you very much for all of you that you give me some idea and clues in this situation:)
Work on a similar problem led me to this discussion concerning Guarded blocks inside form Java source file. I'm not sure it's related to your situation, but it may help you recover.
If you are trying to recover the lost state of the backing xml for the form I don't know what to tell you.
This has happened to me, but I tend to highly componentize the forms (break up the forms into little pieces), which makes this not such a big deal. Have you tried the NetBeans forums? You might get better luck there:
http://forums.netbeans.org/
Nevermind, simple solution.
I finally decided that, after plenty of tinkering, to restart the IDE which I should have though of first. The Java SE Plugin must have crashed or something, anyway it's fixed.
Thanks for the help!
Or just right click on the corresponding .form file and select open. The Design tab/editor reestablishes.
I am currently toying with the idea of converting a small/medium sized project from AWT to SWT, although Swing is not totally out of the picture yet.
I was thinking about converting the main window to an SWT_AWT bridge object, but I have no idea how the semantics for this work. After that, I plan to update dialog for dialog, but not necessarily within one release. Is this possible?
Has someone done a conversion like this and can give me some hints? Is there maybe even a tutorial somewhere out there? Is there maybe even a tool that can automate parts of this? I have tried googling, but to no avail.
Update: One additional thing is: Currently, this is a netbeans project. Might be of help or not, I don't know.
We have done this quite a few times. But only because we are going from a Swing application to an Eclipse RCP application not because we like messing with things. This project will really let you know whether you've separated your controller/model code from your view code.
One suggestion is to not try and convert everything all at once. You will end up with a bunch of mixed code that doesn't work at all. You can start at converting portals. I would consider a portal anything within a Tab, Dialog, or Window, essentially self contained unit. If you have a window that opens up, create the Window in SWT, but make it's contents the existing AWT/Swing. This should be fairly straight forward and allow you to get used to the (I really hope they weren't drunk and had a good reason for this) way of instantiating and associating parent/child controls.
One gotcha that can occur is with transparent components. Swing, with the exception of a "window" class is all rendered in Java. This makes it very easy to render things the way you want them. In SWT, there are some restrictions:
Borders. If you use SWT.BORDER you are stuck with whatever color the native component uses. Your best bet is to use a PaintListener and render your own borders if you want them in a different style or color.
Transparent labels, progress bars. I have not been able to get Labels or Progress Bars to have a transparent background. If you want them to take on the parent color, or drawing you will need to render the text and other controls yourself.
Controls. There are composites and controls in SWT. Think of Controls as the basic native controls that do all the native API calls. These cannot be subclassed, which makes things difficult.
Tables will give you the most trouble. Make sure everything is stable before you attempt to convert a JTable to a Table or TableViewer. You will spend some time on these, especially if you have custom editors and viewers.
I have not researched why SWT was designed the way it was. I am guessing there HAD to be a good reason. It would be great if someone had a blog or defense to it's design so I don't have to search for it. Once it's posted I'll remove these lines since they have no relevance to the question.
Addition
I want to add that since you have an existing product I assume works. The best piece of advice I can give you is to never let your code get into a state that it cannot compile and run. If you work on your conversion and whatever you check in always runs and executes (despite the visual differences between SWT/AWT/Swing) you will save yourself many headaches in the long run. The worst thing you can do is try to tackle this all at once and get your code in an unstable state for weeks at a time.
I would suggest importing it into a WindowBuilder project, as WindowBuilder gives you the ability to parse existing code and create a GUI mock-up, then morph components to either SWT or Swing.
If you're thinking of using a mix of SWT and Swing in the same application, this Eclipse Corner Article will be immensely useful.
We are preparing the same step: Swing to SWT/JFace. First we try to determine the bottlenecks: reimplement special components derived from JComponent with SWT/JFace, search for a replacement of JIDE docking (we want to use SWT/JFace, not RCP to avoid too much hassle). The worst thing we already imagine is, that in Swing you could create components and adding it later to the parent. With SWT this is not possible: the parent component must be passed as a reference to the child component's constructor. This will require major refactoring in the Swing application before using SWT.
Frankly, we rate the conversion a very heavy change, because we expect the time where nothing can be compiled as quite long. We try to decrease this time by preparing everything as good as possible, but we'll see how good it will work.
Update from April 6th 2011:
We now refactored our Swing application to always create components with their parent (as in SWT). Our subclasses of JFrame and JDialog got refactored to just have a JDialog instance to make it easier to switch to SWT's Shell. In parallel, we rewrite sophisticated components in SWT.
I'm trying to build a small application using Java and SWT for the GUI. I'm looking for a way to store in some file the preferences set by the user, I mean, if the window was resized then that new size should be saved for next time the application starts. The same thing with some controls like textbox and so on.
I came up with two ideas to solve this:
Use the classic hand-made .ini files to store those preferences. But it appears to be ugly and hard to maintain.
Serialization/Deserialization of the whole class that contains the GUI. Dunno if this is even possible.
Any ideas? What should I do?
Thanks in advance.
Added:
I'm not doing an Eclipse RCP project, it's just a normal SWT application.
More:
I've already tried with serialization, but SWT widgets doesn't support it, so the only other option that I've found is create another class, say Configuration, mark it as serializable and hold there the values of my widgets. Almost like using java.util.prefs.Preferences, but not as simple.
I'm still waiting to see if there is another way to do this, maybe with some binding involved.
Have a look at Memento design pattern.
Eclipse RCP already reuses this principle, you can refer to the following interface for more information:
org.eclipse.ui.IMemento