Monthly Archives: September 2023

I want row automation id’s on my XamDataGrid…

As part of work I’m doing at the moment, building a UI automation API for our testers. I continually come across issues around data grid controls and access the rows within it (we’re primarily using XamDataGrids from Infragistics).

What I need is to have an AutomationId reflecting some form of index in the grid. Good news is we can do this…

If we take a XamaDataGrid and create a style such as this

<Style x:Key="RowPresenterStyle" TargetType="igDP:DataRecordPresenter">
  <Setter Property="AutomationProperties.AutomationId" Value="{Binding DataItemIndex}" />
</Style>

and now in the XamDataGrid’s FieldLayoutSettings we can apply this style using

<igDP:XamaDataGrid.FieldLayoutSettings>
  <igDP:FieldLayoutSettings
     <!-- Other settings -->
     DataRecordPresenterStyle="{StaticResource RowPresenterStyle}" />
</igDP:XamaDataGrid.FieldLayoutSettings>

Primary Constructors are coming in C# 12 to classes and structs

Available as part of Visual Studio 17.6 preview 2. C# will be adding primary constructors.

Primary constructors already exist (as such) for records, but can be added to classes and structs, so the syntax

public class Person(string firstName, string lastName, int age);

will be equivalent to 

public class Person
{
   private readonly string firstName;
   private readonly string lastName;
   private readonly int age;

   public Person(string firstName, string lastName, int age)
   {
      this.firstName = firstName;
      this.lastName = lastName;
      this.age = age;
   }
}

By using a primary constructor the compiler will no longer generate a default (parameterless) constructor. You can ofcourse add your own but you’ll then need to call the primary constructor, for example

class Person(string firstName, string lastName, int age)
{
   public Person() :
      this("", "", 0)
   {
   }
}

An obvious syntactic difference between a class/struct primary constructor and a record’s is the record parameters are public, so we would tend to use property (Pascal Case) naming conventions and the properties are exposed as public readonly properties. For the class/struct these parameters map to private fields hence we use camel Case (if following the standards).

Note, you cannot access them using this.firstName. This statement might seem slightly confusing because whilst you cannot, for example, write the following

public Person() : 
   this("", "", 0)
{
   // this will not even compile
   this.firstName = "Test";
   // also will not compile
   firstName = "Test";
}

You can do things like the following

class Person(string firstName, string lastName, int age)
{
    public string FirstName
    {
        get => firstName;
        set => firstName = value;
    }

    public override string ToString() => $"{firstName} {lastName} {age}";
}

Essentially your primary constructor parameters are not available in overloaded constructors or using the this. syntax.

Trying out bun

You can never get too complacent with the JavaScript eco-system, no sooner do you start to feel comfortable than something else becomes the new hotness, this time it’s bun. Bun is a JavaScript runtime, pretty much analogous to Node.js, so basically a potential replacement for Node.js.

Setting things up

The Installation page gives details on setting up for various OS’s, Windows is not well supported at the moment (i.e. experimental release), but as I love devcontainers in VSCode, we’ll just set up a devcontainer to use the docker image.

  • Create a folder for your (yes we’re going to do it) hello world app, mine’s named hello-world
  • Create folder named .devcontainer (for more info. see my post Visual Code with vscontainers)
  • Create a file in .devcontainer named devcontainer.json and put the following code in it 
    {
  "image": "oven/bun",
  "forwardPorts": [3000]
}

Now open Visual Code on the folder hello-world (or whatever you named it) and VS Code will hopefully ask if you want to open the folder as a devcontainer, obviously say yes and it’ll set up the docker image for you and then you’ll be working in a devcontainer with bun.

Is it working?

If you carried the steps above (or installed by one of the other means) we now want to check bun is working. From your terminal either on the devcontainer or any terminal if you installed it on your machine or container, run the command

bun

You should see a list of commands etc. If not, check through your installation and in the case of the devcontainer make sure you’re using the terminal in VS Code and it’s showing your root folder of the docker image.

Getting Started

Hopefully everything is running, so we need to create something, so run

bun init

Then fill in the options, mine are using all the defaults, but I’ll then them below anyway

  • package name hello-world
  • entry point index.ts

and that’s all there’s is so it. Bun will create and index.ts file, .gitignore, tsconfig.json, package.json and READEME.md. The index.ts looks like this

console.log("Hello via Bun!");

Let’s run this using 

bun run index.ts

As you’d expect we’re seeing Hello via Bun! in our terminal window.

I want a server!

Most, if not all my work with Node.js was writing server based code, so let’s take the example from the Bun Quick Start page and fire up a little server app.

const server = Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello World from the server");
  },
});

console.log(`Listening on http://localhost:${server.port} ...`);

We’re using port 3000 which we also have listed in our devcontainer.json within forwardPorts. So running index.ts from bun will start the server on port 3000 and VS Code (in my case) will ask if I wish to open the browser for that port. If you’re using a different method then simply open your browser with URL http://localhost:3000/.

We can ofcourse put scripts into our package.json, to save us some typing, for example adding

"scripts": {
    "start": "bun run index.ts"
  },

Now we can use the command

bun run start

Everything else should pretty much work as Node.js, but it’s reported that bun (which essentially also includes package management tooling) is quite a bit faster than npm and yarn, also it includes hot reload out of the box, i.e. we don’t need to use Nodemon. It automatically transpiles TypeScript and JSX. So it’s very much an “all in one” solution to Node.js style development.

So that’s a really quick run through and a reminder to myself how to get bun up and running as quickly as possible.