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: EMAIL REMOVED
Web Site: http://home.btconnect.com/cadoss

On Tue, 24 Aug 2004 08:40:58 +0000 (UTC), "Martin"
<EMAIL REMOVED> wrote:

>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.

Following through your reasoning, it sounds to me as if you have every
case for designing your own Save and Load 'Dialogs'

From what you say, you are not really writing a 'traditional' Windows
style 'file editor'
- you are writing a storage mechanism for 'Jobs'

If you avoid referring to the 'jobs' as Files, then the users need not
even be aware that you are actually storing files.

Personally I would not use a FileListbox, better read the file names
yourself and have your own Listbox
- that way you can sort by Name or by Date, search by part of the name
and generally provide a really neat interface.

You could also keep a little header in each file that stores
interesting things like: Job Opened by, on etc

"J French" <EMAIL REMOVED> wrote in message
news:EMAIL REMOVED...
> On Tue, 24 Aug 2004 08:40:58 +0000 (UTC), "Martin"
> <EMAIL REMOVED> wrote:
>
> >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.
>
> Following through your reasoning, it sounds to me as if you have every
> case for designing your own Save and Load 'Dialogs'
>
> From what you say, you are not really writing a 'traditional' Windows
> style 'file editor'
> - you are writing a storage mechanism for 'Jobs'
>
> If you avoid referring to the 'jobs' as Files, then the users need not
> even be aware that you are actually storing files.
>
> Personally I would not use a FileListbox, better read the file names
> yourself and have your own Listbox
> - that way you can sort by Name or by Date, search by part of the name
> and generally provide a really neat interface.
>
> You could also keep a little header in each file that stores
> interesting things like: Job Opened by, on etc

Some very interesting and useful points there, many thanks.

Regards

Martin Double

Email: EMAIL REMOVED
Web Site: http://home.btconnect.com/cadoss

On Tue, 24 Aug 2004 11:18:40 +0000 (UTC), "Martin"
<EMAIL REMOVED> wrote:

<snip>

>Some very interesting and useful points there, many thanks.
>
>Regards
>
>Martin Double

I can see why you were concerned

However, AFAIK you do not seem to be saving files
- you are saving some sort of 'record'

"J French" <EMAIL REMOVED> wrote in message
news:EMAIL REMOVED...
> On Tue, 24 Aug 2004 11:18:40 +0000 (UTC), "Martin"
> <EMAIL REMOVED> wrote:
>
> <snip>
> However, AFAIK you do not seem to be saving files
> - you are saving some sort of 'record'
>

Sorry for that, I'm still learning, is this better?

On Tue, 24 Aug 2004 13:55:35 +0000 (UTC), "Martin"
<EMAIL REMOVED> wrote:

>
>
>
>"J French" <EMAIL REMOVED> wrote in message
>news:EMAIL REMOVED...
>> On Tue, 24 Aug 2004 11:18:40 +0000 (UTC), "Martin"
>> <EMAIL REMOVED> wrote:
>>
>> <snip>
>> However, AFAIK you do not seem to be saving files
>> - you are saving some sort of 'record'
>>
>
>Sorry for that, I'm still learning, is this better?

It is just the way you think of things
- or rather, how your users view things

"Martin" <EMAIL REMOVED> wrote in message
news:cgeuuq$el8$EMAIL REMOVED...
| 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: EMAIL REMOVED
| 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 ***ortment 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.

I expect Windows applications to utilize Windows common dialogs for common
tasks. If they don't, they're gone.

If I'm expected to open a file on XP for instance, I expect to see the File
Open dialog with the Places bar visible. On older versions I expect to see
the appropriate common dialog. If someone wants me to select a folder rather
than a file, I expect to see the Browse for Folders dialog. I say use the
common controls - either vb or the api versions - so your app looks like a
Windows app and not something thrown together in turbo pascal or delphi or
some other non-standard language with their own ideas of what the user
interface should look like.

If you want / need the browse dialog, see
http://vbnet.mvps.org/code/browse/index.html

If you want the common dialog api rather than the common dialog control, see
http://vbnet.mvps.org/code/comdlg/index.html

Under no circumstances would I use the file/dir/drive list boxes. These are
outdated components provided only for backward compatibility and that are
next to stone-age (circa 1992) in look, feel, and long file name support
depending on the OS they're used on. The VB help indicates these are
depreciated controls (that do not exist in vb.net for that matter), and they
recommend utilizing the common dialogs.

--

Randy Birch
MVP Visual Basic
http://vbnet.mvps.org/
Please respond only to the newsgroups so all can benefit.


"Martin" <EMAIL REMOVED> wrote in message
news:cgeuuq$el8$EMAIL REMOVED...
: 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: EMAIL REMOVED
: Web Site: http://home.btconnect.com/cadoss
:
: