With the API it is very common that you will want to make a change to an object. Say you have some code that adds a pledge to a constituent when an event registrant is added. The user running the code may well have the rights to add an event registrant (participant) but they may not have the rights to add gifts.
Continue reading Checking security
C++ and the API
I am not sure how many people out there would even dream of using C++ together with the API but considering there really is no documentation out there for this type of project I thought that I would try to put together some notes on how it is possible. The API is COM based and there is no reason why you cannot use C++ (just possibly more of a question of why you would ever want to). This posting assumes a basic knowledge of C++.
Firstly why would you every want to use C++. Sometimes this is a necessity. You may be using old C or C++ legacy code that you want to integrate directly with the API. In which case here are a few tips to get you started.
Continue reading C++ and the API
The problem with imports
One common problem that I have had with writing VBA code that hooks on to the import process is debugging. Unlike the other processes that you can write VBA code for the import process is a modal form. This means that the import window has to be on top at all times and you cannot go back to another window in Raiser’s Edge
The problem with this is that you cannot set a break point in your code and you cannot step through the code. This makes debugging code difficult.
There are a couple of work arounds.
Continue reading The problem with imports
A .NET plugin
When I first saw Shaun Sullivan’s code to create a .NET plugin in Raiser’s Edge I was a bit concerned. I tried out the code and after a bit of fiddling with it I managed to get it to work. Although I thought and still think that having an extra HTML page with the plugin as a user control was a bit of a hassle.
A much easier solution that I have done several times is to simply create a .NET class library with a form. When you start your plugin the form is shown directly in a new window.
Close down or crash
One of the basic principles that you need to learn when you start programming the API is that for top level object (constituents, gifts, funds, participants, etc) whenever you initialize the object you need to close it down. This is not too difficult to remember to do and you are swiftly reminded when you close the plug-in or the application (it crashes).
However there are some exceptions to this. When you loop a collection of top level records e.g. CGifts, using the for each construct you also have to close down the individual item. This goes against the above logic as you did not initialize it.
Continue reading Close down or crash
Filtering on Gifts
One common complaint about the API is that it is poorly documented. I found that out myself when I went to use the gift filter object. This is a powerful object that allows you to filter a collection of gifts by its properties. The filter object has very many properties but very few of them are documented. There is one knowledgebase article and one FAQ entry showing how to use it.
Continue reading Filtering on Gifts
Adding Gifts Means Thinking User Options
One issue that I frequency encounter was raised as a post on the forum for a similar problem:
When you create a gift you need to add a fund, campaign and appeal. The problem is that the values on the gifts are dependant on the user options of the person running the code. When I first encountered this problem I was amazed that this could have been programmed in this way.
Continue reading Adding Gifts Means Thinking User Options
The case of the disappearing form
One of my most long standing problems that I have had with RE:VBA is showing a form modally. This in itself is not difficult but as soon as you move away from Raiser’s Edge, bring up another window in front of the modal form and then go back to Raiser’s Edge, the modal form has disappeared. Because the form is modal you are not able to access the underlying window (let’s call this the parent window). This is a pain as the only way to bring it back is to place another window over the parent window and then minimize it. This is not hard to do but it is harder to explain to users and not very intuitive.
Old and New Relationships
The other day I was trawling the knowledgebase for some code to quickly look up the primary organization record for a constituent. It is the sort of thing that I could have worked out myself very easily but sometimes it is just convenient to see if Blackbaud already have the code available.
I found exactly what I was looking for, or so I thought. KB BB54132: How to write code to find the Record ID for the Primary Organization relationship. Seeing the solution reminded me of the time I first took over the reigns of RE customisation developer at my first position in San Francisco.
Six ways to name a record
One thing that can make the API confusing is its inconsistencies. Take for example the task of referencing the constituent object’s system id from another data object. The constituent system ID is used uniformally throughout to connect a constituent to its child objects such as, gifts, actions, aliases, solicit codes, etc. The naming convention however is not uniform. The objects have fields which are referenced in the following format:
OBJECTNAME_fld_FIELDNAME
so that an action references the constituent that is tied to it by the following:
oAction.Fields(ACTION_fld_RECORDS_ID)