addDirectoryField and addFileField methods

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

addDirectoryField and addFileField methods

CARL Philippe (LBP)
Dear all (probably Wayne),
The version 1.53d11 has seen the addition of the addDirectoryField and addFileField methods within the GenericDialog class which are in the form of:
        public void addDirectoryField(String label, String defaultPath)
and
        public void addFileField(String label, String defaultPath)
These methods will create a stringField with a linked "Browse" button for locating the given folder or file which can indeed be very useful (which explains why I'm actually already trying to use them!).
But could it be considered to additionally have the following methods:
        public void addDirectoryField(String label, String defaultPath, int columns)
and
        public void addFileField(String label, String defaultPath, int columns)
Which would additionally able to define the stringField size given that now it is only defined by the String_defaultPath length?
But given that I can define my stringFields the following way:
        gd.addDirectoryField("Data_folder" , "undefined_text_of_a_given_length_to_be_replaced_later_on     ");
        gd.addFileField ("File" , "undefined_text_of_a_given_length_to_be_replaced_later_on      ");
and later on get a handle of these stringFields and reinitialize their content with the following code:
                TextFields = gd.getStringFields ();
                tfFolder   = (TextField) (TextFields.elementAt(0));
                tfFile1    = (TextField) (TextFields.elementAt(1));
                tfFolder   .setText (folder);
                tfFile1    .setText (file1);
I can live with this.
Nevertheless, an issue I can see within these methods is the fact the the name "Browse" is defined within the method which could be problematic the the case of plugins made for non english speakers.
And thus more general methods like:
        public void addDirectoryField(String label, String defaultPath, int columns, String browseButtonName)
and
        public void addFileField(String label, String defaultPath, int columns, String browseButtonName)
could be thus be useful.
At last but not at least, I would expect the "Browse" button of the addDirectoryField to open the "choose directory" dialog within the path defined within the StringField (if it exists) and not the last opened path.
I thank you very much in advance for your answers on this.
My best regards,
Philippe

Philippe CARL
Laboratoire de Bioimagerie et Pathologies
UMR 7021 CNRS - Université de Strasbourg
Faculté de Pharmacie
74 route du Rhin
67401 ILLKIRCH
Tel : +33(0)3 68 85 42 89

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: addDirectoryField and addFileField methods

Wayne Rasband-2
> On Jul 26, 2020, at 12:59 PM, CARL Philippe (LBP) <[hidden email]> wrote:
>
> Dear all (probably Wayne),
> The version 1.53d11 has seen the addition of the addDirectoryField and addFileField methods within the GenericDialog class which are in the form of:
> public void addDirectoryField(String label, String defaultPath)
> and
> public void addFileField(String label, String defaultPath)
> These methods will create a stringField with a linked "Browse" button for locating the given folder or file which can indeed be very useful (which explains why I'm actually already trying to use them!).

The 1.53d47 daily build adds

   addDirectoryField(String label, String defaultPath, int columns)

and

  addFileField(String label, String defaultPath, int columns)

methods. It also adds drag and drop support to GenericDialog directory and file text fields.

The GenericDialogs in the FIle>Import>Image Sequence, File>Save As>Image Sequence, ROI Manager>More>Multi Crop and File>Import>AVI commands use directory and file fields. These dialogs remember the last opened path, not addDirectoryField() and addFileField().

-wayne


> But could it be considered to additionally have the following methods:
> public void addDirectoryField(String label, String defaultPath, int columns)
> and
> public void addFileField(String label, String defaultPath, int columns)
> Which would additionally able to define the stringField size given that now it is only defined by the String_defaultPath length?
> But given that I can define my stringFields the following way:
> gd.addDirectoryField("Data_folder" , "undefined_text_of_a_given_length_to_be_replaced_later_on     ");
> gd.addFileField ("File" , "undefined_text_of_a_given_length_to_be_replaced_later_on      ");
> and later on get a handle of these stringFields and reinitialize their content with the following code:
> TextFields = gd.getStringFields ();
> tfFolder   = (TextField) (TextFields.elementAt(0));
> tfFile1    = (TextField) (TextFields.elementAt(1));
> tfFolder   .setText (folder);
> tfFile1    .setText (file1);
> I can live with this.
> Nevertheless, an issue I can see within these methods is the fact the the name "Browse" is defined within the method which could be problematic the the case of plugins made for non english speakers.
> And thus more general methods like:
> public void addDirectoryField(String label, String defaultPath, int columns, String browseButtonName)
> and
> public void addFileField(String label, String defaultPath, int columns, String browseButtonName)
> could be thus be useful.
> At last but not at least, I would expect the "Browse" button of the addDirectoryField to open the "choose directory" dialog within the path defined within the StringField (if it exists) and not the last opened path.
> I thank you very much in advance for your answers on this.
> My best regards,
> Philippe

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html