Thursday 30 April 2015

No Comment….

So Mr Salopian… How are things going with this ‘No Comment’ policy. Well, says I (looking to the sky and wishing on the long dead bones of Darwin that I actually believed in some higher being) good and bad. I’m not really struggling myself with the concept but I DO struggle with legacy code that is unclear in its intent. Yes, You find me still still battling with the demons of Dicom and converting our Leadtools v14.5 application to the latest and greatest version and in the process coming across some…. challenges. I’m not going to bitch about the parentage of the person who wrote the code or suggest that they should be prevented from accessing a computer ever again or anything like that. The truth is, I worked closely with the guy for about ten years and we had a great working relationship with a lot of mutual respect. We could both rely on each other in a jam and could step in and out of each others code without scratching heads too much.

However, even the best of us somehow take things for granted sometimes. Who’d think that 7 years down the line someone would want to understand or refactor ‘THAT’ piece of code! So I came across the following fairly innocuous lines of code:-

For full blog click here.

Written by Conrad Rowlands, Lead Developer and Team Leader, DSCallards


Solution Wide Compiler Directives

Continuing with my legacy migration of an application developed using Leadtools Medical Suite v14 to utilise Leadtools Medical suite v19 I blogged a few days ago about how I was attacking it using Conditional syntax dependant upon the library I was compiling against. My primary reason for doing this is that if I have issues with regard to the codebase I can easily revert to testing against the previous codebase using EXACTLY the same code and thus eliminate new issues from pre-existing ones. There are several ways that compiler directives can be utilised none of which entirely suit my needs and I thought I would share how I addressed this issue with y’all.

Click here for full blog.

Written by Conrad Rowlands, Lead Developer and Team Leader, Developer Solutions


Tuesday 28 April 2015

Conditional Love

Continuing with my work on converting a legacy application from Leadtools Medical v14.5 to Leadtools Medical Suite v 19 I came across the following annoyance which I felt compelled to share. One of the issues with moving a fairly complex and large application from one series of libraries to another just how you go about breaking things. Any fool can rush in deleting reams and reams of code and replacing the old libraries with the new libraries and then writing thousands of lines of new code only to find that the intent of the application is now not right and it is no longer functioning as was intended. Yes, user testing will pick this up but user testing is to make sure a product is ready for release, and NOT an extension of development.Unit testing will pick up some issues but in general the bugs will be many fold and extremely subtle, especially in already complex software. The key to migrating a functioning LOB application from one library set to another is thus breaking things slowly and in a controlled manner (much as I love the ‘Move Fast and Break things’ approach of Facebook which is fine and dandy if you are the client and accept the risks, generally they dont!).

Click here for full blog.

Written by Conrad Rowlands, Lead Developer and Team Leader, Developer Solutions

We Want Information (DICOM Information)

And so continuing with updating our legacy leadtools application from v14.5 to v19 of the Medical Suite I came across something which had me scratching my head for a little while and I thought as it did I would like to share it with the community so that others hopefully don’t have the same issue.

The issue I was having was related to loading a trying to Insert a module (and the related attributes) into a dataset. For some reason it just would not work. I then stepped back and compared my legacy code with the new code and came across the following anomaly. The InformationClass was not set in my new code. Odd….I was expecting to see it as a type CTImage. I then retraced my code and noticed that the newer libraries did not have the equivalent GetInfoDS method which seemingly loaded this information. So I dug and dug looking to see if a more object orientated approach had been taken to this population but all of my searches drew a blank. I suspected that I had arrived at the answer but the solution still eluded me.

Click here for full blog.

Written by Conrad Rowlands, Principal Developer and Team Leader, Developer Solutions

Thursday 23 April 2015

Embedding LEADTOOLS License Files

I have my colleague Jamie to thank for this particular blog. I have recently come to migrate a legacy project written using Leadtools v14.5 to v19 of the Medical Imaging Suite and so during a conversation with Jamie he showed me a nice way of embedding the Leadtools licence and developer key within the .NET application. I’m sure it’s not going to bring about world peace or halt global warning but it might stop you prematurely looking like the guy above without the aid of a CT scanner. In all seriousness its just a nice tidy way of handling the licensing, So with out further ado:-

Click here for full blog.

Written by Conrad Rowlands, Principal Developer and Team Leader, DSCallards

It's All Just Words!

Whilst migrating an existing framework version 2 application to version 4.5 of the .NET framework i came up against the following mixture of words for an error message that to be honest made me just blank over at the descriptiveness of it all.

Click here to read full blog.

Written by Conrad Rowlands, Principal Developer and Team Leader, DSCallards

Who Knew ...

Who knew that windows contained two registries, I suppose that this should have been dead obvious given the appalling way Microsoft lurch from 16 bit to 32 bit and thence to 64 bit. I just hope I’m not around when they decide to migrate to 128 bit operating systems. I’m sure they’ll manage to come up with some amazingly non obvious name akin to SysWow64 (seriously, who did that!?) that surely serves merely to confuse. I digress…

Anyway yes, so two registries, I had to install an old piece of software that moaned about the minimum requirement of MDAC 2.6 not being installed and instead this windows 8.1 box only had MDAC 2.0.0. I scratched my head as looking in ‘the registry’ i could plainly see that MDAC version 6.3 was installed! Surely this should suffice?! But then something came over me, it may have been the temperature, it was hot for England nearly into double figures, it may have been the romance of spring playing on my mind or more likely I just got desperate:- Registries…..

It turns out that on my machine the default registry is the 64 bit registry, as loaded from C:\Windows. There is also it turns out after a quick 10 second search another regedit.exe (not found by the windows search algorithms) located within the folder C:\Windows\SysWow64, this is of course the 32 bit registry which is where i found my MDAC version v2.0.0. I was now able to change the MDAC version from 2.0.0 to 6.3 allowing my install to complete. I hope that this can be of help to someone, failing that, i got to vent. We all win.

Written by Conrad Rowlands, Principal Developer and Team Leader, DSCallards