MFC DocObject greyed OLE Command update
Dave Kolb -- sasdxk@wnt.sas.com
Tuesday, January 07, 1997
Environment: VC++ 4.2b and Windows NT 4.0 SP2
Some of this works now that I have updated to NT 4.0 SP2 and Office 97
one of which updated the MFC42.DLL library which was at version
4.2.6256 (Product version 4.2.000) and is now at 4.21.6318 (Product
version 5.0.000. Perhaps I did not have the 4.2b patch applied
properly and was not really using MFC 4.2b code before PRINT was
working??? Too late to tell now but perhaps we should all post the
version and product versions from now on (assuming higher levels
include the earlier patches) as the VC++ patches seem to update the
version number (VC++ 4.2 base was 4.2.6068 and 4.2b seems to be
4.2.6256).
Mike, are these version numbers and upward compatible assumptions
correct?
Both mine and the BindScrb DocObject now seem to correctly support the
Office Binder Section menu Print command (and mine the Page Setup
command also but not BindScrb).
But the Print Preview and Section Properties commands from the Office
Binder Section menu are still greyed out. Anything special needed to
support Print Preview or Section Properties? My toolbar Print Preview
works but I can never get back as the Print Preview looses it's header
with the CLOSE control.
Here is my OLE Command map (and all the possible OLE Commands I
think). Is there an undocumented one for Section Properties???
BEGIN_OLECMD_MAP(CsvGDoc, COleServerDoc)
// ON_OLECMD_OPEN()
// ON_OLECMD_NEW()
// ON_OLECMD_SAVE()
ON_OLECMD_SAVE_AS()
ON_OLECMD_SAVE_COPY_AS()
ON_OLECMD_PRINT()
ON_OLECMD_PRINTPREVIEW()
ON_OLECMD_PAGESETUP()
// ON_OLECMD_CUT()
ON_OLECMD_COPY()
// ON_OLECMD_PASTE()
// ON_OLECMD_PASTESPECIAL()
// ON_OLECMD_UNDO()
// ON_OLECMD_REDO()
ON_OLECMD_SELECTALL()
ON_OLECMD_CLEARSELECTION()
END_OLECMD_MAP()
Thanks,
Dave Kolb
SAS Institute
Mike Blaszczak -- mikeblas@nwlink.com
Wednesday, January 08, 1997
At 15:00 1/7/97 -0500, Dave Kolb wrote:
>Environment: VC++ 4.2b and Windows NT 4.0 SP2
>Too late to tell now but perhaps we should all post the
>version and product versions from now on
That's not really necessary, I don't think. If you actually called
product support services, they might want to know to see if a
particular problem has been fixed, but for informal support on
mailing lists it really doesn't matter.
>as the VC++ patches seem to update the
>version number (VC++ 4.2 base was 4.2.6068 and 4.2b seems to be
>4.2.6256).
No, it isn't. The patch MFC 4.2b has a much lower build number than
6256. You must've gotten 6256 from some other source, like Office.
I'm at home without any tools, but I think I remember the patched
build being 6166. You can look at the BUILD_.H file in the MFC\SRC
directory to see what version of the source you have. Since you
don't build MFC yourself, this might not match the exeutable
you have installed. It should match the build number of the debug
libraries you have installed, though--otherwise, source code you
trace through won't match the binary you trace through.
Since the patches update the executable image, they change the version
number so that you can tell the images apart. This way, no program
has an excuse to overwrite a newer library with an older one.
>(assuming higher levels
>include the earlier patches)
Yes, of course they do.
At Microsoft, the development of software is a very continuous
process. We constantly update and change and rebuild the products.
Some huge products are built one a week, like Office. Some products,
like VB, Visual C++ and Windows NT, are built every single day.
The image is stamped with the version number (like the "4.2"
in "4.2.xxxx") and a juian date form (like the "6068" in
"m.n.6068"). The julain date form is made from the last digit
of the year ("6", here, from "1996") and the ordinal day number
(the 68th day of the year for "068" here).
Ignoring the semantics of quality goals, development just keeps
going: the development team just makes new features and fixes bugs
until someone finally decides to take a snapshot of the project and
call it a shipping version. The build you found was made
on the 256th day of 1996, probably from a snapshot of the source
code that occurred sometime on the morning of the 255th day.
It isn't worth it to report particular version numbers. While we
do track bugs down to the build number they were found in and
the build number they were fixed in, nobody walks around with the
whole database. We fixed problems throught the product all summer,
so you'll certainly notice differences between build 6068 and
6256--it represents more than 170 days of work!
>Mike, are these version numbers and upward compatible assumptions
>correct?
If an MFC DLL has the same file name as another build of MFC, it is
always upward compatible. That is, you can replace MFC42.DLL with a
newer build of MFC42.DLL and not expect trouble. You can go backwards,
too, but I'm not sure why you'd ever wnat to do that. Any setup
program that installs any MFC DLL must (must!) do a proper version
check.
I don't use Office 97, so I don't know what version of MFC it might
install. You should stick to redistributing the version of MFC that
you get with Visual C++. You should stick to testing with it, too;
I'm a little surprised that the Office guys dropped their product
with a newer version of MFC42.DLL.
>Both mine and the BindScrb DocObject now seem to correctly support the
>Office Binder Section menu Print command (and mine the Page Setup
>command also but not BindScrb).
There's a difference between print setup and page setup; I think that
BINDSCRB supports only one and not the other, even though it at one
time had ON_OLECMD macros for both commands.
.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.
Dave Kolb -- sasdxk@wnt.sas.com
Thursday, January 09, 1997
[Mini-digest: 2 responses]
...
>as the VC++ patches seem to update the
>version number (VC++ 4.2 base was 4.2.6068 and 4.2b seems to be
>4.2.6256).
No, it isn't. The patch MFC 4.2b has a much lower build number than
6256. You must've gotten 6256 from some other source, like Office.
I'm at home without any tools, but I think I remember the patched
build being 6166. You can look at the BUILD_.H file in the MFC\SRC
directory to see what version of the source you have. Since you
don't build MFC yourself, this might not match the exeutable
you have installed. It should match the build number of the debug
libraries you have installed, though--otherwise, source code you
trace through won't match the binary you trace through.
My msdev\mfc\src\build_.h has version 6139. After running "patch-nt
/NOS /NOP dll42b" with only original copies of mfc42.dll and
mfc42d.dll in the directory, both at version 6068, I end up with a
mfc42.dll that has version 6256 and a mfc42d.dll that has version 6269
in that directory.
Am I doing something wrong or is my dll42b.rtp bad or out of sync with
the header file? I pasted the patch output below. Should the release
and debug be different versions after the patch?
P.S. My original problem with greyed OLECMDs in the Office Binder (95
and 97) actually seems to be related to whether I'm running a release
or debug version of my project. Release works, debug does not. This is
true of the BindScrb DocObject example also. If version number relates
to the date of development then I'd think this is very important to
make sure things like patches and fixes you made are actually
included.
<<
D:\MSDEV\DLL2>patch-nt /NOS /NOP dll42b
----------------------------------------------------------
PATCH Version 3.20 - .RTPatch(R) Professional - Softwa
DOS/Windows/Windows 95/Windows NT Edit
(C) Copyright Pocket Soft, Inc., 1991-1996. All Ri
----------------------------------------------------------
----- Processing Patch File -----
Applying MODIFY File Patch for 'mfc42.dll'
Writing New File
Verifying - Passed!
Deleting Old File
...
Applying MODIFY File Patch for 'MFC42.DLL'
Writing New File
Verifying - Passed!
Deleting Old File
...
Applying MODIFY File Patch for 'MFC42D.DLL'
Writing New File
Verifying - Passed!
Deleting Old File
...
----- Patch File Processing Complete -----
-----------------------------------------------------
- Results of Application of Patch File -
-----------------------------------------------------
File Patches Applied ......................... ( 3)
Files Modified .................. ( 3)
Files Renamed. .................. ( 0)
Files Added ..................... ( 0)
Files Deleted ................... ( 0)
Temporary Files Processed........ ( 0)
File Patches Skipped: New Files Up-To-Date.... ( 0)
File Patches Ignored: Old Files Missing....... ( 37)
Old Files Invalid....... ( 0)
-----------------------------------------------------
Total File Patches Processed ................. ( 40)
----------------------------------------------------->>
Thanks,
Dave Kolb
-----From: Jeff Hare
At 12:27 AM 1/8/97 -0800, Mike Blaszczak wrote:
>At 15:00 1/7/97 -0500, Dave Kolb wrote:
>
>>Environment: VC++ 4.2b and Windows NT 4.0 SP2
>
>>Too late to tell now but perhaps we should all post the
>>version and product versions from now on
>
>That's not really necessary, I don't think. If you actually called
>product support services, they might want to know to see if a
>particular problem has been fixed, but for informal support on
>mailing lists it really doesn't matter.
>
>>as the VC++ patches seem to update the
>>version number (VC++ 4.2 base was 4.2.6068 and 4.2b seems to be
>>4.2.6256).
>
>No, it isn't. The patch MFC 4.2b has a much lower build number than
>6256. You must've gotten 6256 from some other source, like Office.
>I'm at home without any tools, but I think I remember the patched
>build being 6166. You can look at the BUILD_.H file in the MFC\SRC
>directory to see what version of the source you have. Since you
>don't build MFC yourself, this might not match the exeutable
>you have installed. It should match the build number of the debug
>libraries you have installed, though--otherwise, source code you
>trace through won't match the binary you trace through.
This is interesting since, in this order, I:
==========================================
* installed WinNT 4.0 on a fresh machine
* installed Office Pro (for Win95)
* installed MS Internet Explorer 3.0 (4.70.1215)
* installed MSVC 4.1 (then decided to upgrade to 4.2)
* installed MSVC 4.2
* applied the 4.2b patches (only got complaints about missing dlls for
internationalization stuff I didn't install.)
* After rebooting, MSIE wouldn't run. (Sorry for the vague error here,
(it was about a month ago) the error was about some routine not being
found in an MFC Dll which I've since forgotten the name.)
* Reinstalled MSIE and it started working again.
This baffled me because the patch error log reported no failures except
on things which I chose not to install in MSVC.
The long and the short of it is that
MFC42.dll now reports V: 4.2.6256
MFC42d.dll now reports V: 4.2.6269
Yet, I look in the BUILD_.H file in the MFC\SRC and it reports version 6068,
but many source files have obviously been modified by the patch since I had
zipped a copy of the src tree prior to the patch and compared them.
Got me, I followed the directions. :) carefully :)
>
>Since the patches update the executable image, they change the version
>number so that you can tell the images apart. This way, no program
>has an excuse to overwrite a newer library with an older one.
>
>>(assuming higher levels
>>include the earlier patches)
>
>Yes, of course they do.
>
>At Microsoft, the development of software is a very continuous
>process. We constantly update and change and rebuild the products.
>Some huge products are built one a week, like Office. Some products,
>like VB, Visual C++ and Windows NT, are built every single day.
>
>The image is stamped with the version number (like the "4.2"
>in "4.2.xxxx") and a juian date form (like the "6068" in
>"m.n.6068"). The julain date form is made from the last digit
>of the year ("6", here, from "1996") and the ordinal day number
>(the 68th day of the year for "068" here).
>
>Ignoring the semantics of quality goals, development just keeps
>going: the development team just makes new features and fixes bugs
>until someone finally decides to take a snapshot of the project and
>call it a shipping version. The build you found was made
>on the 256th day of 1996, probably from a snapshot of the source
>code that occurred sometime on the morning of the 255th day.
>
>It isn't worth it to report particular version numbers. While we
>do track bugs down to the build number they were found in and
>the build number they were fixed in, nobody walks around with the
>whole database. We fixed problems throught the product all summer,
>so you'll certainly notice differences between build 6068 and
>6256--it represents more than 170 days of work!
>
>>Mike, are these version numbers and upward compatible assumptions
>>correct?
>
>If an MFC DLL has the same file name as another build of MFC, it is
>always upward compatible. That is, you can replace MFC42.DLL with a
>newer build of MFC42.DLL and not expect trouble. You can go backwards,
>too, but I'm not sure why you'd ever wnat to do that. Any setup
>program that installs any MFC DLL must (must!) do a proper version
>check.
>
>I don't use Office 97, so I don't know what version of MFC it might
>install. You should stick to redistributing the version of MFC that
>you get with Visual C++. You should stick to testing with it, too;
>I'm a little surprised that the Office guys dropped their product
>with a newer version of MFC42.DLL.
>
>>Both mine and the BindScrb DocObject now seem to correctly support the
>>Office Binder Section menu Print command (and mine the Page Setup
>>command also but not BindScrb).
>
>There's a difference between print setup and page setup; I think that
>BINDSCRB supports only one and not the other, even though it at one
>time had ON_OLECMD macros for both commands.
>
>.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.
>
>
| Вернуться в корень Архива
|