On NetBeans 7.0.1, if you are designing two User Interfaces, the "Component Inspector" becomes available while at "Design View", if you switch from one UI to another the Inspector randomly collapses all nodes and you lose focus of the component you had previously selected.
This is annoying because you have to keep expanding the nodes to get focus on what you were working.
One solution is to have multiple NetBeans instances, this may work if you must have two UI opened at the same time, but what if you must have five UIs opened at the same time? 5 NetBeans instances is not an option.
So, do you know what do I have to do so the Component Inspector does not collapse when switching between files? or in another words, how to keep the component inspector state between applications switch?
Thanks for your help!
(Posting this as an answer to show screenshots)
I do not get the same behavior as you do. In my case the Inspector does not collapse the panels when switching between open files, only when closing & opening a file. My IDE looks like the screenshots below when switching between the file tabs (CheckPanel.java & PasswordEditPanel.java).
So the functionality is definitely there, but something is amiss in your case.
Related
Most of time I work with more opened projects at once which results in the overcrowded and fuzzy set of opened cross-projects tabs at once. Suddenly I realize I have found what I need and I want to close all the tabs belonging to a project. Is there a way to comfortably close all the project related opened tabs without closing a project itself?
Example
I have opened two projects A and B. I would like to close all the clases under the B project only, i.e. (B1.java, B2.java ... B5.java).
Why don't you want to close the whole project and open to get rid of these tabs?
I want to keep the project opened to see its structure and opened packages with their content. Although my example above is simple, let's assume I don't want to close the project and walk through a broadly branched tree to find a relevant package agian. The only I need is to close the currently opened tabs of the other project to be used soon or later.
Close them manually, huh?
Eclipse has an amazing feature that the each tab size is different based on the length of the class/file name - the closing of more of tabs at row is still about wasting time of finding the x button. The even more stupid is the expandable list on the right side of tabs which items have no x button at all so I can't close the tabs directly from it.
So, does exist a way?
The simple answer is no, this is not possiable. To close all the tabs you can:
In the file menu(File>>Close All), click the close All item. Eclipse will close all the existing tabs.
This is quite a niche requirement, this could be quite a nice opportunity to build a Ecplise Java Plug-in.
I would suggest using "Tasks" or "Mylyn". When you move from task "A" to task "B", it will replace all the editor tabs for project "A" with the last editor tabs you had open for project "B".
In IntelliJ it seems like whenever I save a file there is this annoying green pop-up notifier at the very bottom that obscures my bottom toolbar, i.e. where terminal, messages, debug usually are.
It's usually "Refreshed selected content roots" which I believe is a gradle thing. There is no obvious way to dismiss it and it just trips me up every time.
As I often make a change and then want to switch to SonarLint or Terminal or whatever and it's blocking the button.
I know obvious workarounds like moving buttons around, but I kind of don't understand what that notifier is even called to configure it or even google it.
As #CrazyCoder would know what he's talking about, I found that the alert is caused by the (hasn't been updated in years with no configurable settings) AccuRev Plugin.
You can search this PDF for "Selected Content Roots" and you'll find it:
https://supportline.microfocus.com/Documentation/books/AccuRev/Plugins/IntelliJ/2014.2/intellij-2014.2-users_guide-en.pdf
This means if I don't plan on moving files around I can logout or disable the plugin then run accurev stat -mO when I'm done. There have been plenty of other reasons to do that, so this just added to the heap.
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!
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 brushing up my Eclipse RCP skill by trying to enhance my one-year-old side RCP application. This application has one perspective, and this perspective has 3 views, and I'm adding another view into the same perspective. To add this new view, I added it in the MANIFEST.MF file under Extensions tab and created the Java file for it.
When I run it as an Application, it works. I see all 4 views in the application. But, when I run it as a Product, that new view is missing. It almost seems like the new view is not registered in the Product. There's no error in the console log either. I think I must be missing a step here, but I can't seem figure out here... pretty frustrating!
Note: The views are added into the perspective programmatically (in Java code), not through MANIFEST.MF file. I just realized that even when I change the existing view's layout (ex: size, or location), it doesn't get reflected when running as a Product either, but it works when running as an Application... sigh!
Note: I commented out all the code in my perspective class, in another word, all the views are removed from the perspective. When I launch the Product, I'm still seeing 3 views in the application. I'm thinking there's something to do with caching, but I'm just bummed now.
Any helps are greatly appreciated here! Thanks much,
Okay, after aimlessly clicking around, I figured out the solution. The workspace data needs to be cleared to pick up changes from the perspective.
To do so...
Right click the product file
Choose "Run Configurations..."
Under "Main" tab, check "Clear" checkbox and "workspace" radio button.
Run it.
Hope this will save some of you from troubles.
I've been bitten by this a couple of times until I figured out the easiest workaround: it's sufficient to reset the perspective. There are two ways to achieve this:
Right-click on your perspective in the perspective selector bar at the top right and click on Reset.
Switch to your perspective and then go to Window | Reset perspective....
After that, the changes to your perspective should be picked up.