How to open the FILE_OPENR conditionally?

I have a program that opens a dropdown box containing a number of items. The program contains the following code:

[color=blue:8ca4812a53] CHARACTER*50 ArrayOfItemDescrps(14) COMMON IFileSel EXTERNAL TopAssyCallbk

  i=winio@('%^`ls&',ArrayOfItemDescrps,14,IFileSel,TopAssyCallbk)

[/color:8ca4812a53]

When the user picks an item from the dropdown box, its number in the box is loaded into IFileSel, and the callback function TopAssyCallbk() is called.

If the user has picked the first item in the dropdown box, I would like the callback function to open the FILE_OPENR dialog box. If the user has picked any other item, the callback function should not open the FILE_OPENR dialog box.

The TopAssyCallbk() function has the following code:

[color=blue:8ca4812a53] COMMON IFileSel

  if(IFileSel.NE.1) goto 99
  i=winio@('%ca[&Select User Parts List]&')
  i=winio@('%mn[&File[&Open]]','FILE_OPENR',BOMFileNm,GetFileFn)
  i=winio@('%mn[[E&xit]]','EXIT')

99 continue [/color:8ca4812a53]

This works after a fashion. But the problem is, when the user picks the first item in the dropdown box, the program first presents a very small dialog box with on one menu item, File; and that menu item has one sub-menu item, Open. If the user then clicks on File, and then on Open, the FILE_OPENR dialog box then opens. That's two extra clicks I'd rather the user didn't have to bother with.

Is there a way I can open the FILE_OPENR dialog box as soon as the user picks the first item in the dropdown box? I'd like to put code something like this, in the callback function TopAssyCallbk():

[color=blue:8ca4812a53] COMMON IFileSel

  if(IFileSel.NE.1) goto 99
  i=Just_Open_The_FILE_OPENR_Dialog_Box_Already

99 continue [/color:8ca4812a53]

In a way, I guess I'd like to call the FILE_OPENR function directly, as an ordinary function instead of a callback function.

Can this be done?

If not, is there any way I can get this program to call the callback function FILE_OPENR conditionally, based on which dropdown box item the user picks, without having to open that tiny box with the File/Open menu item first?

Thanks all!

Rather than open a new menu, you could try a call to get_filtered_file@. This will open a pop-up meny for what may be suitable. Below is a cut-out of my file opening routine.

integer*4 function open_data_func()
!
    use simulation_data
!
    include <clearwin.ins>
    include <JDC_menu.ins>
!
    integer*4 l
    character path*129, file*129, curdir@*129
    integer*4 nfilters
    parameter (nfilters=4)
    character filtname(nfilters)*20, filtspec(nfilters)*20
    external  curdir@, get_filtered_file@, screen_report
!
    data filtname / 'Text files', 'Log files', 'Data files', 'All files' /
    data filtspec / '*.txt',      '*.log',     '*.dat',      '*.*'       /
    data path     / ' ' /
!
! based on example on page 300
!
    call crt_interupt
    if (path.eq.' ') path = curdir@()
!
    file  = ' '
    call get_filtered_file@ ('Open Configuration File', file, &
                             path, filtname, filtspec, nfilters, 1)
!
    l = index (file, '\', .true.)          ! save path
    if (l > 0) then
       path = file(1:l)
    end if
!
!  if file selected then open it and read data
    if (file.ne.' ') then
!
!   Read the new data
!
      data_file_name = file
!
      call read_new_data
!
      call screen_report ('DATA READ COMPLETE')
!
    end if
!
    open_data_func = 1

end function open_data_func

John has given you the answer: get_filtered_file@. This should really be get_filtered_fileNAME@ , and the standard callbacks similarly as you have to OPEN the file with an OPEN statement - which might fail for a variety of reasons - for example, the user does not have the requisite permissions on a network.

One or two other things you may not have thought of are:

1. What happens if the user CANCELs?
2. Is your standard data file in plain text (formatted) or is it machine-readable (unformatted)?

In the latter case, it is often fair to assume that it was generated in the first instance by a previous run of your program, and that it is therefore free from errors. However, if it is in plain text, a user (and this could be you) may be tempted to edit the contents, making it then unreadable properly by your application. In this case, you need to handle the error gracefully. The old FORTRAN STOP isn't much of an option!

Finally, your data file layout may evolve. This can make early-version datafiles unreadable by later-version programs (vice versa is axiomatic), which can be irritating if you do want to open an old data file. I have found it useful to put version information at the start of datafiles for this very reason.

Not answers to your question, but I hope answers to your next question!

Eddie

Thank you, Jon and Eddie, this is working exactly as I want. 😄