It seems to me that the biggest issue with the RE API is that it is not really ready for the .NET framework as a whole whatever language you use, you have to jump through hoops to make it work the way you expect and even then it chews you up and spits you out for being a nice .NET developer simply because you talk C or some other .NET pre dated technology.

Between you and me, the problem is that updating the API doesn’t make money, and that’s all that Blackbaud are interested in, if someone could “sell the monetary advantages of .NET” to Blackbaud they would likely jump on it in an instant !!!

I guess the other way to look at it is that the sort of customer base they have know of no other strong competitor at the moment that can deliver this type of thing effectively for a reasonable price so they have their little market cornered so to speak, introduce some competition and this whole issue could simply go away as a gimmick sold to developers in order to keep the administration and maintenance teams on side.

It’s likely just a matter of time as I see it, these things ultimately always are

Specifically referring to the RE API however, I think that VB does have an easier time. RE was written in a different era. There was no such thing as .NET when probably 95% of the API was written and as such they could not have foreseen where the technology would take the industry. COM technology was the big thing of the time and as such as long as the API worked with a COM language that was fine.

Given that, even though VB.NET was rewritten, much of the syntax remains, it is obvious that VB.NET is going to be better suited to what was primarily intended to be used with VB6. The optional parameters is a good example.

The example of collections is an interesting case. You are right this is nothing like the .NET syntax but then why should it be. This was not written for .NET. It is closer to the VB6 Collections class but even then it is more “advanced”.

// ok this seems reasonable
CRecord aRecord = new CRecord();
aRecord.Load(recId);
// here we go … what the …
aRecord.Attributes.Add();

as a tried and tested programmer when i add something to a collection i give it the object I plan to add like this …

aRecord.Attributes.Add(anAttribute);

…

Turns out anything complex with attributes requires a whole separate server instance that you have to do everything on.

Copying an object is another prime example …

If i have 2 CRecord instances and i want to do something like this …

// assume these are initialised
CRecord rec1;
CRecord rec2;
// rec2 is a duplicate so i want to copy everything and delete
rec1.Addresses += rec2.Addresses
//BOOM !!! … no chance

even though this object looks like and seemingly appears to be a collection it’s got literally nothing in common with a typical .NET collection object.

The API just appears out dated to me … maybe i’m just being over critical … it is a huge lengthy code monster after all.

But then i could ask …
why ?
does it need to be ?
if it used some standards would it still be ?

It’s interesting how technically “Blackbaud does not support anything done with the API just simply the API itself”.

thats like saying …

I’ll sell you this car but if you drive it you will no longer be able to get insurance on it.

… Eh ?!?!?

For example the use of the keyword “with” has been left out of C# deliberately because it was deemed to promote poor readability in code however me being a C# programmer myself like the the idea as with any language feature i believe it may be that Microsoft decided that this was being abused thus came the reasoning for it’s being left out.

With that said in C# 4.0 you can do this …

Var someObject = constit.get_Fields(ERECORDSFields.RECORDS_fld_FIRST_NAME);

Apparently the “implicit casting” is supposed to happen but this to me is muddying the nice type safe coding that C# programmers are used to and will encourage bad programming practices as it means u end up treating everyhting like some generic object but call the specific implementation methods on it … evil …

I’ve also noticed how when you get an instance of the main API class that you can call it with “optional parameters” something that does not exist in C# so you have to figure out a way around it, it turns out you can do it with reflection but this is typical of many API providers, they only think of the language they are using and not the fact that by releasing this as a universal API others might want to use it too.

The point is that I think VB has always been the language of choice for Blackbaud and thus everything will appear nice and fluffy in VB, the fact of the matter is that VB is just not a “clean, standards promoting language” by todays standards within the industry, C# is clearly a superior language.

It’s a bit of a sweeping statement i know but think about the origins of VB … didn’t it used to be a “training language” back before .NET … most serious programmers moved in to the C style languages which is where I believe the profesional solutions of today should live.

Points 4 and 5 are classic examples of this coupled with my point on simply initialising the API.

Despite not even being thought of in the development of the API I as a C# developer have the knowledge to go round a few extra miles and get there, something that would never happen in the VB world, simply because the language allows too many short cuts.

Or maybe i’m wrong?