CFileDialog problems and other questions...
Peter.J.Garcin@JCI.Com
Tuesday, January 21, 1997
Environment: VC++ 4.1, NT 4.0
Ok, here's the situation:
I've subclassed CFileDialog and overridden the OnInitDialog method.
Now, the idea is that this Common Open Dialog doesn't read from a
disk, but from a database, so in the OnInitDialog method, it opens the
database and feeds the controls the information from the database that
they need. The idea was to eliminate lots of coding, and "hi-jack" the
existing system dialogs... it didn't work. Although OnInitDialog
finishes without an error and everything seems to be going fine, a few
seconds later an Access Violation (at some crazy address) in
COMDLG32.DLL comes up. It stops and it's in the middle of assembly
code. My feeling is that Microsoft has it set so that you can't mess
with the data going to the controls in the common dialogs. Am I right
or wrong? There doesn't seem to be anything "illegal" about what I'm
trying to do, but yet there is still an access violation in the DLL
file.
So, the alternate solution was to build a custom dialog to do the same
thing. No problem, except I never thought about two small things:
1. How to insert graphics in a typical list box? (the control in the
COMDLG32.DLL has a regular NON owner draw list box...how does that
work?) It seems to be a bit of overkill to use a CListCtrl.
2. The CComboBox tree structure that the new dialogs have...I realize
that these are owner draw boxes, but how do I go about building that
tree that is in the drop down box?
Well, I hope someone can help, I've looked around and there seems to
be just nothing about these topics. They are extremely common
everywhere in Windows, yet information on how to implement this sort
of thing is nonexistent.
Thanks,
~pete
---
Peter Garcin
Toronto Software Design Centre
Johnson Controls Inc.
Mihir Dalal -- m_dalal@ECE.concordia.CA
Thursday, January 23, 1997
[Mini-digest: 2 responses]
Peter,
I have been into this stuff of customizing CFileDialog for quite some
time now, and have been trying all kind of things with the CFileDialog.
Although, I have never tried precisely what you are trying, but I have
been able to fill the CFileDialog with whatever data I have liked to.
I am sure, if the data comes from a database, CFileDialog should be able
to handle it perfectly.
Believe me, MFC lends you complete control over all
the list/edit/combo boxes and push buttons on the CFileDialog box.
I am sure, you are doing something wrong somewhere which possibly
is very minute to detect.
Try this:
Open the database just before you call DoModal() for CYourFileDialog,
pass a pointer to the opened database to CYourFileDialog()
and then try to load the controls in the OnInitDialog() of CYourFileDialog,
instead of both opening and reading the database in OnInitDialog().
Your code would look something like this:
CYourFileDialog dlg;
// Open the database here or just anytime before reaching here
// and for the time being assume m_pSet is the pointer to your
// opened database
// pDBase is a database pointer declared in CYourFileDialog()
dlg.pDBase = m_pSet;
dlg.DoModal();
Then, in the OnInitDialog() you can use pDBase to access the database
and load your dialog list/combo boxes.
Mihir.
------------------ Dept. of Elec. & Comp. (ECE) Engg. -----------------------
Mihir Dalal phone : 1-514-274-4430
M.Engg (Electrical) Student fax : 1-514-421-1166
Concordia University emails : m_dalal@ece.concordia.ca
1455, De Maissoneuve Blvd. dalal@vlsi.concordia.ca
Montreal QC CANADA H3G 1M8 m_dalal@alcor.concordia.ca
----------- http://www.ece.concordia.ca/~m_dalal/addr.html ------------------
On Tue, 21 Jan 1997 Peter.J.Garcin@JCI.Com wrote:
> Environment: VC++ 4.1, NT 4.0
>
> Ok, here's the situation:
>
> I've subclassed CFileDialog and overridden the OnInitDialog method.
> Now, the idea is that this Common Open Dialog doesn't read from a
> disk, but from a database, so in the OnInitDialog method, it opens the
> database and feeds the controls the information from the database that
> they need. The idea was to eliminate lots of coding, and "hi-jack" the
> existing system dialogs... it didn't work. Although OnInitDialog
> finishes without an error and everything seems to be going fine, a few
> seconds later an Access Violation (at some crazy address) in
> COMDLG32.DLL comes up. It stops and it's in the middle of assembly
> code. My feeling is that Microsoft has it set so that you can't mess
> with the data going to the controls in the common dialogs. Am I right
> or wrong? There doesn't seem to be anything "illegal" about what I'm
> trying to do, but yet there is still an access violation in the DLL
> file.
>
> So, the alternate solution was to build a custom dialog to do the same
> thing. No problem, except I never thought about two small things:
>
> 1. How to insert graphics in a typical list box? (the control in the
> COMDLG32.DLL has a regular NON owner draw list box...how does that
> work?) It seems to be a bit of overkill to use a CListCtrl.
>
> 2. The CComboBox tree structure that the new dialogs have...I realize
> that these are owner draw boxes, but how do I go about building that
> tree that is in the drop down box?
>
> Well, I hope someone can help, I've looked around and there seems to
> be just nothing about these topics. They are extremely common
> everywhere in Windows, yet information on how to implement this sort
> of thing is nonexistent.
>
> Thanks,
>
> ~pete
>
> ---
> Peter Garcin
> Toronto Software Design Centre
> Johnson Controls Inc.
-----From: =?iso-8859-1?Q?Klaus_G=FCtter?=
Peter,
1. On WinNT 4.0, the "list box" in the file open dialog *is a* list view
control as can be verified using Spy++. I don't think this is overkill
as a list view control does exactly what you want.
2. Graphically, this is simple: just draw the icon and text with the
desired indentation. A convenient place to fill the list is on the
CBN_DROPDOWN notification.
If you want to use the original file open dialog: this is possible, but
you will have to create something called a "shell extension" (Query for
IShellFolder in Books Online for more information about these). This is
some good amount of work and for sure is not the way to go if you do not
need the extra profit of a perfect shell integration.
- Klaus Guetter
>----------
>Von: Peter.J.Garcin@JCI.Com[SMTP:Peter.J.Garcin@JCI.Com]
>Gesendet: Dienstag, 21. Januar 1997 22:45
>An: mfc-l@netcom.com
>Betreff: CFileDialog problems and other questions...
>
> Environment: VC++ 4.1, NT 4.0
>
> Ok, here's the situation:
>
> I've subclassed CFileDialog and overridden the OnInitDialog method.
> Now, the idea is that this Common Open Dialog doesn't read from a
> disk, but from a database, so in the OnInitDialog method, it opens the
> database and feeds the controls the information from the database that
> they need. The idea was to eliminate lots of coding, and "hi-jack" the
> existing system dialogs... it didn't work. Although OnInitDialog
> finishes without an error and everything seems to be going fine, a few
> seconds later an Access Violation (at some crazy address) in
> COMDLG32.DLL comes up. It stops and it's in the middle of assembly
> code. My feeling is that Microsoft has it set so that you can't mess
> with the data going to the controls in the common dialogs. Am I right
> or wrong? There doesn't seem to be anything "illegal" about what I'm
> trying to do, but yet there is still an access violation in the DLL
> file.
>
> So, the alternate solution was to build a custom dialog to do the same
> thing. No problem, except I never thought about two small things:
>
> 1. How to insert graphics in a typical list box? (the control in the
> COMDLG32.DLL has a regular NON owner draw list box...how does that
> work?) It seems to be a bit of overkill to use a CListCtrl.
>
> 2. The CComboBox tree structure that the new dialogs have...I realize
> that these are owner draw boxes, but how do I go about building that
> tree that is in the drop down box?
>
> Well, I hope someone can help, I've looked around and there seems to
> be just nothing about these topics. They are extremely common
> everywhere in Windows, yet information on how to implement this sort
> of thing is nonexistent.
>
> Thanks,
>
> ~pete
>
> ---
> Peter Garcin
> Toronto Software Design Centre
> Johnson Controls Inc.
>
Mike Blaszczak -- mikeblas@nwlink.com
Saturday, January 25, 1997
At 15:45 1/21/97 -0600, Peter.J.Garcin@JCI.Com wrote:
> Environment: VC++ 4.1, NT 4.0
> Ok, here's the situation:
> I've subclassed CFileDialog and overridden the OnInitDialog method.
> Now, the idea is that this Common Open Dialog doesn't read from a
> disk, but from a database, so in the OnInitDialog method, it opens the
> database and feeds the controls the information from the database that
> they need.
The controls _need_ information that describes a file structure.
>The idea was to eliminate lots of coding, and "hi-jack" the
> existing system dialogs.
What coding would you be eliminating? I'm not sure I understand the intended
application of your dialog box. Are you allowing the user to open a database,
or are you allowing the user to choose a local file based on information
stored in a database?
> Although OnInitDialog
> finishes without an error and everything seems to be going fine, a few
> seconds later an Access Violation (at some crazy address) in
> COMDLG32.DLL comes up.
What message was being handled at the time? For which control was it
destined?
>My feeling is that Microsoft has it set so that you can't mess
> with the data going to the controls in the common dialogs. Am I right
> or wrong?
You're wrong: there is no conspiracy.
> There doesn't seem to be anything "illegal" about what I'm
> trying to do, but yet there is still an access violation in the DLL
> file.
I don't think there's any way for us to tell if you're doing anything wrong
or not--you've not clearly described your goal, and you've not clearly and
in detail described how you're trying to attain that goal.
By initializing the controls yourself, you're working with the assumption
that you know how to properly initialize them. If you don't properly
initialize them, you're not going to get very far. This is your fault
for not initializing the controls correctly; it's not a that Microsoft
(for some unspoken reason) is interested in "setting it" so that you
"cant mess with data going to the controls in the common dialogs".
Quite the opposite is the case, in fact: my book has a couple of samples
which (sometimes heavily) customize the look of the dialogs. One of the
samples parties on the data in the controls directly. It _is_ possible
to mess with the data going to the controls in the dialogs.
If you've messed the data so severely that it isn't at all what the
provided message hanlders for the controls expect, you can bet on crashing.
That only makes sense! If you need to change the data so severly that
the Windows-supplied code can't deal with it, you should revisit your
architecture.
Maybe you can write handlers for the offdending messages and do something
in response to them that's appropriate for the data you've loaded. Or, maybe
your application of the dialog is inappropriate. Given the precious little
specific information you've provided about your application, my hunch is
that the latter condition is the case.
> 1. How to insert graphics in a typical list box? (the control in the
> COMDLG32.DLL has a regular NON owner draw list box...how does that
> work?) It seems to be a bit of overkill to use a CListCtrl.
Why? List view controsl are designed entirely for exactly that kind
of application.
> 2. The CComboBox tree structure that the new dialogs have...I realize
> that these are owner draw boxes, but how do I go about building that
> tree that is in the drop down box?
The tree should already be built. The tree shown in the drop-down lets
you navigate the hierarchy of desktop names and devices on your machine.
If you have such a hierarchy, you already have the tree. If you don't have
the tree, it strongly suggests that no navigable hierarchy exists in your
application. It's quite possible that you don't need the tree and simply
provide a flat list in the combo box.
> Well, I hope someone can help, I've looked around and there seems to
> be just nothing about these topics. They are extremely common
> everywhere in Windows, yet information on how to implement this sort
> of thing is nonexistent.
Hardly! Look at the SDK documentation. It's _loaded_ with stuff about
customizing the file dialog box. See the topic "Open and Save As
Dialog Box Customization" right in the SDK. Check out the related topics
named "Explorer-Style Hook Procedures", and "Explorer-Style Control
Identifiers". You might want to make your own template; perhaps you should
read the topic named "Explorer-Style Custom Templates", too.
My book can't possibly be the only one that shows how to customize a file
dialog. I think that the new Prosise book shows how, for example, and
I remember seeing a chapter or two on it in other books I've examined.
You might try looking at the Knowledge Base, too. Article Q102332 is
titled "How to Show a Custom Common Dialog using CFileDialog", and that
sounds pretty much like what you're doing.
I'm sorry to so strongly refute your assertion that "information on how to
implement this sort of thing is nonexistent". Not researching the matter
and then saying that the dozens of people who write books, documentation,
and manage online resources like the Knowledge Base haven't done anything
isn't very responsible.
.B ekiM
http://www.nwlink.com/~mikeblas/
Why does the "new" Corvette look like a 1993 RX-7?
These words are my own. I do not speak on behalf of Microsoft.
Colin W. Earle -- cwe@denton.chem.arizona.edu
Monday, January 27, 1997
On Sat, 25 Jan 1997, Mike Blaszczak wrote:
(...snip...)
> Quite the opposite is the case, in fact: my book has a couple of samples
> which (sometimes heavily) customize the look of the dialogs. One of the
> samples parties on the data in the controls directly. It _is_ possible
> to mess with the data going to the controls in the dialogs.
>
But, these examples don't completely work. I'm trying to do something
similar to the original poster, but have been unsuccessful. I've been
trying to get a grasp on customiziing common dialogs using Mike's book
but I've had problems with the following two examples. The first is the
CColorDialog example (p 230) which implements the color common dialog and
preset the current color using the member ftn SetCurrentColor. This always
produces an assertion failure for me because the m_hWnd is not yet valid for
the dialog. The MFC reference states that this function is used after calling
doModal so I guess this makes sense to me. I implement the color preset using
the member m_cc struct like this:
dlg.m_cc.rgbResult = someColor;
dlg.m_cc.Flags |= CC_RGBINIT
Is this necessary or am I missing a trick to use SetCurrentColor before
calling doModal?
The other is the StdBoxes example on the CD. The file open test
doesn't do anything. I stepped through the code in the debugger and it
always returns from CFileDialog with IDCANCEL without displaying the
dialog, modified or otherwise. Any suggestions on how I can make this
work? Thanks for your help.
Environment: VC++ 4.0, Win95, NT
thanks,
Colin
PS I do *not* mean this as bait or a flame on Mike. Other than these
two examples, I've found his book to be outstanding.
Colin Earle http://denton.chem.arizona.edu/~cwe
Research Assistant, U. of Arizona mailto:cwe@denton.chem.arizona.edu
phone: (520) 621-8247 (work) /* insert pithy comment here */
| Вернуться в корень Архива
|