Author Topic: New FileOpener interface  (Read 12337 times)

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
New FileOpener interface
« on: February 12, 2009, 04:48:10 PM »
Using the FixedDialog.java example, I've got this somewhat working in my application.  But I have one problem and one question:

- I've got three JButtons at the bottom of a JOptionPane dialog, where the first button is a FileOpener and the other two buttons are not.  In the rendered HTML, the second button also seems to want to act as a FileOpener.  Actually, about the first 2/3 of the second button acts as a FileOpener when clicked, and the last 1/3 acts as it should.  I noticed use of setBounds() in the FixedDialog example.  Do I need to use this?

- What types of JComponents are supported as file openers?  Can I use a JTreeMenuItem in ComponentUtils.setFileOpener()?

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: New FileOpener interface
« Reply #1 on: February 12, 2009, 05:24:57 PM »
Can you attach generated HTML for the FileOpener button? Most likely hidden file upload field overlaps other buttons in the generated HTML.

Only JButton renderer currently supports FileOpener. In theory it should be possible to add support for FileOpener to other UI elements but it needs to be tested. As we were explaining previously, FileOpener implementation tricks the browser by placing hidden upload field, so every component would have to be tested to make sure it works correctly.

What other components do you need to support FileOpener? If you already have a custom renderer for tree items, you can do the same trick that DefaultJComponentRenderer is using for JButton.

Code: [Select]
        if (ComponentUtils.getFileOpener(comp) != null) {
            // Delegate to upload renderer for file uploads
            TraceMgr.trace("Rendering component with file upload renderer", 6);
            ComponentRenderer fileUploadRenderer = page.getPageRenderer().getComponentRenderer("com.creamtec.ajaxswing.rendering.html.AbstractButtonFileUploadSupport");
            fileUploadRenderer.renderComponent(page, comp);
        }

You can see the button template in AjaxSwing/conf/templates, but for other components it would have to be different.
« Last Edit: February 12, 2009, 05:27:28 PM by CreamTec Support Team »

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: New FileOpener interface
« Reply #2 on: February 13, 2009, 10:03:33 AM »
I've attached the generated HTML plus a screen shot.  [Local File] is the file opener, but clicking the left side of [Deployment URL] also initiates the file opener.  In the HTML, the file opener is in the window at the bottom - look for JButton_24489190.

I'd also like to set a file opener on a JMenuItem.  I can probably create a custom renderer, but I wouldn't know how to create the default-component html file.

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: New FileOpener interface
« Reply #3 on: February 13, 2009, 10:59:35 AM »
We fixed the problem with overextended upload button at the product level. Thanks for reporting this.

We'll see how hard would it be to add FileOpener support for JMenuItem and post more information later.

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: New FileOpener interface
« Reply #4 on: February 18, 2009, 11:17:31 AM »
Any more information on this?  If it's going to be a while, could I get the fix in a patch?  If possible, I need both the JRE 1.4 and 1.5 jars.

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: New FileOpener interface
« Reply #5 on: February 18, 2009, 11:35:10 AM »
We've added FileOpener support for JMenuItem. This is being tested right now and we expect Beta2 to be released tomorrow. Alex will send you a note when it's ready.

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: New FileOpener interface
« Reply #6 on: February 18, 2009, 12:10:08 PM »
Great, thanks.

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: New FileOpener interface
« Reply #7 on: February 20, 2009, 09:56:43 AM »
Beta2, which contains the FileOpener support for JMenuItem, was released yesterday. Please download it and let us know if it meets your needs.

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: New FileOpener interface
« Reply #8 on: February 20, 2009, 12:13:07 PM »
I downloaded beta2, and am getting the following exception when I try to start a browser session:

2009/02/20 10:13:27 Exception: "java.lang.NoSuchMethodError: sun.font.FontManager.maybeUsingAlternateCompositeFonts()Z
        at java.awt.Component.getFontMetrics(Component.java:2501)
        at javax.swing.JComponent.getFontMetrics(Unknown Source)
        at javax.swing.plaf.basic.BasicLabelUI.getPreferredSize(Unknown Source)
        at javax.swing.JComponent.getPreferredSize(Unknown Source)
        at javax.swing.plaf.basic.BasicComboBoxRenderer.getPreferredSize(Unknown Source)
        at javax.swing.plaf.basic.BasicListUI.updateLayoutState(Unknown Source)
        at javax.swing.plaf.basic.BasicListUI.maybeUpdateLayoutState(Unknown Source)
        at javax.swing.plaf.basic.BasicListUI$Handler.valueChanged(Unknown Source)
        at javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown Source)
        at javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown Source)
        at javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown Source)
        at javax.swing.DefaultListSelectionModel.changeSelection(Unknown Source)
        at javax.swing.DefaultListSelectionModel.changeSelection(Unknown Source)
        at javax.swing.DefaultListSelectionModel.setSelectionInterval(Unknown Source)
        at javax.swing.JList.setSelectedIndex(Unknown Source)
        at javax.swing.plaf.basic.BasicComboPopup.setListSelection(Unknown Source)
        at javax.swing.plaf.basic.BasicComboPopup.access$300(Unknown Source)
        at javax.swing.plaf.basic.BasicComboPopup$Handler.itemStateChanged(Unknown Source)
        at javax.swing.JComboBox.fireItemStateChanged(Unknown Source)
        at javax.swing.JComboBox.selectedItemChanged(Unknown Source)
        at javax.swing.JComboBox.contentsChanged(Unknown Source)
        at javax.swing.AbstractListModel.fireContentsChanged(Unknown Source)
        at javax.swing.DefaultComboBoxModel.setSelectedItem(Unknown Source)
        at javax.swing.DefaultComboBoxModel.addElement(Unknown Source)
        at oracle.help.DefaultNavigatorPanel$TabPanelChoiceModel.addNavigatorTabPanel(Unknown Source)
        at oracle.help.DefaultNavigatorPanel.addNavigatorTabPanel(Unknown Source)
        at oracle.help.Help._createNavigatorsForBook(Unknown Source)
        at oracle.help.Help.addBook(Unknown Source)
        at com.cleo.lexicom.help.LexHelp.createHelp(LexHelp.java:84)
        at com.cleo.lexicom.help.LexHelp.<init>(LexHelp.java:42)
        at com.cleo.lexicom.help.LexHelp.getHelpStr(LexHelp.java:134)
        at com.cleo.lexicom.help.ContextHelpButton.<init>(ContextHelpButton.java:37)
        at com.cleo.lexicom.PasswordDialog.<init>(PasswordDialog.java:88)
        at com.cleo.lexicom.LexiCom.webGUIpassword(LexiCom.java:1815)
        at com.cleo.lexicom.LexiCom.init(LexiCom.java:631)
        at com.cleo.lexicom.LexiCom.<init>(LexiCom.java:178)
        at com.cleo.lexicom.VLTrader.main(VLTrader.java:84)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at com.creamtec.ajaxswing.core.ClientAgent.loadAndRun(ClientAgent.java:616)
        at com.creamtec.ajaxswing.core.ClientAgent.doRun(ClientAgent.java:574)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at com.creamtec.ajaxswing.core.AjaxSwingThread.doVoidMethodVoid(AjaxSwingThread.java:152)
        at com.creamtec.ajaxswing.core.AjaxSwingThread.run(AjaxSwingThread.java:46)

Any idea what might be causing this.  Our code hasn't changed in this area - in fact, this looks to be stemming from the Oracle Help for Java library we use.

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: New FileOpener interface
« Reply #9 on: February 20, 2009, 01:02:41 PM »
I'm sure this is caused by us upgrading to the latest versions of JDK 1.5 and 1.6 (jdk1.5.0_17 and jdk1.6.0_12). Would it be possible for you to also upgrade?

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: New FileOpener interface
« Reply #10 on: February 20, 2009, 03:16:02 PM »
Okay, I'm using 1.5.0_17 now, and it did resolve the error.

This is 100% better than w/o this new interface, but I do have some feedback:

- On MSIE (not on Firefox), the entire page clears and redraws after a file is selected.
- On Firefox (not on MSIE), the pointer changes to just an I cursor when over the FileOpener button or menu item.
- On both MSIE and Firefox, the browser's file chooser dialog defaults to the extreme upper-left corner.  Would it be possible to center the dialog or at least offset from the corner some amount?

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: New FileOpener interface
« Reply #11 on: February 20, 2009, 03:21:29 PM »
Oh, I forgot one last remark:

- It would be great if the FileOpener interface had a second method that's called when the browser's file chooser dialog is first shown (or at least when it is closed w/o selecting a file), so can hide a pulldown menu or dispose a dialog if appropriate.

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: New FileOpener interface
« Reply #12 on: February 20, 2009, 04:19:49 PM »
> - On MSIE (not on Firefox), the entire page clears and redraws after a file is selected.

This is IE issue that is not likely to have resolution. File upload requires full page submission and unlike Firefox IE seems to clear the page before redrawing it.

> - On Firefox (not on MSIE), the pointer changes to just an I cursor when over the FileOpener button or menu item.

This is Firefox issue that's not likely to be have a resolution either. As you know, this file upload is a big browser hack. What is happening is there is actually an 100% transparent file input displayed over the menu item (or button). When the user clicks the menu item he actually clicks that file input. The file input is not stylable, so Firefox ignores CSS for the cursor.

> - On both MSIE and Firefox, the browser's file chooser dialog defaults to the extreme upper-left corner. 
> Would it be possible to center the dialog or at least offset from the corner some amount?

Same as above - there is no programmatic control of where the dialog is diplayed or how it's hidden. It's all done by the browser. It probably doesn't display the dialog over the menu item because the transparent file input is actually very large. It needs to be large to accommodate any menu item size.

So unfortunately what you see is about as good as it can get. You are welcome to try other way to improve it but what we have is already pushing the limits of browser. Maybe with more time spent things can be improved further, but it's trial an error and no guarantees.


aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: New FileOpener interface
« Reply #13 on: February 23, 2009, 06:08:09 PM »
Okay, I understand.  We're happy with the improvements.  Thank you.

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: New FileOpener interface
« Reply #14 on: May 08, 2009, 12:33:47 PM »
A new issue has cropped up for us with the FileOpener interface.  We're setting FileOpener on a JButton, and while the file opener logic works, we have an HTML rendering problem.  Much extra whitespace is being added on the rightside of the panel containing the JButton.  I've attached two screen shots showing this; the FileOpener button is [Import...].

When we don't set FileOpener on the JButton, this renderering problem disappears.  Unfortunately, this isn't an option for us as this is on our main page and the browseClient property has to be false for other JFileChooser buttons that need to browse the server rather than the client.