1129 Oleinitiate: Initiate Failed Error

Keywords:     1129 Oleinitiate: Initiate Failed

---

Question:

I have created a DLL in both Visual FoxPro 5.0 and Visual Basic 5.0. When testing the object in WinBatch32, the object creation keeps failing with the message:

	1129 Oleinitiate: Initiate Failed

	Obj=ObjectOpen("WSERVER.APPCTRL")

	WinBatch 32 96M

	WIL Version: 2.3mbn

The object can be initialized and its methods executed from either of those applications - only WinBatch is having a problem. Any ideas?

Answer:

Seems vaguely ok, can you give me the VB line of code that opens the object. Basically we look it up in the registry to figure out what program to run. Some registry entry might be either incorrect of of some type we do not understand.

Sometimes RUNning the application involved first, before trying to open the object helps as less registry entries have to be 100% correct.

Question (thread continued):

I am not sure why you want the VB line that opens the object when I am trying to open it from Winbatch. When testing, it is easier to open the object from Visual FoxPro:

	joe = createobject("WSERVER.APPCTRL")
	frank = joe.GetAppToRun()

* this works.

Opening the object in VB is a little different:

	Private Sub Form_Load()
	' AppCtrl is the class in the WSERVER DLL
        Set oWserver = New AppCtrl

        End Sub

        Private Sub Command1_Click()
        MsgBox oWserver.GetAppToRun(), vbOKOnly, "WSERVER"
        End Sub

        Private Sub Form_Unload(Cancel As Integer)
        Set oWserver = Nothing
        End Sub

What do you mean exactly by RUNning the application first to see if that will help the object creation?

Answer:

Try:

        xxx=ObjectOpen("APPCTRL")

We don't generally need to know *where* the object is defined (exe or dll) as the registry takes care of that for us.

Not knowing what WSERVER.APPCTRL is I dont know what to do with it. Seeing it used in running code helps me understand its nature. It looks from the VB code that the WSERVER part was throwing us off.

Re..Running an EXE. Some objects are defined in EXE files, and sometimes have bad registry entries making it difficult to find, but if the application is already running it steps in during the ObjectOpen process and says "Hey I can handle that sort of object") and bypasses a few registry lookup operations.

Question (thread continued):

It still won't initiate. Could it be because it is of the ActiveX flavor (whatever OLE version that is) rather than OLE 2.0?

Answer:

Hmmm. Maybe. I kind of do not think so. If VB can open it as you posted earlier, we ought to be able to open it at least. Errors would come later.

I'm not sure what is wrong. I still strongly suspect invalid registry entries or an improperly setup CLSID.

Resolution:

I set up the VFP OLE as an out-of-process server. I ran it from my WinBatch script and then was indeed able to perform the ObjectOpen successfully! So it does look like some kind of registry problem. I unregistered and re-registered the DLL, but ObjectOpen still would not work unless I performed a RUN first.

We tested OLE creation under VB 4.0 and the WinBatch script opened its object without a hitch. It seems the way the 5.0 platforms must register objects differently than in 4.0.

---

Article ID:   W12940

Filename:   1129 OLE Initiate Failed Error.txt