We Keep Coding

How can I access arraylist from one jframe to another jframe

I am relatively new in Java. In one of my project I have three jframes. They are Menuframe,that has list of menus; LoadDatafromExcelframe, that is use to select and read data from Excel file; and ShowDataFrame, that is use to display data that I read in LoadDatafromExcelframe. Actually its part of a big project. not the whole project! At the beginning of my project I am reading Excel file and load all the data in arraylist. Till this point I am good. Now I want to click the ShowDataFrame from the menulist to display the data that I have read in the LoadDatafromExcelframe. If I can access the arraylist then I think I can move forward. My question is "How can I access arraylist from one jframe (ShowDataFrame) to another frame(LoadDatafromExcelframe)?"I am using Netbeans IDE.
private void jMenuItemShowDataActionPerformed(java.awt.event.ActionEvent evt) {
showDataFrame.setVisible(true);
}

The key issue has little to do with JFrames or Swing in fact, but is simply one of passing information from one object to another. The only way Swing gets involved is if you want to pass this information in response to an event of one sort or another.
The solution is usually one of simply giving your classes appropriate getter and setter methods, of separating out your "model", the logical portion of your program, from your "view", the GUI portion of your program, and of using some sort of listener or observer type interface (such as can be obtained via Swing event listeners) to notify one class when the other is ready to push or pull information.
More general recommendations:
Avoid making anything static that does not need to be static. That is a quick solution that usually causes more pain in the long run as it makes your code very hard to enhance later and to test.
Avoid using lots of JFrames. Most professional GUI's have but one master window, one "JFrame" if you will. Often it is better to swap views in this JFrame such as with a CardLayout or with tabbed panes if needed. Also information that needs to be obtained in another window in a modal fashion can be displayed in a modal dialog.
Get a good book on OOPs basics as it applies to Java programming, such as Bruce Eckel's "Thinking in Java".
And get a good book on use of design patterns with Java such as Head First Design Patterns. These two concepts are key to moving ahead in Java.
Avoid using code generation utilities such as NetBean's form creation utility as it shields you from learning Swing specifics, and hinders your ability to learn to create complex Swing GUI's. Sure, use these tools once your a Swing journeyman, but until then, use the Swing tutorials to learn the library and code by hand.
For more specific advice, you will need to provide more details and provide more code.
Edit 2
More advice based on your post:
In one of my project I have three jframes. They are Menuframe,that has list of menus; LoadDatafromExcelframe, that is use to select and read data from Excel file; and ShowDataFrame, that is use to display data that I read in LoadDatafromExcelframe.
This looks to be better implemented creating 3 JPanels and not 3 JFrames. Then you could display the JPanels as needed in a single JFrame using a CardLayout to help you swap them.
Actually its part of a big project. not the whole project! At the beginning of my project I am reading Excel file and load all the data in arraylist.
This ArrayList should not be "read into a JFrame" but rather the data belongs in a non-GUI class, one of your "model" classes to be exact. Then the view classes, your GUI code can ask the model for this data whenever necessary. Read up on Model-View-Control program design on this site to learn more about this useful pattern.
Till this point I am good. Now I want to click the ShowDataFrame from the menulist to display the data that I have read in the LoadDatafromExcelframe.
Here using MVC structure, one of your "view" classes, the one holding the "menulist" should notify the "control" class that your code needs the ArrayList data held by the "model" class. This could all be done by having the Control class hold references to both "model" and "view" and having the "view" class hold references to the control thus allowing communication between classes.

You can change your ArrayList in static an public in the properties of the object then just call the name of te class who contains de ArrayList and call the ArrayList and use it wherever you want.
Something like this:
JFrame1.ArrayList1.add("some stuff");
Obviously doing this in the JFrame2 class where you want to call the ArrayList

Simple example of using GWT editors with form validation?

I'm looking for a simple example of how to use GWT editor framework for editing a simple form. While there are examples out there, like this, they emit any UI related parts, such as showing how everything fits together, how form validation errors could be displayed, etc.
Lets say I wanted to create a simple form for editing a Person, with textboxes for first name, last name, and email, and validation rules to make sure all fields were filled in, showing errors in case of validation errors. How can this be done with GWT editors?

Not a complete example but have you looked at http://www.gwtproject.org/javadoc/latest/com/google/gwt/editor/ui/client/ValueBoxEditorDecorator.html for showing the error?
I think we found it hard to extends so copy and pasted it, shame and us, and changed for our needs.
It is a nice pattern though, we also encapsulated the HTML for labels, mandatory indicators, help text etc in a similar way.

Handling large number of Swing components

I'm doing a favor for an engineer friend by making him a program that helps him with the scheduling of his factory's production. Each type of product is broken down to a set of steps (they share a lot of them, but there are a few differences).
The programming issue:
Each time a new production process is registered I display a number of checkboxes representing the before mentioned steps. He can choose which steps he needs added for this particular product. If he checks a checkbox, two (or more) textfields appear where he can add additional information (starting date, duration, comments, etc...). My problem is that this is a lot of individual components and I am unsure how to handle them. Since I will need to have access to all of them at some point (the checkboxes to see if that step is needed and all the textfields for the data) I was thinking of having them all as fields, but that doesn't feel right...
Another approach could be to make a container class that groups the textfields together with the checkbox. Something like this:
ArrayList<MyComponentGroup> group;
for (MyComponentGroup cg : group) {
if (cg.getCheckBox().isSelected()) {
//access and read the data from all the textfields in this object
}
}
What is the Java programming convention or the most commonly used method to handle this situation?

Here's what I would do when dealing with tons of components and similar requirements:
I would model the relationship between options (available through checkbox selections) and the related data to fill (requirements). This model may already be available for you.
I would attempt to use PropertyEditor instances and map them to model elements.
When the time comes to save or use the data filled by the user, I would just walk the model represented on the screen, grab the associated editors and deal with the value of those editors.
I think that the approach that I described above will give you less work and potentially and it will bring more flexibility for your friend.
You'd only pay the initial cost of getting the components relationships/dependencies in a nice model as well as registering the relevant PropertyEditors for visual editing.

One approach is to consistently give each JComponent a unique name. Use something hierarchical to fit the complex process, like "Whites.Rinsecycle.enableCB". For completeness, store this String as a clientProperty in the JComponent. Then you can use that as a key in a large Map to access all the components.
Maybe not the most "elegant" (I'd tend to go with a hierarchy of JPanels with relevant fields) but for a slightly quick and dirty, moderate sized project this is reasonable.

Revert (Undo) implementation in GWT

We are trying to build a GUI framework using GWT. We are finding it hard to implement the cancel functionality in the framework.
Required feature is this:
We have CRUD screens which have pop-ups, grids and so on. When the user changes anything in the GUI and then clicks on cancel() he should be given a notification message saying that something has changed.
Approach that we have tried:
Currently we are trying to keep a hashmap of key vs value of the entire pojo object and trying to compare it against the model which gets updated as and when user changes something. But this is adding lot of unwanted code in every pojo and not working as expected when user adds data directly from the backend.
Is there any elegant way in achieving this functionality? Kindly note that *we are not using Editor framework of GWT *(https://developers.google.com/web-toolkit/doc/latest/DevGuideUiEditors) in our application.
Example:
Suppose I have a pojo like this:
public class Person {
List<Address> address;
PhoneNumber phoneData;
// and so on along with getters and setters
}
How will I write a generic clone method for this? And even if I manage to do that somehow that will lead to lot of code in every pojo (our application has hundreds of them) which doesn't seem right.
Please note that, our pojo gets updated as soon as something is changed in GUI to achieve live binding.

So you have "Save" and "Cancel" buttons in your form?
I would recommend you to change the concept. Update your object properties immediately as user edit them (as in GMail, JIRA and many other modern applications) in an OnChange event handler.
Save all updates to the session stack as UpdateAction objects and let the user undo every single property modification calling UpdateAction.undo() method.
The benefits are:
this design is much more user friendly than "Click "Edit" - update - click "Save"" scenario.
You don't need separate view/edit forms/popup dialogs - just a single form for both viewing and editing.

Techniques for customising UI layout

The problem described below relates to an inventory tracking Java program. There are multiple classes of inventory item and it is not possible to determine up front what properties of the intentory class are being tracked. Taking two classes for example:
InventoryClassOne {
String name;
Double price
}
InventoryClassTwo {
StockStatus status;
Long Quantity
}.
Storing the data is no problem, I can just define a
class InventoryProperty<T> {
T value;
}
and a
class InventoryClass {
Map<String, InventoryProperty<?>> inventoryPropertyMap;
}
The UI will be developed using the Wicket framework. I want to provide the administrator of the application with a means of adding new InventoryClasses and defining how the data gets laid out (tabular, list, etc...) on a per InventoryClass basis. Has anyone ever solved this type of problem before? What design patterns are available for achieving this. I don’t even know what words to type into Google in order get ideas for how to solve this.

As much as I love Wicket, I really don't think it is the best option for this kind of meta-website.
But if I absolutely had to do it in Wicket, this is what I'd do:
Create a Fragment for each basic UI widget.
On the admin page you create a mapping from each field of your inventory class to a pre-fab fragment. (You'll have to use reflection to query what fields are available.)
When you're constructing your UI page, you create a repeater (a ListView for example, but even a simple repeater will do) which for each entry in your Field->Fragment mapping adds the fragment with a model pointing at the field.
You might need to tweak it a bit, especially with tables but this is the basic idea.
However, and I have to repeat this, you're practically losing most of the advantages of Wicket, even worse, you'll have to put extra effort in to work your way around (or against) Wicket. It just doesn't seem to be worth it.