VB to VC++

[CiberTHuG]

Okay... I have some questions about MS specific additions to C++ and if there are any equivelants of various VB conventions.

First... the VB code that I'm porting is using On Error. Is there a VC++ equivelant?

Secondly... I'm converting Property Get and Property Let to __declspec( property( put = someX)) int x;. Can I do the following to make the attribute private but keep the get/put method public?

class Sample{
  private:
    int x;
  public:
    __declspec(property(get = GetX, put = SetX)) x;
};

Or do I have to declare x on the __declspec statement?

[parksie]

I would suggest not using __declspec unless you absolutely have to. I prefer to use accessor method's because they're more readable, even though you have to write a little more yourself. That's just my opinion though, because I don't like tying myself down to things.

class Sample{
public:
    inline int GetX() { return m_iX; }
    inline void SetX(int iX) { m_iX = iX; }

private:
    int m_iX;
};

In C++ the standard method of handling errors is with exceptions:

try {
    // Code that might throw an exception
} catch(int e) { // Any type here
    // Act on exception
} catch(...) { // Anything not handled
    // Do a generic death here
}

(or something, not used them for a while)

When using the Win32 API at least, it doesn't usually throw exceptions, but returns an error code from the function and requires you to call GetLastError(). Other functions rely on you passing the correct data in the first place, or they'll just crash rather than provide an error.

[CiberTHuG]

Parksie, I agree with the inline functions, but... I have to maintain compatiblity with the VB version of this DLL. When using __declspec I can use the same name for get and set, and I can use assignment operators instead of function calls.

'Course, now that I think about it... If I have two functions int DoWork(void) and void DoWork(int), and I call DoWork(SomeInt), it is going to use the correct function because it is going to pick the one with the correct number/type of arguments, isn't it?

If not I could just do this:

class Sample{
  private:
    int m_iX;
  public:
    inline int X(int iX) { if iX { m_iX = iX; } else { return m_iX; }}
};

If I remember correctly, it will return m_iX in either case. I don't remember if I have to do something to make the arguement optional.

[CiberTHuG]

Thinking some more... I can't use assignment operators with the code example I just gave, I still have to make function calls.

The VB code orginally had output to logs as well as setting private variables. I've dropped the log routines for now. I guess I will have to add them back. When I do, how can I still use property so I can keep using assignment operators and not function calls?

[parksie]

What is your C++ DLL supposed to be compatible with the VB DLL for? Do you mean by using classes like a Class Module?

I'm afraid it's not as simple as that You have to learn all the painful intricacies of COM just to do this:

Dim x as New CPPObj
x.Prop = 5
x.MyMethod "hello", 65, 0.3

[CiberTHuG]

Well, there is currently a VB app writen and a VB DLL, both home grown. The DLL looks a lot like the WinInet DLL, and calls it. So the home made app calls the home made DLL which in turn calls the WinInet DLL.

But there are blocking problems when trying to use WinInet asynchronously in VB. So they want to rewrite the in-between VB DLL in VC++, and try to keep everything the same in the VB app that will call it.

So I have to port this VB DLL to VC++. The VC++ DLL has to keep the same exposure for the VB app, and has to again call into WinInet.

Why the VB app isn't calling WinInet on its own, I don't know. There is not any work being done by the DLL it calls. It does do a lot of dumping to logs.

Anyway... it isn't my project, I don't ask, I just do the best I can. Like I said, I learned C++ with the GNU compiler. I'm used to using EMACS or Pico. I'm just getting used to Visual Studio, and I don't like it. MicroSoft introduces so many little technologies (DLL, ADO, AFX, MFC, COM, .NET) instead of sticking to a few approaches and making them robust, stable, and capable. For example, why have MFC? No matter how I look at it, it looks so much like a different approach to DLLs and APIs. Why they bothered to create special conventions for that, I don't know. I guess so they could keep selling tech manuals, IDEs, training labs, et al.

I so bad want to land a job working with C++ in a non-MS environment, or better yet, learning Java.

*hops off soap box and trundles off to find food*

[parksie]

That actually doesn't answer the single most important question: is it an ActiveX VB DLL?

[CiberTHuG]

It was.

[parksie]

Then you won't be able to do it like that using C++ classes/properties. You'll have to construct an interface and inherit from IUnknown and all that crap to make it work with COM...not nice :-(.

The easiest way, I expect, is to use the Active Template Library, which really simplifies things like this and doesn't add much bulk (unlike MFC).

[CiberTHuG]

Ohboy, this is not going to work. I am in way over my head. And as I'm getting more and more into this, I'm liking MFC less and less, and I see there are so many MS specific things. Do they just not understand the point behind a standard?

Anyway... Like I said, I'm trying to write this DLL in VC++. Internally, I'm using char * for all my string needs. Some of these functions, however, are going to return strings to VB app that is calling it. If I do char * RetVal; and return RetVal;, am I going to have any problems?

[parksie]

You're not only in over your head, you're in over mine as well I've used COM, but only from ATL because the raw method was totally incomprehensible to me I much prefer CORBA for things like this, it's a lot simpler.

You can't just return a char* variable, because this is only a pointer to a memory location that will be deallocated as soon as the function exits, in most situations. See http://www.parksie.net/StringDLL.zip for a GetWindowText-type method for doing it, which I haven't had any problems with yet.

[CiberTHuG]

Okay, this may not be too bad.

First off, I think that I disagree with you statement about the char * being deallocated as the function closes. With the explicit return, the variable in the program that makes the call should be set to point to the same block of memory. You will now have two pointers. The pointer inside the called function will be deallocated, but because there is still a pointer to that block of memory, it (the block of memory) will not be dealloc'ed.

'Course, all of that is true provided we are in C++. But this is a VB program calling the VC++ function. I don't know if the VB variable will be set equal to the string "ABCD" or to the memory address 0x0001254. VB doesn't support pointers. I also am afraid that the memory block will be dealloc'ed because C++ doesn't regonize the VB variables claim to that memory. Hopefully the data is copied into the VB programs memory space and not just a hex number which will have no meaning to VB.

I hope that makes sense.

Anyway... I looked at the projects you mention. There, the VB app is call the function GetString myString, myLength. I'm looking at preserving the myString = GetString(myLength) format. But that is a side point for now... here is the VC++ DLL function:

char *str = "1234567890123456789012345678901234567890";

void __stdcall GetString(char *pcString, long lLength) {
	strncpy(pcString, str, lLength);
	pcString[lLength] = 0;
}

I notice here that the first argument is being passed by reference, and that is expected. Instead of returning a memory address to VB, it is picking VBs address and altering its memory block.

But that isn't my question... my question is... why is it setting the nth character to zero? Is that providing the null termination for the string?

I'm going to experiment with changing it from a void return to char *. I'll let you know how it goes.

[parksie]

If you this then it definitely won't work:

char* func() {
    char *x = "Hello";
    return x;
}

This works, but is a memory leak:

char* func() {
    char *x = new char[6];
    strcpy(x, "Hello");
    return x;
}

However, you can always do this, which is a method used in the Standard C Library for things like the time functions:

char* func() {
    static char buf[100];
    strcpy(buf, "Hello");
    return buf;
}

That way, the pointed-to string may work until the function is called again, and the content changes. The pointer will be fine, though. I'm not altogether sure how VB handles strings with the API which is why I always used ByVal pcStr As Long and passed a pointer using StrPtr.

[CiberTHuG]

Yes, it didn't work. You get a "memory couldn't be written" error, funny that.

I'm looking over some API calls that I know I've used in VB and that I know are C++/VC++ DLLs and I don't see any that actually return a value other than a long interger. Though VB see them as ByVal calls, I suspect they all do what was done in this example you gave, the VC++ function considers it a by reference situation.

Anyway... until I can find a way to return strings, I will have to force a rewrite of the VB program that is calling this DLL. There has to be a way... I just don't know what it is.

In the orignal VB DLL there were some functions declared like this:

Public Property Get ResponseCode() As Long
    On Error GoTo RaiseError
    LogIt "Get ResponseCode"
    ResponseCode = lngResponseCode
    Exit Property
RaiseError:
    AppError Erl, "Get ResponseCode", Err.Number, Err.Source, _
      Err.Description, Err.HelpFile, Err.HelpContext
End Property

lngResponseCode is meant to be a private member of the class.

I've found a way to do this same sort of property in VC++, I think.

class Inet  
{
private:
    long lngResponseCode;
public:
    __declspec( property( get = ResponseCode )) lngResponseCode;
};

Now, I don't have the explicit error checking or the logging (LogIt) that was in the VB version, but... the doco says this should do the same thing. I will have to try it. Anyway... in the VB code there are some Public Property as String. I guess I can't use char * to emulate that. I guess I have to used fixed length strings (char[n]). That bothers me since I have no idea how long these things will be.

'Course, if I'm forcing the VB app to change its calls from myRespCode = myClass.ResponseCode to myClass.ResponseCode(myRespCode) then I guess it isn't a big to do. I can add all the logging, too.

I just hate having to force the whole project to change just because one DLL is being rewritte in VC++. The only reason we are doing this is because they feel there are blocking problems with using the INet controls asynchronously from VB. They feel that VC++ will be multi-threaded and able to handle this. I don't know anything about adding threading to this. I'm hoping that will take care of itself.

[CiberTHuG]

Oh grumble grumble.

I'm trying to convert that example you provided to a class. It compiles itself, but... VB can't include a reference to it. I went back and created a new project letting VS do as much work as it wanted on its own (__declspec(dllexport) stuff). But I still can't include a reference in VB. How can I get VB to instantiate the class in the VC++ DLL? I suspect that this is really more so a problem with the DLL I created and not VB.

[parksie]

To add a reference you need to use COM, remember?

VB cannot use a C++ class (well, .NET hacks it so that you can do something like that).

[CiberTHuG]

Oh... now I understand what you were saying.

Well, I don't know anything about COM. Guess I'll start with MSDN.