Programmatically Changing a SharePoint Barcode

One of the limitations in the current version of SharePoint is auto-assignment of barcode information when a SPListItem is added to a container, contrary to consuming user input, such as a value from a generic reader to generate the barcode. Honestly, I find it a monster limitation since this situation is the most conventional implementation of Barcode ID strategies.

While by default it will work like this when using ListFormWebPart pages, it is feasible to override this default behavior from your own custom code to generate new barcodes, set to your ID, inclusive of preview and ID association for things like tooltips on hover over.

Firstly, there are some namespaces that people don’t work with very much that have to be used. These are Microsoft.Office.RecordsManagement.PolicyFeatures and Microsoft.Office.RecordsManagement.InformationPolicy. Once you have these references established, since the barcoding is inherent with imaging, it is helpful to set an Image global qualifier to the System.Image namespace as well ala Image=System.Drawing.Image.

Secondly, you actually have to employ the barcode fields themselves. Unfortunatly, the SPBuiltInFieldId enumeration doesn’t have a reference to any of the ID’s that are required which is kind of a bummer since we have to make SPField objects to represent those fields and turn off their readonly properties (SPField.ReadOnlyField). There are three fields that are a concern, the barcode value, the barcode image, and the barcode preview. Once you have those toggled off, the code is unsophisticated to get a new image and associated value. You simply have to use the Barcode.ProvisionBarcodeWithValue() and Barcode.SetBarcodePreview() methods, then call the SPListItem.Update() method, where the fieldValue variable is some arbitrary string representing the new ID.

Image img;
Barcode.ProvisionBarcodeWithValue(item, true, ref fieldValue, out img);

That’s it!


SP Event Recievers Firing 10 Times On Purpose?

I don’t know whether it is, or if it isn’t by design, and I am curious of if this was any sort of business applicability to have the event reciever architecture make you manually disable and enable event firing for certain events. What I am talking about is, if you have a simple event receiver, say something that is doing the manipulation of a list item object name, you have to compensate accordingly in your code, otherwise the event will occur ten times (we are even going to go into system updating so that metadata is enforced, which will be the subject of a separate post) by placing a SPEventReceiverBase.DisableEventFiring Method(), inserting your updating code consuming the properties argument, then terminating with the SPEventReceiverBase.EnableEventFiring Method() method (obviously you don’t have to fully qualify the methods in code since you can just reference the class with the “this” qualifier). This basically just breaks down to disabling event firing temporarily before you execute your custom code, and then once your code is done doing it stuff, you renable event firing.

The code could be as simple as this in your ItemUpdated Method (this isn’t production worthy code, you should place site context references into using constructs otherwise to take advantage of appropriately disposing of objects. Furthermore, it is usually better to just extract a method that is representative of your code, since then it is much easier to wrap and increases the readability of the code):


public override void ItemUpdated(SPItemEventProperties properties)

SPSite oCurSite = new SPSite(“http://h4v0kTeSt”);
SPWeb oCurWeb = oCurSite.RootWeb;
SPList oCurList = oCurWeb.Lists[“testing event receiver”];
SPListItem oCurItem = oCurList.GetItemById(ID);
oCurItem[“Title”] = “adjusted name”;


But this adjusted it ten times (I put a trace listener on it), so if the event receiver was something that was actually doing something that could affect business operations, I would have to wrap my changes with the Disable and Enable event firing code.
So, why is this necessary?

When looking under the hood at some of the programmatic architecture of it, it appears that there is basically filtering of an infinite list before handing the result of the output, therefore there are continuous triggers which occur and trigger the event  receiver in a loop. But, I am unsure where the magical number of 10 comes up, or how it only executes 10 times, since it looks like it should be an infinite number of executions occurring.

I would be interested in more insight regarding it.