Convert int to enum

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I've posted this before but obviously to the wrong groups, as no-one's got
back... I can't believe I'm venturing into uncharted territory by trying to
use ADO in a Win32 SDK application...

I am having a problem with MIDL producing output that is acceptable to C,
but not to C++ (the generated msado15_h.h file). I want to use the COM
object (ADO) in C++, so I don't really
want to have to go through the ballache of having a separate compilation unit
to export functions from.

Basically, it produces a default argument, by saying
/* [defaultvalue][in] */ SeekEnum SeekOption = 1) = 0;

when '0' isn't an enum - it's an int. It needs 'adSeekFirstEQ' but midl
obviously doesn't think to put that.

Is there any way i can get midl.exe to produce an .h file that is acceptable
to the C++ compiler or am I just going to have to stick to C?

The problem is not with compiling the msado15_i.c file - that compiles fine.
The issue is with compiling anything that includes the msado15_h.h file if it
is .cpp rather than .c
 
Why don't you use the ADO header from the Platform SDK?
No need to process the IDL via MIDL.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: (e-mail address removed)
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
 
I've tried that, but it's msado15.h, not msado15_h.h, and it isn't the same.
I get a load of errors that I've got better things to do than fix, I'd
rather have a .vbs that modifies the midl output to be correct as it doesn't
seem like there's any other viable solution.

Alexander Nickolov said:
Why don't you use the ADO header from the Platform SDK?
No need to process the IDL via MIDL.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: (e-mail address removed)
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

Bonj said:
I've posted this before but obviously to the wrong groups, as no-one's
got
back... I can't believe I'm venturing into uncharted territory by trying
to
use ADO in a Win32 SDK application...

I am having a problem with MIDL producing output that is acceptable to C,
but not to C++ (the generated msado15_h.h file). I want to use the COM
object (ADO) in C++, so I don't really
want to have to go through the ballache of having a separate compilation
unit
to export functions from.

Basically, it produces a default argument, by saying
/* [defaultvalue][in] */ SeekEnum SeekOption = 1) = 0;

when '0' isn't an enum - it's an int. It needs 'adSeekFirstEQ' but midl
obviously doesn't think to put that.

Is there any way i can get midl.exe to produce an .h file that is
acceptable
to the C++ compiler or am I just going to have to stick to C?

The problem is not with compiling the msado15_i.c file - that compiles
fine.
The issue is with compiling anything that includes the msado15_h.h file
if it
is .cpp rather than .c
Click to expand...
Click to expand...
 
Bonj said:
I've tried that, but it's msado15.h, not msado15_h.h, and it isn't the
same. I get a load of errors that I've got better things to do than fix,
I'd rather have a .vbs that modifies the midl output to be correct as it
doesn't seem like there's any other viable solution.
Click to expand...

As I mentioned in another post, I prefer the #import directive, but some
playing around got the following to work. I used some of the COM support
classes because I *hate* dealing directly with BSTR and VARIANT. I didn't
really do all that much testing, but the following (with an appropriate
connection string and query string) retrieved and printed the first column
of the first row in the recordset...

/*
test.cpp, compiles with MSVC.NET...
cl /GX test.cpp /link ole32.lib comsupp.lib
*/

#include <windows.h>
#include <initguid.h>
#include "adoid.h"
#include "msado15.h"
#include <comdef.h>
#include <comutil.h>
#include <string>
#include <iostream>

using namespace std;

struct COM_Init {
COM_Init() { CoInitialize(NULL); }
~COM_Init() { CoUninitialize(); }
} COM_Init_;

static void check_hr(HRESULT hr) {
if (FAILED(hr)) throw hr;
}

template <class T> static void safe_rel(T& t) {
if (!t) return;
t->Release();
t = NULL;
}

void safe_rel_rs(ADORecordset*& rs) {
if (!rs) return;

long s = 0;

if (SUCCEEDED(rs->get_State(&s)))
if (adStateOpen == s)
rs->Close();

safe_rel(rs);
}

static string bstr2stl(const _bstr_t& b) {
const char* c = b.operator const char *();
return c ? c : "";
}

int main(void)
{
ADORecordset* rs = NULL;
ADOFields* flds = NULL;
ADOField* f = NULL;

try {
HRESULT hr = S_OK;

hr = CoCreateInstance(CLSID_CADORecordset, NULL,
CLSCTX_INPROC_SERVER, IID_IADORecordset, (void**)&rs);
check_hr(hr);

_variant_t connect = _bstr_t("Your_Connection_String");
_variant_t source = _bstr_t("Your_SQL_SELECT");
hr = rs->Open(source, connect, adOpenForwardOnly,
adLockReadOnly, -1);
check_hr(hr);

check_hr(rs->get_Fields(&flds));

_variant_t val;
check_hr(flds->get_Item(_variant_t(0L), &f));
check_hr(f->get_Value(&val));
cout << bstr2stl((_bstr_t)val) << endl;
}
catch(HRESULT hr) { cerr << "COM Failure: " << hr << endl; }
catch(...) { cerr << "exception" << endl; }

safe_rel(f);
safe_rel(flds);
safe_rel_rs(rs);

return 0;
}
 
That'd be great, I wouldn't have a problem if I could use the COM support
classes - which aren't included as part of the SDK.
 
Bonj said:
That'd be great, I wouldn't have a problem if I could
use the COM support classes - which aren't included as
part of the SDK.
Click to expand...

Doh! I thought they were part of the SDK.

But regardless, the code is straight COM plus the ado headers, _bstr_t,
_variant_t, and _com_error. All you'd have to do is use the traditional
functions like VariantInit, SysAllocString, et al instead of the helper
classes I used.

Craig
 
Yes, it is you're right, so I might take some of those things into my
project actually, I like the template safe_rel and the check_hr ideas.

Thanks
 
Back
Top