C-DLL-VBA connections strings

[Francogrex]

Hello, I'm trying to connect excel to a C dll library (call C dll from
excel through the VBA). It works well for returning integer and double
values (see simple example below), but I can't seem to get it to
return strings (Note that the dll I am making I tested and it works
well elsewhere because when I link it to an exe it is actually
returing a string as expected). I am using MinGW gcc (so basically
only C) to construct my dll, so I don't have access to BSTR and other
cpp like objects/functions... Is there a way to make the C dll return
strings to excel? Thanks

DLL.c
#ifdef BUILD_DLL
#define EXPORT __declspec(dllexport)
#else
#define EXPORT __declspec(dllimport)
#endif
EXPORT int __stdcall add2(int num){
return num + 2;
}

COMPILE mydll.dll
c:\> gcc -c -DBUILD_DLL dll.c
c:\> gcc -shared -o mydll.dll dll.o -Wl,--add-stdcall-alias

IN VBA:
Private Declare Function add2 Lib "c:/mydll" _
(ByVal num As Long) As Long

 

[Ben Bacarisse]

Hello, I'm trying to connect excel to a C dll library (call C dll from
excel through the VBA). It works well for returning integer and double
values (see simple example below), but I can't seem to get it to
return strings (Note that the dll I am making I tested and it works
well elsewhere because when I link it to an exe it is actually
returing a string as expected).

This is not really a C question. It is all about how VB represents
strings. I confirmed this is a search where I found:

http://support.microsoft.com/kb/118643/EN-US/

despite the page name there is an example of returning a string also.

 

[Francogrex]

This is not really a C question.  It is all about how VB represents
strings.  I confirmed this is a search where I found:

http://support.microsoft.com/kb/118643/EN-US/

despite the page name there is an example of returning a string also.

Thanks for the effort but I think I did mention that i'm using MinGW's
gcc. None of those programs compile with gcc even with the right
libraries "vbapi.h". __far __pascal?? what the hell is that?

 

[jacob navia]

Thanks for the effort but I think I did mention that i'm using MinGW's
gcc. None of those programs compile with gcc even with the right
libraries "vbapi.h". __far __pascal?? what the hell is that?

Use another compiler...

mongw doesn't work well under windows, unless you write
very simple console programs...

 

[Keith Thompson]

Use another compiler...

mongw doesn't work well under windows, unless you write
very simple console programs...

My understanding is that mingw can be used to develop native Windows
applications not just console programs. I can't comment on how good
it is because I don't use it. (jacob's statement might be correct;
I'm just providing a bit more information.)

 

[BartC]

My understanding is that mingw can be used to develop native Windows
applications not just console programs. I can't comment on how good
it is because I don't use it. (jacob's statement might be correct;
I'm just providing a bit more information.)

I've just compiled and run Petzold's 'Hello World' for Windows with mingw
(gcc 3.4.5) and it seems to work OK.

 

[jacob navia]

I've just compiled and run Petzold's 'Hello World' for Windows with
mingw (gcc 3.4.5) and it seems to work OK.

Hello world yes. But the problem are the windows header files...
They are kind of old, and not up to date...

 

[Old Wolf]

I am using MinGW gcc so I don't have access to BSTR

BSTR is a typedef for "unsigned short *", so you certainly
do have access to it. BSTRs can be created and manipulated
using basic Windows API functions. This is kind of
off-topic for c.l.c though, one of the Windows programming
newsgroups would be the best place to write.

 

[Ben Bacarisse]

Thanks for the effort but I think I did mention that i'm using MinGW's
gcc. None of those programs compile with gcc even with the right
libraries "vbapi.h". __far __pascal?? what the hell is that?

It specifies things to do with the calling convention. It may not be
required but if it is then you will need to find MinGW's equivalent
(if it has one). You will certainly need to know how to build a VB
string in C so the header file, or at least some of the definitions in
it, will be required (it sounds as if you have that part sorted).

Anyway, this is not really a C question. A VB group is likely to able
to tell you if this can be done with MinGW better than we can.

 

[Nick Keighley]

My understanding is that mingw can be used to develop native Windows
applications not just console programs.  I can't comment on how good
it is because I don't use it.  (jacob's statement might be correct;
I'm just providing a bit more information.)

I've done. It isn't particularly hard

 

[Richard Bos]

Not very subtle, jacob.

My understanding is that mingw can be used to develop native Windows
applications not just console programs. I can't comment on how good
it is because I don't use it. (jacob's statement might be correct;
I'm just providing a bit more information.)

I _have_ used it. In fact, it is my most frequently used compiler. I can
say with all confidence that jacob is expostulating out of his
fundamental orifice.

What you probably _can't_ easily do is link mingw with VB. But then, you
can't easily link TinyC with Turbo Pascal, either, as far as I know. It
really doesn't mean anything about the quality of the systems involved.
What it _does_ mean is that, if you want easy interoperability of
different compilers, get them from the same vendor.

Richard

 

[jacob navia]

Not very subtle, jacob.


I _have_ used it. In fact, it is my most frequently used compiler. I can
say with all confidence that jacob is expostulating out of his
fundamental orifice.

The fact that
printf("%Lg\n",(long double)a);

doesn't work is OK with you of course.

The fact that most windows headers are missing is OK with you too.

> I can
> say with all confidence that jacob is expostulating out of his
> fundamental orifice.
>

This is obviously a good regular.
Insults, polemic, and no brains

[snip crap]

 

[Kenny McCormack]

The fact that
printf("%Lg\n",(long double)a);

doesn't work is OK with you of course.

The fact that most windows headers are missing is OK with you too.

Note to all (not specifically to Jacob): Jacob has a tendency to
exagerate, and the regs never miss a chance to pounce on him for it.

But he is basically right here - the underlying concept being that
trying to develop for Windows using a Unixy compiler is (as I've also
noted in a parallel thread) asking for pain. I've used both Cygwin and
Mingw on several occasions to compile Unix specific code (Cygwin) and/or
what Jacob snidely calls "simple console apps" and both tools do indeed
work well. Both tools are also able to create Windows GUI apps and
nobody seriously thinks otherwise. In fact, I think that the Windows
GVIM (VI like editor) is/can be compiled with Mingw, but the point still
remains that if you are developing specifically for Windows, you should
use a Windows oriented compiler/IDE (such as lcc-win32...).

This is obviously a good regular.
Insults, polemic, and no brains

Well, you've been around for a while - you know what to expect.
You could try at least a little not to give them such easy opportunities.

 

[Nick Keighley]

doesn't seem a major problem

which ones?

Note to all (not specifically to Jacob): Jacob has a tendency to
exagerate, and the regs never miss a chance to pounce on him for it.

But he is basically right here

no he isn't

- the underlying concept being that
trying to develop for Windows using a Unixy compiler is (as I've also
noted in a parallel thread) asking for pain.  

not really. I'm not sure why MingW is a "unix compiler"

I've used both Cygwin and
Mingw on several occasions to compile Unix specific code (Cygwin) and/or
what Jacob snidely calls "simple console apps" and both tools do indeed
work well.  Both tools are also able to create Windows GUI apps and
nobody seriously thinks otherwise.  In fact, I think that the Windows
GVIM (VI like editor) is/can be compiled with Mingw, but the point still
remains that if you are developing specifically for Windows, you should
use a Windows oriented compiler/IDE (such as lcc-win32...).

why?

Oh, and if you do want to use a "windows compiler" also consider
Microsoft's Visual C++ Express. It *is* (or can be made to be)
a C compiler and it's free.

Well, you've been around for a while - you know what to expect.
You could try at least a little not to give them such easy opportunities.

 

[jacob navia]

doesn't seem a major problem

Obvious. It is gcc

When my compiler doesn't emit an error when it sees // comments
using the undocumented ansic89 flag a posting will be done
by the regs indicating a "serious bug".

When gcc doesn't print long doubles that's not very important.

 

[lawrence.jones]

When my compiler doesn't emit an error when it sees // comments
using the undocumented ansic89 flag a posting will be done
by the regs indicating a "serious bug".

Please pay attention, Jacob. There's one (non-"reg") rabble rouser who
periodically posts that nonsense. When he/she does, the "regs" defend
your right to have an undocumented flag do whatever you want it to,
despite the somewhat misleading name. None of us/them have *ever*
called it a bug, let alone a serious one, as long as you don't claim C89
conformance, which you most adamantly do not.

 

[Keith Thompson]

When my compiler doesn't emit an error when it sees // comments
using the undocumented ansic89 flag a posting will be done
by the regs indicating a "serious bug".

[...]

jacob, do you actually *read* this newsgroup?

A single troll calling himself "Tea Pot" has repeatedly complained
about this. The "regs" consistently reply that, since the ansic89
flag is not documented, and since there's no claim that lcc-win
supports C89/C90, it's not a bug, and that even if it were this is
not the place to complain about it.

On this particular point, we have consistently defended you. I,
for one, would appreciate it if you'd pay a bit more attention
and refrain from making unfounded accusations.

 

[Kenny McCormack]

Please pay attention, Jacob. There's one (non-"reg") rabble rouser who
periodically posts that nonsense. When he/she does, the "regs" defend
your right to have an undocumented flag do whatever you want it to,
despite the somewhat misleading name. None of us/them have *ever*
called it a bug, let alone a serious one, as long as you don't claim C89
conformance, which you most adamantly do not.

It is pretty clear that the so-called "rabble rouser" is a Heathfield sock.

Once you realize this, everything you've written above takes on a
different tone.

 

[Keith Thompson]

When my compiler doesn't emit an error when it sees // comments
using the undocumented ansic89 flag a posting will be done
by the regs indicating a "serious bug".

[...]

jacob, do you actually *read* this newsgroup?

A single troll calling himself "Tea Pot" has repeatedly complained
about this. The "regs" consistently reply that, since the ansic89
flag is not documented, and since there's no claim that lcc-win
supports C89/C90, it's not a bug, and that even if it were this is
not the place to complain about it.

On this particular point, we have consistently defended you. I,
for one, would appreciate it if you'd pay a bit more attention
and refrain from making unfounded accusations.

jacob, somehow I'm not surprised that you chose to ignore this.
Disappointed, but not surprised.

 

[Nick Keighley]

I'm sorry, the context was that you claimed it was difficult to write
windows application with MingW. At least two people have said it isn't
as they've done it (including me). What the <expletive> does this have
to do with how long doubles are handled? I don't think I have *ever*
used long doubles they are not essential to windows programming.

You also claimed "The fact that most windows headers are missing is OK
with you too. ". I asked you which ones and you failed to respond. So
which headers are missing?

And I have yet to have it explained to me what "unix compiler is".
If it runs under windows and generates windows binaries and provides
acces to the most common windows libraries then it's a windows'
compiler.

good grief.