Common dialog control returns wrong filename
Norman Diamond
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.
Peter Huang
I can reproduce the problem on my side, now I am researching the problem
and I will update you with new information ASAP.
Best regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
David Youngblood
>
> I can reproduce the problem on my side, now I am researching the problem
> and I will update you with new information ASAP.
Also reproducible using GetSaveFileName API.
David
Franz Strele
"Norman Diamond" <ndia...@nospam.nospam> schrieb im Newsbeitrag
news:2AF9BB59-EAE5-413F...@microsoft.com...
...
> 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.
if you set the overwrite-prompt-flag ("cdlOFNOverwritePrompt" for vb,
"OFN_OVERWRITEPROMPT" for win32-api) you get at least a warning that the
(existing) file gets overwritten...
franz
Randy Birch
common dialogs. It is caused by the listview generating a CDN_SELCHANGE
message when the listview area is clicked. When a white space is clicked the
highlighting is removed from the current selection, causing the
CDN_SELCHANGE message. I suspect code responding to the CDN_SELCHANGE
message interrogates the listview as to its currently-selected item
returning the name of the previously selected item. This is not a bug per
se, but rather the way a listview works. For example, in a VB application
utilizing a listview, querying the Selected property will indicate that an
item has been selected when the listview is first loaded, even if the user
has not actually done so.
Remember too that Word and Excel do not use the Windows common dialogs, so
their custom implementation to duplicate the functionality of the real
common dialogs may circumvent the problem. I suggest you try the same test
with Notepad, Paint, or any other Windows or third-party application that
uses the real common dialogs.
--
Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/
"Norman Diamond" <ndia...@nospam.nospam> wrote in message
news:2AF9BB59-EAE5-413F...@microsoft.com...
: In VB6 SP6, VB6 SP5, and possibly others, the common dialog box sometimes
Randy Birch
uMsg \ uMsg(int) \ wparam \ lparam
CDN_INITDONE \ 78 \ 0 \ 1235464
CDN_SELCHANGE \ 78 \ 0 \ 1236276 'on showing dialog
CDN_SELCHANGE \ 78 \ 0 \ 1236276 'on selecting file aa.txt
'user edits aa.txt to become aa2.txt
CDN_SELCHANGE \ 78 \ 0 \ 1236276 'on clicking the white space in the lv
'OK pressed
File name returned: aa.txt
--
Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/
"Randy Birch" <rgb_rem...@mvps.org> wrote in message
news:usrYKWnp...@tk2msftngp13.phx.gbl...
: This is not a "bug" in VB, but rather an "issue" particular to Windows
:
David Youngblood
> This is not a "bug" in VB, but rather an "issue" particular to Windows
> common dialogs. It is caused by the listview generating a CDN_SELCHANGE
> message when the listview area is clicked.
The problem does not occur in the ShowOpen dialog, but does in the ShowSave
dialog. I would assume that they both use the same ListView control.
> Remember too that Word and Excel do not use the Windows common dialogs, so
> their custom implementation to duplicate the functionality of the real
> common dialogs may circumvent the problem. I suggest you try the same test
> with Notepad, Paint, or any other Windows or third-party application that
> uses the real common dialogs.
I would say that that just makes it a windows bug instead of a vb bug. <g>
I can't envision any circumstance in which returning a wrong filename (a
filename other than the filename in the filename box) could be considered
acceptable.
Here are some steps to reproduce the problem without clicking on the listview.
1) Call the common dilalog ShowOpen
2) Click on a file, any file
3) Type in a different name in the filename box (existing or not)
4) Tab through the controls until the filename box has focus again,
or alternately Shift+Tab, Tab
5) Clicking Save, the dialog will return the filename from step 2
David
Randy Birch
I thought it did when I first tested it.
--
Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/
"David Youngblood" <d...@flash.net> wrote in message
news:O9i3bLop...@TK2MSFTNGP09.phx.gbl...
: "Randy Birch" <rgb_rem...@mvps.org> wrote
:
:
:
David Youngblood
> 1) Call the common dilalog ShowOpen
That should have been ShowSave. The problem does not occur in the ShowOpen
dialog.
1) Call the common dilalog ShowSave
Peter Huang
Based on my test, the SaveFileDialog in VB.NET has the same problem. It
seems that perhaps the underlying filedialog has the default behavior.
I will keep researching the problem, if I have any new information, I will
update you with new information ASAP.
Best regards,
Norman Diamond
> "Norman Diamond" <ndia...@nospam.nospam> schrieb im Newsbeitrag
> news:2AF9BB59-EAE5-413F...@microsoft.com...
>
> > instead of the new name that you put on the filename line. Your program will
> > destroy your customer's existing data.
>
> if you set the overwrite-prompt-flag ("cdlOFNOverwritePrompt" for vb,
> "OFN_OVERWRITEPROMPT" for win32-api) you get at least a warning that the
> (existing) file gets overwritten...
Herr Strele, thank you for your suggestion. I do not mark your posting as an
"answer" because the bug (Windows bug instead of VB bug) still remains, it is
a serious bug, and I don't want Microsoft to think it is solved. But as a
partial
workaround it is indeed helpful, thank you.
Peter Huang
Thank you for you input.
Now we have been aware of the issue and I have reported the issue to our
product team, maybe it will be fixed in the next service pack, but I can
not guarantee if this will be done.
Thank you for your understanding!
Norman Diamond
> maybe it will be fixed in the next service pack, but I can
> not guarantee if this will be done.
Somewhere I once read that Microsoft took rather seriously, issues that
cause loss of data. After my experiences with various Windows versions
destroying entire contents of hard disk partitions I could not really believe
that statement. Now here is additional confirmation, though on a rather
smaller scale.
Mr. Huang, I do appreciate your understanding of the problem, but
understanding is just one step. By not issuing a hotfix and not guaranteeing
that a service pack will fix it, your company really shows how seriously it
takes issues that cause loss of data.
Peter Huang
Have you tried Franz's suggestion that use the "cdlOFNOverwritePrompt" flag
which will invoke a warning dialog when overwriting file?
I think this will help to partially avoid the problem. This should be a
workaround.
Although we have reported the problem to our product team, there will be
special approach to evalue if hotfix or service pack will be provided.
Hope this helps.
Brett Keown [MSFT]
I can appreciate your frustration in not having a hotfix guaranteed. I
believe what Peter is trying to say here is that he has no control over the
bug fix / hotfix / QFE process. He can submit it as an item for review, but
then the Product Group owns the issue and it is out of his hands.
For even the most serious of bugs (like data loss scenarios), we would
never "guarantee" that it will be resolved in the next version or Service
Pack. Even if we were 100% sure that it would be included. What would
happen if he did make such a promise, only to later find that the fix broke
many other items through regression testing? He would have then set your
expectations inappropriately, You would never know that there was a bug
fix, which failed at the last minute and had to be pulled, you would only
see that nothing had been done to address your issue though you had been
promised it would be taken care of.
If this is an urgent issue for you, I encourage you to let me know. My
email address is below, just remove the "online" portion from it. I will
be happy to help you open a support incident and walk its escalation
through our processes to see if we can get a hotfix out for you a bit
quicker then the next release. As I said however, there are no promises
that this will be possible.
Brett Keown
Microsoft Support
bre...@online.microsoft.com