WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

Error Codes

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

1129 Oleinitiate: Initiate Failed Error

Keywords:     1129 Oleinitiate: Initiate Failed

Question:

I get the 1129 OLE Initiate Failed - error on *ONE* machine when I try to use
GMUI   = ObjectCreate("gmw.ui")
What should be my troubleshooting strategy?(It works fine on all other machines)

Answer:

First step would be to make sure the COM Automation object represented by the progid "gmw.ui" is registered on the system. If you have the WIL Type Viewer available on the problematic machine, use it to see if the progid shows up on the progid tab. If not, you would need to do a registry search with regedit or a WIL script. If the progid is present, you would also need to make sure that the DLL or exe for the object is also present and in the location indicated in the registry. The location can be found in the InprocServer32 key under the classid key for the object. The classid is the braces enclosed, dash delimited hex number found in the CLSID key under the "gmw.ui" progid key in the registry.

Most likely cause is the DLL or exe that implements the object has gone missing or is in the wrong location. The brute force solution may be to simply (or not so simply) reinstall or re-register the COM Automation object.


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 or of some type WinBatch does 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
File Created: 2014:05:29:09:14:46
Last Updated: 2014:05:29:09:14:46