Coding

Just a quick one: Anyone out there that needs to embed Microsoft Office into their application somehow can do so using a sample OCX available from Microsoft called DSO Framer (KB311765) as a starting point. The sample does everything you need it to out of the box, but the biggest trick is to make sure you're closing each office instantiation cleanly.

It also allows you to play with disabling menus, toggling read-only, and redirecting other functions, and can be quite powerful. At the time of writing, it still works for the up-coming Office 2010, but I would recommend you avoid embedding office in future unless you're unable to argue the point with your managers. While it works with Office 2007, it's a bit flakey, so I suspect Microsoft will ditch it at some point, but you can always download it here (468KiB ZIP).

Importantly, it's free. Do not spend your money on Edraw Office Viewer as it's the same thing, only with renamed symbols and a hefty price tag! Go for the public domain version.

I'm sick of fixing other people's code. I love the open-source community for all of the free and high-quality software that's out there. I've even contributed my own little bits and pieces, mostly in the form of patches, here and there.

What I hate about the open-source movement are the egos. The problem is that the people who started a project end up actually belittling the project because of their own arrogance. Suggest something, or even provide a patch, and these particular people will tell you that your idea is wrong, that you don't know what you're doing, and so forth. On the other hand, they may never respond. I can understand this to a certain extent; I work in IT, and we're all control-freaks at some level.

Over the next year or so, I'm going to start rewriting my blog from the ground up, because this is ultimately the only way I can get the performance and feature-set I want without hacking at someone else's system. This also means my little DVD collection database will be frozen and remain incomplete until I rewrite that part too.

People don't seem to realise that computer programming is an artistic discipline rather than procedural office work. Those outside of the field would probably scoff at that remark, after they've put together a pivot table within excel. Just because you can cook doesn't make you a chef.

Your average manager fails to understand the difference between someone within an artistic job and someone with a procedural job — the difference being that to accomplish their goal one designs and constructs while the other follows list of tasks. Just because you're a mechanic doesn't make you an automotive engineer.

Just under a month ago, we completed an upgrade of our Axapta 3.0 SP5 KR3 system to Dynamics AX 4.0 SP1. For those who don't know, Microsoft Dynamics AX is the new name for Microsoft Business Solutions Axapta.

During the upgrade, we ran into many problems, so I thought I'd write up the highlights so others in the same position could benefit. I don't seek to condemn the product, in fact I think the product in general is very good, however I believe this information should be available to help others out. All of these problems have been presented to Microsoft, at least a month ago, and I've also provided my solutions where applicable.

I like Serendipity for blogging, and have no intention to move to WordPress despite constant nagging from fellow bloggers.

The great thing about Serendipity is the ease at which new plug-ins can be created. While their plugin API documentation looks like it's lacking substance, it makes sense once you get going and realise the blanks are fairly obvious.

On Monday, Mr. Brewer mentioned something about my Axapta posts looking messy and that they could probably benefit from a little thing called GeSHi. Having never heard of this before, I set out and asked the oracle what this was.

After finding this funky little toy, I set my heart on writing a tiny plug-in for Serendipity, but David Rolston beat me to it.

Our company was the first to use the European Commission's VIES system via SOAP to validate VAT numbers automatically. We used to have a custom hack to perform this operation within Axapta 3.0, waiting for what was then a rumour that Dynamics Ax 4.0 would be able to call .NET assemblies via CLR interoperability.

In my previous article, I touched on calling code within Ax from C#, but now I want to explain how this works the other way around.

I'm currently in the process of migrating our Axapta 3.0 system over to Dynamics Ax 4.0. This is a difficult process due to the number of customisations we have made in the system, and many changes between the two standard code-beds. In light of this, we've been conscious of new developments on the horizon, so some of our customisations had temporary snippets of code in them, waiting for enhancements such as .NET interoperability.

One of these temporary snippets of code is responsible for monitoring recurring batch job execution, and ultimately the use of a monitoring system completely outside of Dynamics Ax is preferable. This is where the .NET Business Connector steps in, and since a small number of licenses come with the base Dynamics Ax product, it can be a really useful development tool. Most of what's written here will also apply to the old COM Connector, in principle.

It seems that calling Windows API functions from Axapta is viewed as some sort of mysterious magic by most Axapta developers. Unfortunately, there are times when you need to do something that requires tight integration with functionality that exists outside of the system. While there are other methods of interfacing between bits of code, including COM, XML-RPC, or even .NET, using the Windows API can sometimes be very efficient, and powerful.

For beginner WinAPI coders who are also Axapta programmers, with at least some programming experience in C or C++, I felt it might be better to answer a question from my colleagues about calling WinAPI calls from Axapta, outside of those already wrapped by the WinAPI:: or WinGDI:: classes.

Axapta inherently begs community involvement from X++ developers due to its horrible lack of documentation. Dynamics Ax 4.0 (the erp system formerly known as..) certainly solves this to great lengths, but there are still grey-areas here and there which need to be filled in.

I often get asked about tips and tricks in Axapta, and today I was asked (again) about the nofetch keyword in X++ select statements. Why is it there? What's the point?