Never mind about the "438" error - it was from the command "Application.OLERequestPendingTimeout=0" in my macro which was an attempt to avoid a dialog box telling me that the application isn't responding when the macro takes too long to run. Stephen Taylor seems to indicate you can ignore this dialog and it will go away when the macro completes - we'll see.
On Sun, May 8, 2011 at 12:17 AM, Devon McCormick <[email protected]> wrote: > It's been very frustrating to attempt to replace 2,000 lines of C++ code > with my 100 lines of J when I can hardly get the OLE interface to run the > same way twice in a row. It's tantalizing because it seems to have actually > worked once or twice in the dozens of times I've tried it. However, most of > the time I get errors like this when I attempt to run a macro: > > |domain error: wd > | xlcmd'base run clear_pool' > wd 'qer' > ole - Can't move focus to the control because it is invisible, not enabled, > or of a type that does not accept the focus. : 12 > > Making the spreadsheet visible just changes the error to a "Run time error > '438'", which, according to what I see on the web: > > Run Time Error 438 - Object Doesn't Support this Property or Method > The most common cause of error 438 is not maintaining binary > compatibility<http://www.vbforums.com/showthread.php?t=460591#>between > successive versions of your components. Each COM interface has an > associated GUID that is called an interface ID (IID). Each coclass has an > associated GUID that is called class ID (CLSID). When you compile an ActiveX > component in Visual Basic, the CLSIDs and IIDs are compiled into the > component's type library. > > Example: > A program that consists of a Visual Basic client and an ActiveX DLL is > released to the user community. At a later time, additional functionality is > to be added to the DLL component. The necessary modifications are made, and > the ActiveX DLL is compiled without maintaining binary compatibility. When > the DLL is released, the client that is trying to use the DLL will throw run > time error 438. The reason this occurs is that when the DLL was compiled, a > fresh set of GUIDs was compiled into the DLL, and the client has no > reference to these new GUIDs. This is why it is important to maintain binary > compatibility with the last-released version of the component when you are > trying to release a newer version. > > None of which seems like anything I can do anything about from J. > > Has anyone ever used this to run any non-trivial code in Excel from J? I'm > starting to look at alternatives to J because I just can't make this work > and the error messages are unhelpful and opaque. > > Any ideas would be appreciated, > > Devon > > > -- > Devon McCormick, CFA > ^me^ at acm. > org is my > preferred e-mail > > -- Devon McCormick, CFA ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
