I implemented DnD between 2 JTables in my java applet.
It works fine: when I drag a line from one table to another (or from a table to itself - reordering), it copies to the destination and removed from the origin.
The problem is when I drag a line outside the java window. The cursor shows like a circle showing that this drag is illegal, exportData() is called anyway, and I don't know how to identify whether the DnD was legal or not?
This is important because only if it was legal, I would want to remove the line from the origin JTable...
I guess, you are talking about the TransferHandler class. Then, exportData does only the preparation of the transfer; exportDone is the method to override and implement the removal for the case action==MOVE. By the way, the API documentation for both methods clearly describes this.
Related
I'm working on my custom ColorChooserPanel class, but I don't know how to create a ColorSwatch.
I found a class named ColorSwatch or something like that but its package private and I can't access it.
How can I ensure that I have a proper color chooser?
First, you need to think about the way this should work, to formulate your goals into action points that you can always check and see whether and how they are fulfilled:
it should be displayed
it should handle click events
it should be able to return a color (the last chosen color, or a default in lack of that)
Now, a very common way of supporting color choosers is to have something like in this image:
However, this is way too complex for a first implementation. You should first have something which "works", that is, you are able to choose colors to taste success and then work out the subsequent details. Unless you say otherwise, I'm assuming that the Basic colors section is good for now. In that case, you can create a class, which contains a JPanel, containing clickable elements. Your class needs to have a Color member, which one can get calling a getter and which is set when a clickable item inside your JPanel is clicked. The clickable items can be JPanels on their own, for example.
If you prefer something ready-made, then kindly read these:
https://docs.oracle.com/javase/tutorial/uiswing/components/colorchooser.html
https://coderanch.com/t/332515/java/Color-Palette
I find it useful to have fields colored in different way than local variables so that I find it easier to visually read the code flow.
In the same way, I would like to color method calls acting on the current instance, so that they look different from method calls acting on other instances (regardless of their type). This should affect interface methods, inherited methods, abstract methods...
These methods are most of the time self-documenting code, or duplicated code that was refactored but not deemed worthy enough of having another class handle the common logic. Therefore I find it useful to visually see I'm not leaving the responsibility of this class.
How can I achieve this in IntelliJ Idea?
I am writing this question because I have found a similar question related to Android Studio while looking for an answer to this, but when I tried to google/search the question days later it was absolutely painful as it did not come up anywhere in the search results, I did not remember how I found it in the first place. I'm writing this question in the hopes it will be useful to any future reader having the same question.
There's a way, but it's a workaround, it will have side effects.
How:
Go to File > Settings > Inspections (Choose the Global Profile if necessary).
Type in the search: qualified.
Tick the checkbox next to "Instance method call not qualified with 'this'".
Click on Severity > Edit severities, add new entry by clicking the green + button.
Name it whatever you want.
You must put it at the bottom of the list using the arrows. If you don't, the F2 key will no longer work as you expect it as it will prioritize errors at the top of the list.
Set the Error stripe mark to #FFFFFF, or the same color as the scrollbar.
Set it bold if you wish.
If you want to set a color, you must set a background color to white (or black if you have a black interface). If you don't, the color will appear black in most conditions.
If you really want to, do the same for "Unnecessary 'this' qualifier"; there is an additional checkbox to make it only apply to methods and not fields.
Side effects:
This enables inspections, which is not desired.
Pointing the mouse cursor onto the method calls will cause a hover text to appear describing the inspection.
If your code has no errors, no warnings, and no additional informative inspections, pressing F2 will jump through these calls.
I am making a knight's tour implementation in java, and currently I have everything jumbled into one giant mess of code.
I have a class called MainFrame which includes the code to solve the knights tour as well as methods for the menu, etc.
I want to create a new class called KT (for knights tour) which will contain the code for the algorithm, but I'm having lots of issues doing that.
I don't want to post code here because i dont want someone from my class copying or something, so I will just briefly explain.
In class KT, I have declared the variables, arrays, etc. I have methods such as printSolution, move, redo (the backtracking), etc.
However I am unsure how to tie in the code for the buttons (which is declared in MainFrame). For example, I have a loop in the print method that prints the correct solution on the 8x8 board. Right now I'm being asked to create a new method for the button even though I have the button in class MainFrame.
I have a KT k = new KT(); and then I'm launching MainFrame. Is that where I am doing it wrong or is it something really simple that I'm being too dumb to figure out?
tl;dr program works well when i have everything in one class, but i want to make two classes and make everything "look" nice
First of all, give your KnightTour class an actual name. Like, you know, KnightTour. If you were coding this for cash money, the next guy who had to read your code would want to punch the guy who called a class something like KT.
Think about creating this class so that you can use it from a GUI controller like your button and menu laden applet. But so that it can ALSO be used from, say, a character based application where you type commands at a prompt and have your new class evaluate those commands.
The reason I suggest this is because it will force you to create your KnightTour class so that it is PURELY the "business logic" for your app. By that I mean that your KnightTour class should not know anything about buttons, menus, GUIs, text interfaces, or anything like that. You need to think about your KnightTour class in terms of what it must accomplish.
I don't really know what KnightTour does. So I'll just throw out some ideas of what kind of functionality it might need to support. I'm assuming everything takes place on a chess board?
Get the state (occupied, unoccupied) for a given board location (x,y)
Put a chess piece (piece enumerator) on a given location (x,y)
Validate placement of a piece (piece enumerator, location x,y)
Suggest a move, returning a Suggestion object with a piece enumerator and location
Reset the board to start all over.
Now, when you push a button that says "place a piece on 5,5" then you'll handle that event in your GUI controller, and then call the "set piece" method (#2 above) to do that work. If you have a character based application, when you type "put knight at 5,5" then you'll parse that text, and then invoke #2 above. The key point is that both of those user interfaces access the same KnightTour methods to do the same work.
In the actionPerformed method of your MainFrame class just call the appropriate methods to get the solution from KT (which, by the way, I would rename to KnightsTour...readability counts).
Ideally you want all your logic (the model) broken up into sensible methods in KnightsTour, and all your display and button-handling code (the view and controller) in MainFrame. If that's difficult, it's a good sign that you need to rethink how you divided things into methods (and what you're doing with global state...which is frowned upon).
I'm sorry I can't be more specific--I'm kind of hand-tied since you didn't post code.
I need to create a drag and drop system in swing where an image of the thing being dragged is attached to the cursor during the drag. In theory this is achieveable with
public Icon TransferHandler.getVisualRepresentation(Transferable t)
but there appears to be a long standing bug (here) that means this method is never called. I know I can do it by implementing my own DnD system with DragSource etc., but does anyone know of an easier workround that will get me what I need?
The method TransferHandler.getVisualRepresentation wasn't supported in java 1.4, I'm not sure if or when it was fixed. To test whether it works in a current version you could adapt this example
In the end I used the old style drag-and-drop to implement what I wanted. However I have no reason to think abrightwell's solution wouldn't work just as well - this was just the best way at the time.
You could Try putting the image on a Jlabel (in the draggesture recognizer)and set its bounds, in the droptargetListener dragover method. Alternately, hows about implementing a Mouse listener (I've not tested this latter method).
I have used the "work around" suggested towards the bottom of the bug report you have listed. It worked well enough for me. Granted I was using this with Mac OS X so I have no idea whether Winderz will support it. It would be nice if they would at least fix it to work like they intended and simply document where it will and won't work... oh well. Good Luck.
Here's a very specific coding question:
I've recently been asked to maintain some old-ish Java Swing GUI code at work and ran into this problem:
I've attached my own subclass of InputVerifier called MyFilenameVerifier to a JTextField (but it may as well be any JComponent for these purposes). I've overridden the verify() method such that it calls super.verify(input) (where input is the JComponent parameter to verify()). If super.verify(input) comes back false, I do:
input.setBorder(BorderFactory.createLineBorder(Color.RED));
This is a convention used throughout the UI of this application that started long before me, so I don't have a lot of choice as far as using other ways to get the users attention (wish I did). This is just the way it works.
Problem is, once the user goes back and types something valid into the text field, I need a way to set it back to default border (instead of just saying set it to Color.GRAY or whatever, which is a different color from its original border). I need a way to say, "remove the extra decoration and go back to normal" or just set the border to its default, in other words.
Couldn't you just call input.getBorder() and cache it somewhere before setting the border to red?
Or without caching anything, you could tell the JComponent to update its UI back to the look and feel's defaults via component.updateUI. That should make the component reset its colors, borders, fonts, etc to match the original settings.
input.getBorder()
Wouldn't it be awesome if no one ever saw this and I got away free without the ass-beating I deserve for asking this question?
Not sure how your system is build, but I think you can store the original border before changing it. So you can change it back later
// assuming the Border was not null before
if (!super.verify(input)) {
original = input.getBorder();
input.setBorder(...);
} else {
if (original != null) {
input.setBorder(original);
original = null; // not needed
}
}
You need to preserve the existing border when you change it.
One way to do this is to use the methods putClientProperty() and getClientProperty(), which you'll find documented in the API.
Another possibility, if there are only a few input widgets you need this for is to subclass, e.g. JTextField, add setBorderOverride() and modify getBorder() to return "overriddingBorder" if it is not null.
Then you just use setBorderOverride(redBorder) to make it red and setBorderOverride(null) to clear it.
This of course depends on the painting to use getBorder(), which it may or may not do, and which may be implementation specific.
Incidentally, you only need a single static reference to the border-- it's the selfsame border instance used by all JTextFields.