Home |
Search |
Today's Posts |
#13
Posted to microsoft.public.excel,microsoft.public.excel.programming
|
|||
|
|||
Excel and the Math Coprocessor for DLLs
On 4/2/2012 7:33 PM, joeu2004 wrote:
"Lynn McGuire" wrote: TestDLL.dll is created using my testdll.c code and the Open Watcom C compiler and linker. Okay. My mistake. There is a difference(!) when calling InitTestDLL from XL2003 VBA v. XL2010 VBA. And I misinterpreted the results from XL2003 VBA. When InitTestDLL is called from XL2003 VBA, the last MsgBox displayed by checkMathCoprocessorStatus says "was 0x127f" and "is now 0x127f" the first time. But subsequent times, it says "was 0x137f" and "is now 0x137f". That led me to conclude that your DLL is changing the FPU control word in some way completely unrelated to the code we see in your testdll.c. But when InitTestDLL is called from XL2010 VBA, we see "was 0x137f" and "is now 0x137f" for the first call and for all subsequent calls. That is consistent with the code in your testdll.c Ergo, the change that I see with XL2003 VBA is probably due to VBA, not your code. (Although I had used XL2003 for my initial test of your code, I had switched to XL2010 unconsciously for my subsequent testing. Mea culpa!) Based on Martin's assumption that your version of _control87 is displaying the actual FPU control word, 0x127f corresponds to _PC_53 + _RC_NEAR, and 0x137f corresponds to _PC_64 + _RC_NEAR. That would indeed explain the results that we observe with your testdll.dll, namely: chptst is zero the first time, but about 2.85E-10 subsequent times when using XL2003. But when using XL2010, you see about 2.85E-10 consistently. As Martin and I have said repeatedly, the remedy is for you to call _control87(_PC53 + _RC_NEAR, _MCW_PC + _MCW_RC) at the __beginning__ of InitTestDLL. (Technically, _RC_NEAR and _MCW_RC are not needed since it appears that _RC_NEAR is already set. But it is good "defensive programming" to set both modes.) Alternatively, as I explained previously, you can call a DLL routine directly from the VBA procedure CommandButton1_Click. The DLL routine would call _control87(_PC53 + _RCNEAR, _MCW_PC + _MCW_RC). That would obviate the need to call _control87 from each DLL routine that you might call from CommandButton1_Click. But you would need to call that DLL routine from every VBA procedure that you initiate, either with an Excel "button" or by calling a VBA function from an Excel formula. So arguably, it is more reliable to call _control87 (or a DLL routine) from each entry point that allow to be called from VBA. I have tried this already when y'all first suggested it. But I will try it again tomorrow in case I screwed it up (totally possible !). I also have a new theory that passing two character strings to my DLL in the argument list are causing problems. I intend to try that out also. Thanks, Lynn |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Excel is messing with the math coprocessor | Excel Programming | |||
VSTO updating excel dlls | Excel Programming | |||
How are excel function names in dlls/xlas resolved ? | Excel Programming | |||
Referencing .Net DLLs | Excel Programming | |||
DLLs | Excel Programming |