Monthly Archives: March 2013

How to get the PHP current information

I’ve on many occasions in past worked with PHP and upon starting this blog realised I’d forgotten almost everything I ever knew about the language/technology. So I’m going to add a few PHP items as and when I have to look them up or remember them.

The first is the phpinfo() method. Simply place this method into a .php file in the following way

<? phpinfo(); ?>

and when this file placed on your web site, simply load the page in your web browser to see loads of PHP information for your webserver/configuration, such as any php.ini file path…

Talking of the which. I was having problems with this blog (assuming I’m still using a PHP based blog when you read this) when it was on godaddy. Iwas getting various timeouts when loading pages. So using the previous code I can check where the php.ini file is located (if indeed there is one) and either edit (or replace it with a file) with the following lines

max_execution_time = 360     ; Maximum execution time of each script, in seconds

Note: the php.ini might have a version number such as php5.ini, obviously this is the file name that should be used to replace the file, add a new one or to be edited.

Oh and this blog is no longer on godaddy due to it being horrendously slow.

32-bit/64-bit incompatibility fun

So, I’m working on a C#/.NET application which currently uses a 32-bit version of TIBCO RV. The company I’m working for is (slowly) moving from Windows XP over to Windows 7 (and the brave new world of 64-bit computing). However they’re obviously wanting to test their suite of in-house application and ensure they’re all run correctly on the 64-bit machines.

I’ve been tasked with ensuring our application works. Ofcourse immediately we hit a problem which was the use of the 32-bit TIBCO RV. The application, by default, was built with the “Any CPU” configuration. The way the JIT works is that it will JIT compile “Any CPU” code to the architecture of the CPU, so on a 32-bit OS it’s 32-bit and on a 64-bit OS it’s run as a 64-bit application – which is how it obviously should be.

But with the inclusion of the 32-bit DLL and the JIT switching the application to 64-bit obviously caused a bit of a problem and we were seeing the “System.BadImageFormatException” exception when the application attempted to load the 32-bit DLL. Ofcourse this is to be expected as you can’t mix 64-bit and 32-bit in the same application.

Apart from the obvious solution of getting a 64-bit version of TIBCO RV installed (which is ultimately where we’d hope to end up). How do we solve this problem now?

So the key to solving this is the “Any CPU” configuration. If we create an x86 configuration we can force the JIT to build for a 32-bit architecture and x64 will force the code to 64-bit.

Now here I made a subtle mistake which I’m going to share with you. I created a new configuration whereby all projects were switched to “x86” I compiled the application without a hitch and deployed it, only to find it still failing. Part of the problem was I didn’t have a 64-bit machine to run on, so this was a rather slow process of building, deploying and testing :)

To cut a long story short (too late I know). I eventually got some time on a 64-bit machine. I rebuilt the client on this machine in “x86” mode and strangely (unlike building it on the 32-bit machine) I got loads of errors. Seemingly incompatible assemblies all pointing to a bunch of third party UI assemblies (which I assume are built as Any CPU) – now I’ve not confirmed this yet but I wondered at this point whether the problem is to do with some of my assemblies configured as x86 and others as Any CPU. That’s something I need to look into.

Anyway further investigation brought to my attention the following application

corflags /32bit+

I used this on the EXE only and ran the application an it worked perfectly.

Switching back to Visual Studio I changed only the EXE’s project to build x86 code. I recompiled the solution and had no incompatibilities during the build. Then I ran the application and all worked perfectly.

So it appears just setting the entry point (in this case the EXE) to x86 solved the problem, seemingly forcing the application into 32-bit mode.

Debugger Attributes

DebuggerDisplayAttribute

One attribute that I find very useful, but for some reason I always forget what it’s called, is the DebuggerDisplayAttribute. This allows us to display a field or combination of fields within the debugger window, for example when we move the mouse over a variable whilst stepping through code. Instead of just seeing the type name we can display something possibly more meaningful.

[DebuggerDisplay("Name: {FullName}, Role: {OrganisationRole}")]
public class User
{
   // ...
   public string FullName { get; set; }
   public string OrganisationRole { get; set; }
}

The above will now display something like

Name: John Smith, Role: Team Lead

in the debugger.

DebuggerStepThroughAttribute

Even with my poor memory, this is one I remember well as I use it quite a lot.

When in debug mode stepping through code often we end up stepping into properties or other code which maybe makes no sense to step through. Either the code is simple, like a getter simply returning a value or make it’s boiler plate code for calling a webservice.

Using the DebuggerStepThroughAttribute (as below) we can tell the debugger to basically step-over the code contained within the property or method.

public string this[string key]
{
   [DebuggerStepThrough]
   get { return parameters[key]; }
}

CallerMemberNameAttribute

Once very cool feature of .NET 4.5 which passed me by until now is the CallerMemberNameAttribute. Whilst using Reactive UI on a project I accidentally started using an overload of RaiseAndSetIfChanged without the first param being of the form x=> x.PropertyName. Yet the application compiled and seemed to work fine.When I realised my mistake I took a look at the source for ReactiveUI and noticed the use of the [CallerMemberName] attribute on the last argument of the method.

Have a read of the CallerMemberNameAttribute documentation for further info. But basically you can have a string as an optional param with the CallerMemberNameAttribute declaration preceding it and the called method can now find the name of the method that called it. Plus other attributes in CallerFilePathAttribute and CallerLineNumberAttribute which the called method can even get the file path of he source and line number of the where the method was called from. See Caller Information for more.

This is very useful (as shown by it’s use in ReactiveUI) as instead of passing a string from a property for an OnPropertyChanged event with the possibility of typos etc. we can instead let the compiler services handle this using the CallerMemberNameAttribute

public string MyProperty
{
   get { return myProperty; }
   set
   {
      if(myPropery != value)
      {
         myProperty = value;
         //OnPropertyChanged("MyProperty"); -- Replaced
         OnPropertyChanged();
      }
   }
}

private void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
   // raise a property changed even or whatever with the propertyName string
}

WPF Composite Control

Over the years I’ve implemented this code in Delphi, C++ and C# with WinForms. I finally had reason to implement it again, but now in WPF. There were a few interesting issues to solve, so I’ve listed them below.

1. I wanted a simple EllipseTextBox control. A textbox with associated “…” button. The XAML for this is simple enough (I’ve excluded all the UserControl namespaces etc.).

<Grid>
   <Grid.ColumnDefinitions>
      <ColumnDefinition Width="*" />
      <ColumnDefinition Width="Auto" />
   </Grid.ColumnDefinitions>
   <TextBox Grid.Column="0" />
   <Button Grid.Column="1" Content="..." />
</Grid>

Whilst this produces a Button next to a TextBox I obviously needed to add code behind to allow me to bind to the Button Command and TextBox Text properties.

2. So in the code behind I needed to write a few lines of code, but as the TextBox already has a Text property and the Button a Command property, I wanted to set up the relevant DependencyProperty to pass the Text and Command through to the TextBox and Button. To do this I added the following.

public partial class EllipseTextBox : UserControl
{
	public static readonly DependencyProperty TextProperty = TextBox.TextProperty.AddOwner(typeof (EllipseTextBox));
	public static readonly DependencyProperty CommandProperty = ButtonBase.CommandProperty.AddOwner(typeof (EllipseTextBox));

	public EllipseTextBox()
	{
		InitializeComponent();
	}

	public string Text
	{
		get { return (string)GetValue(TextProperty); }
		set { SetValue(TextProperty, value); }
	}

	public ICommand Command
	{
		get { return (ICommand)GetValue(CommandProperty); }
		set { SetValue(CommandProperty, value); }
	}
}

Great so now we can have a TextBox and Button displayed along with the code to pass the Command and Text properties through to the Button and TextBox, but this is of little use of the Command is not hooked up directly to the Button in the UserControl and likewise the Text property on the TextBox. So next step is to wire the XAML to the code behind.

3. Thankfully this isn’t difficult (although it’s rather verbose). So if we update the original XAML replacing the TextBox and Button code with the following

<TextBox Grid.Column="0" Text="{Binding Text, RelativeSource={RelativeSource FindAncestor, AncestorType=ControlLibrary:EllipseTextBox, AncestorLevel=1}}" />
<Button Grid.Column="1" Content="..." Width="{Binding ActualHeight, RelativeSource={RelativeSource Self}}" Command="{Binding Command, RelativeSource={RelativeSource FindAncestor, AncestorType=ControlLibrary:EllipseTextBox, AncestorLevel=1}}"/>

Note: Another nice little trick while implementing this was that I wanted the Button to be square – so I’ve got the Button Width binding to the ActualHeight of the Button. Well I thought it was nice :)