Tuesday, September 23, 2008

Hiding the Save/Close button in Microsoft CRM 4.0

UPDATE: Check if the button is on the form.

I've been doing a lot of work with Microsoft CRM 4.0 recently. One simple thing I wanted to do was to remove the "Save Close" button from a CRM window.

You can achieve this via Customizations in CRM (under Settings) and override the OnLoad JavaScript event for the form and use the following JavaScript:
if (document.all._MBcrmFormSaveAndClose != undefined)  
{
document.all._MBcrmFormSaveAndClose.style.display='none';
}
That’s it, job done.

Note you need to check if the button is on the form as users without Write permission will not have a button hence without the check, the javascript will fail.

I'll be posting more complex stuff on Microsoft CRM in the future...

Handling Resize of Form on SIP event in the Compact Framework

I have learned (a while back) that the bug (I think pre CF 2.0 SP2) when showing or hiding the SIP didn’t send the WM_RESIZE message to the form has been fixed.

Usually you would typically derive from a base form which derived from Form. In this class you would handle the SIP EnabledChanged event and resize the tab control or another other control that wasn’t using any type of anchoring/docking.
You would normally have coded something like this:
private void sip_EnabledChanged(object sender, EventArgs e)
{
Resize();
}

private void Resize()
{
try
{
if (Visible)
{
foreach (Control ctl in Controls)
{
if (ctl.GetType() == typeof(TabControl))
{
//Set the height of the tab control.
Rectangle rect;
rect = this.ClientRectangle;
ctl.Height = rect.Height + 2 * 96 /
CurrentAutoScaleDimentions.Width;
ctl.Width = rect.Width;
}
}
}
}
catch { }
}
The above is still relevant if you are targeting CF 1.0. However you might want to extend the Resize method to support other controls in CF 1.0 as CF 1.0 has no support for Anchoring or docking.

Note the use of property CurrentAutoScaleDimensions.Width - this gives us access to the DPI to which the form is rendered. Quite neat addition back when CF 2.0 was released.

Happy coding :)

Sunday, September 14, 2008

ReSharper 4.1 released

So what's new?? well bug fixes!

See release notes here.

Get it from here.

The complete Windows Mobile memory management resource list

I wrote an article recently regarding memory management on Windows Mobile. After looking at the web logs for my site over the past couple of weeks, I noticed this article has been getting many hits which proves it's a popular topic for Windows Mobile devs.

So I have decided to write this post which is an aggregate post combining all the memory related posts regarding Windows Mobile that I could find.

Starting with my original post:


  1. http://www.simonrhart.com/2008/05/memory-management-on-windows-mobile-61.html


  2. http://www.danielmoth.com/Blog/2005/01/memory-problems-faq.html


  3. http://blogs.msdn.com/ce_base/archive/2006/01/11/511883.aspx


  4. http://blogs.msdn.com/stevenpr/archive/2004/07/26/an-overview-of-the-net-compact-framework-garbage-collector.aspx


  5. http://blogs.msdn.com/stevenpr/archive/2005/12/14/503818.aspx


  6. http://blog.opennetcf.com/ctacke/2006/06/30/MEDC2006CFMemoryManagementPresentation.aspx


  7. http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032318791&CountryCode=US

There you have it, probably the most up to date aggregate Windows Mobile memory article to date! :)


Sunday, September 07, 2008

Detecting whether you're running on smartphone or Pocket PC

In the old days (before Compact Framework 3.5) detecting whether you're running on PPC or smartphone was done using a method such as this.

This is no longer required as the SystemSettings class has been extended to support a Platform property. So now you can easily distinguish the difference between PPC, smartphone or a generic WinCE device. SystemSettings lives in the Microsoft.WindowsCE.Forms.dll assembly, so you'll need to add a reference to this dll in your project.

The code is very simple and could look like the following:
Microsoft.WindowsCE.Forms.WinCEPlatform platform = 
Microsoft.WindowsCE.Forms.SystemSettings.Platform;

switch (platform)
{
case Microsoft.WindowsCE.Forms.WinCEPlatform.PocketPC:
//Do PPC stuff.
break;
case Microsoft.WindowsCE.Forms.WinCEPlatform.Smartphone:
//Do smartphone stuff.
break;
case Microsoft.WindowsCE.Forms.WinCEPlatform.WinCEGeneric:
//Do WinCE stuff.
break;
}
That's alot cleaner than ugly P/invoke code.