MFC OCX crashes Excel 5 NT
Randal Parsons -- Randal.Parsons@btal.com.au
Tuesday, February 13, 1996
Hi.
I have been developing an OCX using VC++ 4.0 and it works fine
in the Test Container program provided. I thought it would be a
good idea to try it in other sorts of containers, such as Excel
and Word. Unfortunately, Excel crashes and Word resizes the
inserted object back to its original size after you have
stretched it.
Just in case the fault was mine, I generated a brand new OCX and
compiled it - without modifying any of code. This OCX exhibited
*identical* behaviour to my original OCX.
The error message in Excel was :
The exception Illegal Instruction
An attempt was made to excute an illegal instruction.
(0xc000001d) occurred in the application at location
0x0012f1d0.
The hex codes are identical for any OCX I have been able to
generate.
I have used VC++ 2.2 to generate an OCX and found that it works
perfectly in Excel, but Word still shrinks the object back to
its original (creation) size.
Has anyone else seen this behaviour? Is there some magical
combination of compiler options that will enable my OCXs to
work? I would appreciate any assistance.
Regards,
Randal Parsons.
PS. I'm running NT 3.51, Excel 5.0 for Windows NT, Word 6.0 for
Windows NT.
Mike Blaszczak -- mikeblas@interserv.com
Wednesday, February 14, 1996
On Tue, 13 Feb 1996, Randal Parsons wrote:
>Just in case the fault was mine, I generated a brand new OCX and
>compiled it - without modifying any of code. This OCX exhibited
>*identical* behaviour to my original OCX.
How are you inserting the control into Excel? If you haven't modified _any_
lines of code, the control isn't marked as "Insertable" and won't show up in
the "Insert Object" dialog box.
>The error message in Excel was :
> The exception Illegal Instruction
> An attempt was made to excute an illegal instruction.
> (0xc000001d) occurred in the application at location
>0x0012f1d0.
>
>The hex codes are identical for any OCX I have been able to
>generate.
I can't reproduce this problem... though I _am_ told by Excel that the
control couldn't be inserted. Are you running on Intel machines?
.B ekiM
--
TCHAR szDisc[] = _T("These words are my own; I do not speak for Microsoft.");
Randal Parsons -- Randal.Parsons@btal.com.au
Tuesday, February 20, 1996
mikeblas@interserv.com wrote:
> How are you inserting the control into Excel? If you haven't modified _any_
> lines of code, the control isn't marked as "Insertable" and won't show up in
> the "Insert Object" dialog box.
Actually, you can make the control insertable when you create it
using AppWizard. Thats what I did and I inserted it using "Insert
Object".
> I can't reproduce this problem... though I _am_ told by Excel that the
> control couldn't be inserted. Are you running on Intel machines?
>
I'm running a Pentium 133, with NT 3.51 Service Pack 2, and VC++4.0
with vcpatch1.exe applied to it.
I posted this same message to Compuserve and was told not to bother
using Excel or Word as containers since everyone knew they were
flakey. I was told if I wanted to work with Excel, then I should
stick to plain OLE Automation. I tryed Excel 7.0 later, and found
that although the program didn't crash, the behaviour was _very_
unstable. Even the Calendar control provided by Microsoft didn't
behave itself properly.
Regards,
Randal Parsons.
Mike Blaszczak -- mikeblas@interserv.com
Tuesday, February 20, 1996
On Tue, 20 Feb 1996, Randal Parsons wrote:
>Actually, you can make the control insertable when you create it
>using AppWizard. Thats what I did and I inserted it using "Insert
>Object".
Indeed, you can. I forgot this was finally added to the ControlWizard.
>I'm running a Pentium 133, with NT 3.51 Service Pack 2, and VC++4.0
>with vcpatch1.exe applied to it.
That's interesting--I don't have the service pack (so I'm running Win NT 3.51
build 1057 flat) and I don't have VCPATCH1.EXE.
>I posted this same message to Compuserve and was told not to bother
>using Excel or Word as containers since everyone knew they were
>flakey. I was told if I wanted to work with Excel, then I should
>stick to plain OLE Automation. I tryed Excel 7.0 later, and found
>that although the program didn't crash, the behaviour was _very_
>unstable. Even the Calendar control provided by Microsoft didn't
>behave itself properly.
This is reasonable advice. I was under the impression, though, that Excel had
cleaned themselves up for hosting OLE COntrols. Excel used to crash right
out of the gate when someone asked it for a DISPID with a negative
index--which OLE controls like to do when they want to find out about
ambient properties from their contaner.
I'll have to ask the Excel folks what's going on.
.B ekiM
--
TCHAR szDisc[] = _T("These words are my own; I do not speak for Microsoft.");
Randal Parsons -- Randal.Parsons@btal.com.au
Friday, February 23, 1996
mikeblas@interserv.com wrote:
> That's interesting--I don't have the service pack (so I'm running Win NT 3.51
> build 1057 flat) and I don't have VCPATCH1.EXE.
Apparently service pack 3 is now out and VCPATCH2.exe is now available from Mircosoft's web page.
> This is reasonable advice. I was under the impression, though, that Excel had
> cleaned themselves up for hosting OLE COntrols. Excel used to crash right
> out of the gate when someone asked it for a DISPID with a negative
> index--which OLE controls like to do when they want to find out about
> ambient properties from their contaner.
>
> I'll have to ask the Excel folks what's going on.
>
The sort of flakey behaviour I was talking about included :
- Once the Calendar control lost the focus, its behaviour was forever modified. It was no longer possible to
select a day for example.
- When my control lost the focus, it was redrawn as if seen through a powerful magnifying glass. I suspect
that this was my fault (since it didn't happen to the MS control), except that my control behaves itself in the
Test Container provided. The scaling returned to normal if I stretched my control.
Other Issues :
The Calendar control that comes with MS Office 95 has its property page dialog activated from a
right-mouse-button menu, but selecting the properties for mine didn't work.
When the Calendar Control is inserted, it size is ~ 5 columns * 4 (or 5) rows. When my control is activated, it
starts at that size and immediately shrinks to ~1.5 columns * 2 rows. This is the same size that it would be if
created in the Test Container and is equivalent to the "default" control behaviour. Is there something I can do
to make it a certain size on creation? I haven't managed to find anything in the MFC code that suggests a
solution.
Thanks for following this up.
Regards,
Randal Parsons.
| Вернуться в корень Архива
|