472,131 Members | 1,400 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,131 software developers and data experts.

Common dialog control returns wrong filename !!

With the risk of being accused of multi-posting I would like to draw the
attention to a serious visual basic/windows issue discussed in the
microsoft.public.vb.bugs newsgroup. As pointed out below by Norman Diamond
the bug may result in loss of data when saving files with the standard
common dialog control.

Norman Diamond describes the problem as follows:

----------
In VB6 SP6, VB6 SP5, and possibly others, the common dialog box sometimes
returns a different filename from the name that is displayed on the filename
line.

Write a small program that opens a common dialog box for saving a file.
When executed, the dialog box shows a list of files presently existing in
the
directory. Do a single click on one filename and the filename is
automatically copied to the filename line in the dialog box. Edit the name
on the filename line to a nonexistent file, as if you want to save a new
file
with a slightly different name instead of overwriting the existing file.

Now, if you don't want to see the bug occur, then click immediately on the
Save button.

But if you do want to see the bug occur, for example if your customer
complains that your program overwrote their valuable data and you need to
prove whose fault it is, then you do the following instead. After slightly
editing the name in the filename line, click a blank spot inside the list of
filenames in the main part of the common dialog box. This wasted click does
not select a file. The name shown on the filename line remains as you
edited
it, it does not automatically change. Then click on the Save button. The
common dialog control returns to your program a filename of an existing file
instead of the new name that you put on the filename line. Your program
will
destroy your customer's existing data.

My boss just did similar tests with Microsoft Word, Excel, and other
applications. They do not have this bug. Only VB programs get hit by this
bug.
----------

I have not been able to find any solution/work-around to this problem.

Soeren
www.seqtools.dk
Jul 17 '05 #1
3 6627

"S.W. Rasmussen" <sw*@seqtools.dk> wrote in message
news:41*********************@dread16.news.tele.dk. ..
| With the risk of being accused of multi-posting I would like to draw
the
| attention to a serious visual basic/windows issue discussed in the
| microsoft.public.vb.bugs newsgroup. As pointed out below by Norman
Diamond
| the bug may result in loss of data when saving files with the standard
| common dialog control.
|
| Norman Diamond describes the problem as follows:
|
| ----------
| In VB6 SP6, VB6 SP5, and possibly others, the common dialog box
sometimes
| returns a different filename from the name that is displayed on the
filename
| line.
|
| Write a small program that opens a common dialog box for saving a
file.
| When executed, the dialog box shows a list of files presently existing
in
| the
| directory. Do a single click on one filename and the filename is
| automatically copied to the filename line in the dialog box. Edit the
name
| on the filename line to a nonexistent file, as if you want to save a
new
| file
| with a slightly different name instead of overwriting the existing
file.
|
| Now, if you don't want to see the bug occur, then click immediately on
the
| Save button.
|
| But if you do want to see the bug occur, for example if your customer
| complains that your program overwrote their valuable data and you need
to
| prove whose fault it is, then you do the following instead. After
slightly
| editing the name in the filename line, click a blank spot inside the
list of
| filenames in the main part of the common dialog box. This wasted
click does
| not select a file. The name shown on the filename line remains as you
| edited
| it, it does not automatically change. Then click on the Save button.
The
| common dialog control returns to your program a filename of an
existing file
| instead of the new name that you put on the filename line. Your
program
| will
| destroy your customer's existing data.
|
| My boss just did similar tests with Microsoft Word, Excel, and other
| applications. They do not have this bug. Only VB programs get hit by
this
| bug.
| ----------
|
| I have not been able to find any solution/work-around to this problem.
|
| Soeren
| www.seqtools.dk
|
|

I would think that setting the flag cdlOFNOverwritePrompt, which brings
up a confirmation for any file overwrite, would suffice.

I reproduced this behavior, using VB6 SP4, with Common Dialog SP3. With
the flag set, it prompts for overwrite confirmation, showing the last
selected existing file name.
Jul 17 '05 #2

"Steve Gerrard" <my********@comcast.net> wrote in message
news:Np********************@comcast.com...

"S.W. Rasmussen" <sw*@seqtools.dk> wrote in message
news:41*********************@dread16.news.tele.dk. ..
| With the risk of being accused of multi-posting I would like to draw
the
| attention to a serious visual basic/windows issue discussed in the
| microsoft.public.vb.bugs newsgroup. As pointed out below by Norman
Diamond
| the bug may result in loss of data when saving files with the standard
| common dialog control.
|
| Norman Diamond describes the problem as follows:
|
| ----------
| In VB6 SP6, VB6 SP5, and possibly others, the common dialog box
sometimes
| returns a different filename from the name that is displayed on the
filename
| line.
|
| Write a small program that opens a common dialog box for saving a
file.
| When executed, the dialog box shows a list of files presently existing
in
| the
| directory. Do a single click on one filename and the filename is
| automatically copied to the filename line in the dialog box. Edit the
name
| on the filename line to a nonexistent file, as if you want to save a
new
| file
| with a slightly different name instead of overwriting the existing
file.
|
| Now, if you don't want to see the bug occur, then click immediately on
the
| Save button.
|
| But if you do want to see the bug occur, for example if your customer
| complains that your program overwrote their valuable data and you need
to
| prove whose fault it is, then you do the following instead. After
slightly
| editing the name in the filename line, click a blank spot inside the
list of
| filenames in the main part of the common dialog box. This wasted
click does
| not select a file. The name shown on the filename line remains as you
| edited
| it, it does not automatically change. Then click on the Save button.
The
| common dialog control returns to your program a filename of an
existing file
| instead of the new name that you put on the filename line. Your
program
| will
| destroy your customer's existing data.
|
| My boss just did similar tests with Microsoft Word, Excel, and other
| applications. They do not have this bug. Only VB programs get hit by
this
| bug.
| ----------
|
| I have not been able to find any solution/work-around to this problem.
|
| Soeren
| www.seqtools.dk
|
|

I would think that setting the flag cdlOFNOverwritePrompt, which brings
up a confirmation for any file overwrite, would suffice.

I reproduced this behavior, using VB6 SP4, with Common Dialog SP3. With
the flag set, it prompts for overwrite confirmation, showing the last
selected existing file name.


Even with the overwrite warning enabled it is highly misleading - and very
bad programming practice - to save the file with a title different from that
displayed in the title text field of the dialogbox. In my experience
warnings tend to be OK'ed without being read / understood... Especially in
this case where the content of the warning is quite unexpected to the user.

I am surprised that this bug has survived for such a long time - and that it
cannot be easily corrected having Steve McMahon's source code at hand:

http://www.vbaccelerator.com/home/VB...ct/article.asp

Soeren
www.seqtools.dk
Jul 17 '05 #3
You could always use the API control and set up a hook, and when the message
indicating a selection change was made, update the textbox to reflect that
name. IOW, if the user is silly enough to re-click the listview after
providing a custom filename, they lose their customization.

I suggest you get over looking for a 'fix' to this 'bug' ... it ain't going
to happen. This is a windows common dialog issue, not a VB issue.

--
Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/
"S.W. Rasmussen" <sw*@seqtools.dk> wrote in message
news:41*********************@dread16.news.tele.dk. ..
:
: "Steve Gerrard" <my********@comcast.net> wrote in message
: news:Np********************@comcast.com...
: >
: > "S.W. Rasmussen" <sw*@seqtools.dk> wrote in message
: > news:41*********************@dread16.news.tele.dk. ..
: > | With the risk of being accused of multi-posting I would like to draw
: > the
: > | attention to a serious visual basic/windows issue discussed in the
: > | microsoft.public.vb.bugs newsgroup. As pointed out below by Norman
: > Diamond
: > | the bug may result in loss of data when saving files with the standard
: > | common dialog control.
: > |
: > | Norman Diamond describes the problem as follows:
: > |
: > | ----------
: > | In VB6 SP6, VB6 SP5, and possibly others, the common dialog box
: > sometimes
: > | returns a different filename from the name that is displayed on the
: > filename
: > | line.
: > |
: > | Write a small program that opens a common dialog box for saving a
: > file.
: > | When executed, the dialog box shows a list of files presently existing
: > in
: > | the
: > | directory. Do a single click on one filename and the filename is
: > | automatically copied to the filename line in the dialog box. Edit the
: > name
: > | on the filename line to a nonexistent file, as if you want to save a
: > new
: > | file
: > | with a slightly different name instead of overwriting the existing
: > file.
: > |
: > | Now, if you don't want to see the bug occur, then click immediately on
: > the
: > | Save button.
: > |
: > | But if you do want to see the bug occur, for example if your customer
: > | complains that your program overwrote their valuable data and you need
: > to
: > | prove whose fault it is, then you do the following instead. After
: > slightly
: > | editing the name in the filename line, click a blank spot inside the
: > list of
: > | filenames in the main part of the common dialog box. This wasted
: > click does
: > | not select a file. The name shown on the filename line remains as you
: > | edited
: > | it, it does not automatically change. Then click on the Save button.
: > The
: > | common dialog control returns to your program a filename of an
: > existing file
: > | instead of the new name that you put on the filename line. Your
: > program
: > | will
: > | destroy your customer's existing data.
: > |
: > | My boss just did similar tests with Microsoft Word, Excel, and other
: > | applications. They do not have this bug. Only VB programs get hit by
: > this
: > | bug.
: > | ----------
: > |
: > | I have not been able to find any solution/work-around to this problem.
: > |
: > | Soeren
: > | www.seqtools.dk
: > |
: > |
: >
: > I would think that setting the flag cdlOFNOverwritePrompt, which brings
: > up a confirmation for any file overwrite, would suffice.
: >
: > I reproduced this behavior, using VB6 SP4, with Common Dialog SP3. With
: > the flag set, it prompts for overwrite confirmation, showing the last
: > selected existing file name.
: >
: >
:
: Even with the overwrite warning enabled it is highly misleading - and very
: bad programming practice - to save the file with a title different from
that
: displayed in the title text field of the dialogbox. In my experience
: warnings tend to be OK'ed without being read / understood... Especially in
: this case where the content of the warning is quite unexpected to the
user.
:
: I am surprised that this bug has survived for such a long time - and that
it
: cannot be easily corrected having Steve McMahon's source code at hand:
:
:
http://www.vbaccelerator.com/home/VB...ct/article.asp
:
: Soeren
: www.seqtools.dk
:
:

Jul 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by John Lauwers | last post: by
6 posts views Thread by Steve Barnett | last post: by
3 posts views Thread by Koliber (js) | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.