Kate, You need to use a data model to set up the combo-list. There are no tags that would support setting up a combo box through XML
Kate Rhodes wrote:
speaking of missing documentation.. I think it would be fairly easy and not too time consuming, but immensely helpful if on each tag page there was an example of that tag with all it's potential attributes. ex. I can't figure out how to add elements to a combo-list in the xml but I'm sure it's possible. an example of each tag would solve this and many other questions without having to write lengthy documentation. -Kate -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Wolf Paulus Sent: Wednesday, March 05, 2003 1:54 PM To: [email protected] Subject: Re: [Forum] Re: swixml .. What is still missing? Frank, While there is nothing wrong with your approach, there was a particular reason why we did it differently. I guess the missing documentation is to blame. However, let me try to explain how we pictures the link between the GUI Widgets and the actual evenbthandlers. All the SwiXml Tags representing Swing objects that inherit from Abstract Button (like JButton, JMenuItem, JCheckBox, etc.) accept the ActionCommand and the Action attribute. When the Action attribute is used, the following will happen with the example for instance: XML Code: .. <button Text="Click" Action="Handle_Click"/> <button id="btn2" Text="2nd Button"/> .. Java Code: .. public class HelloWorld extends WindowAdapter { private SwingEngine swix = new SwingEngine( this ); // *1* public JButton btn2; // *2* public Action Handle_Click= new AbstractAction() { public void actionPerformed(ActionEvent e) { System.out.println( "Click was pressed" ); btn2.setEnable(false); //*3* } } private HelloWorld() { try { swix.render( "xml/HelloWorld.xml" ).setVisible( true ); } catch (Exception e) { e.printStackTrace(); } } public static void main(String[] args) { new HelloWorld(); } } The button Tag triggers the instatiation of a JButton object. Then after the parsing and instantiation work of the whole XML document is done, EventHandlers, (in our case the _public_ Action Handle_Click is linked with the Button. The Button does not need an ID if you don't need to refer to it later. The example has another button (//*2*) that we want to disable if the 1st button was clicked. Therefore this button needs an ID. If there is a _public_ Button in the class of the object that was passed into the SwingEngine at construction time (//*1*) and the button's name matches the tag's then this button gets initialized automatically during parsing as well. If you need to make your members private you will have to use the SwingEngine's find method to init those yourself. Now here comes the benefit of during it this way. Swing programmers are used to use inner classes. The Action class used in this example is an inner class, allowing easy access to the outer class members and methods. See how easy it is to disable the 2nd button in the event handler. When you want to use the alternative (built in) way hook up your event handlers, you need to use the ActionCommand attribute. This requires a little more java code to write but in certain situations this might be preferable over the Action attr. way. Check the sample code at http://www.swixml.org/samples/index.html for details. Wolf Frank Mei�ner wrote:Hello again, Ok, because I needed the features I mentioned, I added them for myself. Now I'm able to write swigxml-code like this: ... <menuitem id="mi_exit" InitClass="test.actions.ExitAction" FactoryMethod="getInstance"/> ... <button enabled="true" InitClass="test.actions.ExitAction" FactoryMethod="getInstance"/> ... All these objects use the same instance of ExitAction. If no ExitAction is used at all, no object of this type is created (of course...). So, this code moves swigxml a bit more to the business-logic part of the code. It allows you to switch some (maybe expensive) parts of your gui on and of. Especially if the components do create without further arguments you do not have to take care on them. Just implement them, test if they work correctly and leave it to someone else to decide if he/she wants to see them. On the original swigxml you have to take care on the creation of the actions for yourself. You have to (correct me if I'm wrong) assign an id to every button or menu item in the xml. Then you have to write code which iterates over all of the id's you defined. If one is used (e.g. the component by getIdMap().get(id) returned a value != null), you have to create the appropriate Action and assign it to the {button, menu item, ...}. Of course, one might use a clever String for the id (like "1.test.actions.ExitAction<getInstance>") but this is not as clever as to provide the factory method :) Just tell me what you think of it... Frank _______________________________________________ Forum mailing list [email protected] http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com_______________________________________________ Forum mailing list [email protected] http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com _______________________________________________ Forum mailing list [email protected] http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com
