"Martin" <ca****@btconnect.com> wrote in message
news:cg**********@titan.btinternet.com...
| Again drawing on the groups experience:-
|
| 1. For general file opening and file saving, using VB6, are there any
issues
| with using the FileOpen and FileSave Common Dialog Boxes?
|
| 2. Is using the FileOpen and FileSave Common Dialog Boxes the best way
to go
| in general?
|
| 3. For Most of my projects I will be using the same types of data
input form
| and report output form, as discussed here recently. Also, the files
that are
| saved or recalled are all of the same type (text files with extension
..job)
| and are, ideally for me, saved in the same directory (App.Path / job).
This
| being the case the FileOpen and FileSave Common Dialog Boxes seem to
be a
| bit of an over kill?
|
| a) When file saving; only the "file name", without extension is
needed. This
| could be supplied more simply on the data input form as the first part
of
| the required data, or is this too crude?
|
| b) When recalling an existing job I could get away with just the
FileListBox
| because I know (or think I know) where the Drive/Directory is. Or is
this
| also too crude.
|
| a) and b) appear very simple to me but don't mimic your conventional
Windows
| style application. I would therefore be most grateful for your advice.
|
|
| Regards
|
| Martin Double
|
| Email:
ca****@btconnect.com
| Web Site:
http://home.btconnect.com/cadoss
|
Having read the J. French sequence, I will pipe up with the other point
of view, just in case it makes sense for your app.
If the app does use files in the conventional way, I think the common
dialog is the way to go. It is not the best interface, but users are
usually used to it. It is useful for things like the standard "file
exists, do you want to replace it" message, letting users change
directory for whatever reason they may dream up; clicking on an existing
file to get the name, then adding an A or a 1 to the end; and so on.
One way to judge whether you use files in the "conventional" way is
whether a Most Recently Used file list in your file menu would make
sense for your app. If so, then I would be looking for file open and
save dialogs. If not, then you may find something else more suitable.
I have one app that works the way you and Jerry are discussing, and it
starts up with a list of projects, with an assortment of data on each
one, for the user to choose from. I also have another that sticks to the
conventional dialog interface, with MRUs, and saving the last project
folder as as setting, etc. So, it really just depends.
One note: it is possible to use the common dialogs through API calls,
instead of the extra OCX, if you do decide to go that way.
