System Error - CoInitialize has not been called

[Dave Navarro]

You're out of the loop on this one Eric, sorry.

Nonetheless, his comment is a valid one. Microsoft has already told you its their problem and you don't want to believe them or us.

--Dave


------------------
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Eric Pearson]

Well, it wouldn't be the first time.

But I did have a reason for posting that... I encountered a very similar problem about a year ago. I was using ODBC API calls, and I kept getting unexpected OLE-related Application Errors during program-shutdown events, when I had never made any OLE API calls at all. After a lot of research it turned out to be, without any doubt whatsoever, a Windows problem.

But it did not involve thunking or VB, so it's not the same problem, so I'll shut up now.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Jeffrey J. Borghoff]

Originally posted by Eric Pearson:
In your own words...

> MS claims that VB is not architected to support thunking.

So you're saying that you don't believe Microsoft or PowerBASIC, who seem to be in agreement that the problem is with VB?

-- Eric

You're out of the loop on this one Eric, sorry.


------------------

[Dave Navarro]

We will continue to offer Direct/32 with PB/DLL because it does work with older versions of Visual Basic and other programming languages.

Errata information concerning this problem in Visual Basic will be included with subsequent releases of the product as well as being posted on our web site.

--Dave


------------------
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Eric Pearson]

In your own words...

> MS claims that VB is not architected to support thunking.

So you're saying that you don't believe Microsoft or PowerBASIC, who seem to be in agreement that the problem is with VB?

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Jeffrey J. Borghoff]

No, I don't believe it's a problem in VB. Will you continue to sell and support Direct32?

------------------

[Dave Navarro]

Jeff,

Whether you choose to "believe it" or not, the problem is in VB and there is *NOTHING* we can do about it.

If you can get them to send me the source code to Visual Basic, I will happily go in and fix it for you. However, until VB is modified you will NOT be able to use Direct/32 as you are attempting to do.

--Dave


------------------
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Jeffrey J. Borghoff]

To support:

Have you been able to fix this problem with Direct32 and VB?

------------------

[Jeffrey J. Borghoff]

You're out of luck on this one. I worked with Microsoft and PowerBASIC for weeks and got nowhere. PowerBASIC claims it's a VB bug, (their big on that) and MS claims that VB is not architected to support thunking. No one wants to take responsibility on this on. Good luck.

------------------

[Andy Stevens]

Sorry forgot to add the main reason for posting.

Has there been any news from Microsoft?

Andy Stevens

[Andy Stevens]

I am also getting this error with the addone sample in the IDE.
VB5 SP3 with Win95B (OSR2).

I too think it maybe a Microsoft problem, I have been getting
strange problems calling 16-bit OLE servers (EXEs) from VB5,
which you are supposed to be able to do. I bought PB/DLL
especially to get round these problems (I need to call some
16-bit dlls from my 32-bit program).

It maybe in Microsoft's OLE layer.

Andy Stevens.

------------------

[Jeffrey J. Borghoff]

Dave Morris, can you send me a screen captures of the VB About Box for the two PC you using VB and Direct32 on.

Or at least the following from the About Box:

VB Service Pack Version, if any (top of box)
VB 6.0 Build number (bottom left of box)
VBA Version (bottom middle of box)
Forms3 Version (bottom right of box)

Thanks,
[email protected]

[David L Morris]

Jeffrey,

My PB 16bit dll, which is loaded with Direct32.dll, was compiled
with PBDLL20 on my home pc which is Win98 and has VB60 with (I think) sp3.

At work I run on WIN95 and VB60 - again (I think) with sp3. The VB60 app
which uses the Direct32.dll and the PB16bit dll was written and compiled
at work. So far I do not have problems when running the compiled VB60 exe.
It is only in the VB60 runtime design environment that I get the error.

I also have PBDLL6 applications which use the same DIRECT32.dll and
PB16bit dll for the same overall application as the VB60 app. These work
without complications.

These applications are part of an on-going evaluation exercise for my
benefit. In the future, we will be moving to WIN2000/NT so the DIRECT32.DLL
concept will NOT be useable. In this case I have some fallback positions:-

1. Use a small 16bit exe to do odbc16 calls to the databases. Run this 16bit
exe from a thread in the PBDLL60 or VB60 32bit app.

2. Have the 32bit apps use a seperate tier process/object for db work.
I can explore ODBC32/OLEDB/ADODB or other APIs

I don't know if this will help, however, the earlier PBDLL1.5 release had a
more extensive direct32 example for use with VB32 code.

Regards

[Jeffrey J. Borghoff]

This posting this for David Lloyd and David L Morris.

I'm trying to see where this "System Error - CoInitialize has not been called" first reared it's ugly head.

1. What version of VB are you using, including Service Pack?
2. What Windows OS are you using, including Service Pack?

Jeff

[Dave Navarro]

Are you using a STATIC or SHARED variable for the handle of the DLL?

--Dave


-------------
PowerBASIC Support
mailto:[email protected][email protected]</A>

Added Note: Please ignore what I wrote below or delete this post. After I made a minor change to my dll, the CoInitialize error returned, and my posted advice is wrong.

The key to avoiding errors when using DIRECT32 seems to be calling the
pb_Load16() and pb_Unload16(hDll) routines from the same subroutine.

I did a lot of experimenting, and I got partial success with various code positions, but it always seems to work without error this way.

I have written a pb_LoadUnload16(iStart) routine that selects its action to load or unload based on whether iStart is set to True.


[This message has been edited by David Lloyd (edited January 13, 2000).]

My CoInitialize error is back, and moving the disconnect routine doesn't fix it this time. The error no longer happens when I disconnect, though. It happens after the last line of the program executes, or when I run an added "END."

I did some searching on "qt_thunk," and I came across an interesting paragraph at www.itecuk.com/delmag/thunk95.htm. It says (page 3) "If an EBP stack frame is not set up, your routine will cause an Access Violation upon exit, as qt_thunk will have scribbled across the calling routine's stack frame."

[David L Morris]

Dave,

Re: I typically put the pb_Unload16 calls in the "unload" event. Where did you put it?

I use a Vb Sub Main and do the pb_Unload16 on exit of the program.

The ETC shown below is only to hide the legitimate connection data.

Sub Main()
    Dim s As Long
    gConnect = "ODBC;dsn=ETC;dbq=ETC;uid=morrisd;pwd=ETC;database=ETC"
    ghDLL = pb_Load16("dmodbc16.dll")
    pfnDTest = pb_GetProc16(ghDLL, "dmSQL32call") ' dmSQL32call does my odbc16.dll stuff
    gSQLCommandFile = App.Path + "\" + "SQLIncmd.txt"
    gSQLResultFile = App.Path + "\" + "result.txt" 'The result is output like a property bag

    Frm_Agnt.Show 1 'vbModal and do all the necessary database SQL stuff

    pb_Unload16 ghDLL
End Sub

[Dave Navarro]

I typically put the pb_Unload16 calls in the "unload" event. Where did you put it?

--Dave


-------------
PowerBASIC Support
mailto:[email protected][email protected]</A>

I have encountered CoInitialize errors that went away without explanation when I moved the call to pb_Unload16 to a different event.

I have also encountered CoInitialize errors that existed when code would run in the environment but would not compile. In my case adding "ByVal" to some parameters allowed the program to compile, and the CoInitialize errors went away. I don't know why.

My superstition blames most unexplained failures on the hard drive, and the rest on the power quality. If all else fails, try your program on another machine.



[This message has been edited by David Lloyd (edited January 05, 2000).]