Microsoft CRM 2011, hide system Save menu

Recently we were asked if it is possible to disable a standard 'Save' menu of Microsoft CRM 2011, since all data on forms is read-only anyway. So, after some searching I've found sample code how to do this. The key was to use "top" property which is containing parent frame which is necessary, since our code (called in "OnLoad" form event) is executing in inner frame. With some modifications this is what finally worked out for me:

var disableSaveMenu = function() {
    // your entities names
    var entities = ["account", "contact" /* add as necessary */];

    var i;
    for(i = 0; i < entities.length; i++) {
        var ent = entities[i];
        var save = top.document.getElementById(ent + "|NoRelationship|Form|Mscrm.Form." + ent + ".MainTab.Save");
        if(save != null) {
            save.style.display = 'none';
            break;
        }
    }
    
    // hide 'File' menu, additional 'Save' is also located there
    var jewel = top.document.getElementById("jewelcontainer");
    if(jewel != null) {
        jewel.style.display = 'none';
    }
};

Microsoft CRM 2011, automatically load all subgrids

Microsoft CRM 2011 doesn't load by default data in all of the subgrids if they count exceed 4, displaying 'To load ... records, click here' message. It's actually extremely annoying.

It's not possible to change this behaviour with standard tools (i.e. via control preferences). So I've found how to do it using JavaScript function call on form OnLoad event. Unfortunatelly it did't worked in my case. For some reason the moment then OnLoad event was fired, the from subgrids were, apparently, not initialized on the form. I've decided then to call the function with a little delay:

var autoLoadSubgrids = function() {
    var maxAuto = 4;
    var loadDelay = 1000;

    var subgrids = Xrm.Page.ui.controls.get(function (control, index) {
        return control.getControlType() == "subgrid";
    });
    
    if (subgrids.length > maxAuto) {
        var subCall = function() {
            var i;
            for (i = maxAuto; i < subgrids.length; i++) {
                var grid = subgrids[i];
                if(grid != null) {
                    grid.refresh();
                }
            }
        };

        window.setTimeout(subCall, loadDelay);
    }
};

And it worked! Not the solution I would like, but I guess that's all I can do now and it also would'n do any harm if something goes wrong.

XNA the end

This entry at Promit Roy's blog finally confirmes that any last hope of XNA should be left. This is, probably, better than nothing, however it was almost obvious with release of Windows 8 SDK with DirectX merged into it. Yet they gained some little respect at least from that point. This is, probably, the only point from which respect can be given.

First they they should say that earlier. Second, they should not drop XNA at all. Despite some negative aspects XNA was extremly intuitive and easy to work with. It was a huge success, enormous attention from developers of wide range of expecience, from novice to professionals. Terraria was written in XNA, a 1.5+ million sells title. They don't need even to add support for WinRT. Just a mere bugfixing, support and Visual Studio 2012 integration.

Enough rant. The question is, should you continue to use XNA? It, of course, depends. If you amateur or just started to learn game programming, it doesn't really matter, you can safely continue to write your first games. However, you can try to port your game to MonoGame to be ready for Windows 8. Last option is also to consider for writing your first more or less serious game, which, most probably you want it to evolve and live in future. Professionals can decide for thenselves I guess, but I guess XNA is no longer a valid option for pro game development.

WiX, worst toolset ever

So, I suppose sooner or later every developer out there will face the task of writing a installer for his product. I you are working under Windows, Windows Installer seems like a reasonable choice. I'm not so sure about it now.

Now, there is no some sort official tool from Microsoft for making Windows Installer packages. Huh? Seems like that. Presumably I didn't dig enough for that, so far I found just this nonsence.

But then, WiX! Which is infamous for being used to create Microsoft Office 2003 installer. And it's also internal Microsoft product as well. Certanly it's a big YES compared to nothing. It's even integrates into Visual Studio and adds custom projects for creating installers. And you actually start to think that will be a nice journey. But then you try to find some tutorials, examples and documentation. It is awful, all of these. If you add (but I suppose, it's the reason in the first place) that WiX markup is extremenly unintuitive, complicated and confusing then you will understand that frustration means. Contrary to what you might expect, WiX Toolset it's a pretty low-level tool, which must be backed with good documentation and comprehensive and complete examples.

The feedback is thru this mailing-list style forum with horrible desing. The leading toolset man Rob Mensching is rich for caustic comments like this. And, as you can guess from a thread, WiX Toolset is OK with bugs that lasts for more than 2 years.

The thing that finally really, really helped me out was WiX: A Developer's Guide to Windows Installer XML book. And I'm not sure how much more time I would spend in misery without it.

So for me it's official, WiX Toolset is teh worst tool I've ever encountered in all my developer experience so far. It doesn't mean however you shouldn't use it, but unless you are ought to use Windows Installer, you can consider some other tools out there.

P.S. Useful tips on MSI.

Fixing XBLIG (and Windows Phone) forum links

As usual, working with an elephant finesse, Microsoft, for some obvious reasons decided to split Windows Phone and XBLIG forums. This results in incredible amount of links on the web are being broken. Oh, this is so nice.. The good part however is that, you can replace old forums.create.msdn.com/forums with xboxforums.create.msdn.com/forums in address and make it to the desired topic.

As for unfortunate ones who were looking for some topics for Windows Phone, the things here are much simplier: all topics are lost somethere, or just gone, I don't actually know.

Back to XBLIG. If you are using Firefox, you can use Redirector add-on, as described here. Just in case, I'll duplicate the rules here. Goto add-on options and add two rules:

Rule 1
Example URL: http://forums.create.msdn.com/forums/p/0001/0001.aspx
Include Pattern: http://forums.create.msdn.com/forums/*/*/*
Redirect to: http://xboxforums.create.msdn.com/forums/$1/$2/$3
Pattern Type: Wildcard

Rule 2
Example URL: http://forums.create.msdn.com/forums/t/0001.aspx
Include Pattern: http://forums.create.msdn.com/forums/*/*
Redirect to: http://xboxforums.create.msdn.com/forums/$1/$2
Pattern Type: Wildcard

WPF: Final

So here it comes, Windows 8. This discussion on StackOverflow provides some really good answer about all-new WinRT platform from Microsoft employee. BTW seems like this fellow is definetely monitors and answers most of winrt tagged questions on StackOverflow, this is so nice of Microsoft.

So, what is the answer to question "Is WPF is dead?". The answer is both yes and no. In fact the whole .NET system is left behind. In the UI design aspect we that while you are still can use XAML you, in fact using all new WinRT libraries which are available not only to .NET, but to C++ and JavaScript. You can name WinRT as a "Native .NET". So WPF is dead for WinRT. Yet Microsoft did very good job in saving your XAML experience in WPF, so you can use it in WinRT via "replace namespace" method. Also WPF and .NET is still there, and will be for a very long time, but I don't think this is as good investment as it was three years ago, then Microsoft pushed WPF as their primary API for UI.

Resume. Microsoft made .NET second time, this time in native languages. This results in all Windows 8 cool features we have seen, such as very low memory usage and blazingly fast speed. WPF and .NET just couldn't make it, even using DirectX, so Microsoft falled back to native apps. To me, as developer, this is actually a good thing, since we get a "Win32 Reloaded" platfrom which have all (or most of) RAD stuff which makes .NET so popular.

P.S. Related video.

Previous post on subject.

Python Tools for Visual Studio 2010

There is an incredible product available to all of us. Not only it's extremely nice to have Python language in VS, but to me no less important that it's also open source. There is a lot of open source code, but I think this one is specifically valuable since it covers a lot of aspects of VS integration at all levels, and it's from Microsoft.

P.S. some videos on features.

WPF "strikes back"

As a funny coincidence next day after my post about death, or more correctly, halt of WPF development, I've received another mail from a Microsoft mailing list. There was an article in Windows development section named Автоматизация стоматологического кресла в WPF (which is something like "Automation dentist chair using WPF" in English). I was thinking "Whoa! That was unexpeted!", but real fun was after clicking a link: a 2 month old article at CodeProject, that a clever move! While maintaning, for show, some articles about WPF, Microsoft isolates itself from it, so they can say afterwards: look, it wasn't even our guy article! Nice move, but one more proof of big instability and uncertainty around WPF.

P.S. check out CodeProject — it's a great place to learn and share code.

Previous post on subject. Next post on subject.

Is WPF is going to it's end?

Most propably it will in a some way. There most probably, I would say is about good 80%, and some way, is "will be left as is, and will not be promoted in any way". The rumors, strong rumors, for this are floating for about a year as of now. And Microsoft is holding a silence for too long on that matter.

Some individual responses by Rob Relyea are trying to deny this, but look at Rob Relyea current position: Program Manager on Kinect for Windows Team. And then Past: * Program Manager/Architect on WPF/XAML (2001-2011). Suddenly after 10 years on WPF/XAML he is in some quite other role.

Look at the official WPF team blog. Silence since November, 2010. That's not how actively developed product blog looks like. The last big boom (and only?) about WPF was about porting Visual Studio 2010 UI to WPF, this was end of year 2009.

Nowadays, Microsoft talks all about HTML5 and JavaSript, much more than about WPF, which is quite suspicious by itself: Microsoft will stand ground puching it's own technology, if possible. One of last WPF PDC videos (7:00 AM, no audience, no questions, and horrible quality of recording) is just "beating about the bush". It's not what you expect from technology vNext presentation. Watching this video, I can just say that next version of WPF is Silverlight. WPF will be left as a host, engine, core, whatever you like, to support existing infrastructure around WPF. Future development will be forced to move to Silverlight, and there is a reason — to push and boost Windows Phone 7 applications.

The most intriguing question about all that, is, why is this happening? I think this sitiation have many aspects, this is that this comes to mind:

• WPF wasn't that successful enough to crown it as main platform for Windows UI. There was a quite of a negative experience with WPF, Evernote 3.5 is popular example. Speed and memory of course is a major factor if you want to put all OS graphics on that, Windows is not that fast by it's own, that to think about WPF?
• Windows Phone  7+ lobby. If you force developers to use Silverlight, then you have all desktop developers that are able to write GUI and apps for Windows Phone.
• Microsoft wants to get it all with all those HTML[5] and JavaScript developers. If you can write windows apps in Ajax, then Microsoft doubles (at least) number of developers for it's main platform.

This note is rather confused, yet I hope it will provide you with some food for thought.

Next post on subject.