Getting Started with C#

Of course to follow along you’ll need to download and install VS for macOS

Once you have it you can easily start a new “solution”
This is MS’ term for what might roughly be the equivalent of a Xojo project (although its a bit more than that) But for now “Xojo project” is close enough.

Select “New”

Select Mac app in the left hand pane send select “Cocoa app” and make sure the language elector is set to C# (you can use others supported by C# but I’m going to focus on C#)

Press Continue

Give your project a name – I used getting_started

Note that in this pane you can select which version of macOS you want to deploy backwards to. Leave it set to macOS 10.14 for now.

Since we’re going to use a different overall framework we arent interested in a document based app either.

Press Continue

Note that GIT integration is built right into the IDE.

Save the project in whatever location you like.

Press Create and Visual Studio will do its thing to create everything needed.

Once it has you should see a screen something like the following.

Now if you wanted you could write a traditional macOS app in C# using the entire macOS framework (which oddly enough MS has done a decent job documenting)

However, the whole point of this tutorial is to use an alternate more “Xojo like framework”

Visual Studio has a nice package management system called nuget built right in. This makes it easy to add in various “libraries” other authors have made available and keep your version up to date as the author updates their code.

Lets add the package from Einhugur

Right click on the top item in the left hand “navigator”

You should get a menu like the following

Select Manage Nuget Packages

You’ll see a dialog that has a very long list of packages that are available to be added to projects. There are packages for dealing with AWS, JSON, Azure, Unit Testing, Redis, REST API’s, and tons of other things.

Fortunately there’s a search field to help us narrow down the item list to the one we’re looking for.

In the search field type in Einhugur

Check the checkbox next to the package and press the Add Package button in the lower right

You’ll get asked what “project” to add the package to. Since we only have one project in this solution the dialog offers to add it to that one. Press the OK button and the package will be added.

ABOUT C# and VS

A “solution” can have many projects in it so it can make sharing code between the different project in the solution really simple, You can have a desktop app, a web app, a mobile app (iOS and Android) all in the same “solution”.

And now we’re ready to start altering the default code we were initially given when we created the solution.

In C# you have to tell the compiler what other bits of any project your going to use. You do this with a “Using” directive. In Xojo everything is global so you rarely have to do this. In C# using .Net the range of libraries is so vast its a requirement. And because there are often several different implementations for something like JSON you have to say which one you’re using – you could use several in different parts of your project (although you might regret that)

In VS, unlike in Xojo, each item in the left hand pane is a “file” a single file on disk. And VS is, for all intents and purposes a text editor for those files (albeit a very smart one).

When you double click an item in its left hand navigator it will open a tab with that item in the tab – the entire item.

What we want to start editing is the AppDelegate.cs file
Double click it to open it.

Since we’re going to make this application a Einhugur Forms one we’ll need to add the using clause
using Einhugur.Forms;

right below
using AppKit;
using Foundation;

As well since we’re not using macOS classes directly we’ll change the code for the class to

namespace getting_started
{
	[Register ("AppDelegate")]
	public class App : Application
        {
	   public App ()
		{
		}

           static void Main(string[] args)
           {
              Application.Init(typeof(App), args);
           }
    }
}

While all this looks daunting its not so hard in reality

namespace getting_started defines a namespace that all our project code can be in. Unlike Xojo “modules” a namespace in C# can span multiple files.

[Register (“AppDelegate”)] tells the C# compiler the following code implements the “AppDelegate” protocol. Its much like an interface.

public class App : Application declares the class App as a subclass of Application. In Xojo you’d set the super property.

public App () declares the CONSTRUCTOR for the App class. You can have several that vary by their signatures. Our code in this case doesnt need to do anything hence the empty { } that follows it.

static void Main(string[] args) declares the MAIN ENTRY POINT for the application. This is the FIRST code that will be run when this application starts up (even before the App constructor) This code basically calls the constructor of App and all that instance to initialize.

Thats it for code we need to write.

We do need to remove one file from the project since it servers the same purpose as the Main method we just added.

Right click on Main.cs and remove it from the project.

And now you can click “Run”

Heres my copy of the project as it sits now

Adventures in C#

Yeah after all these years I’ve started writing some code in C#

Mostly as a way to work in something else
But also as a way to learn another language that I _might_ end up needing to use for client work. Thats a whole different story.

So I started just using a framework put together by Björn Eiríksson

Any first it was just learning how to write code, add event handlers, and generally just getting used to how this all worked, C# syntax (some very handy things there) and poking about.

For all this I’ve been using Visual Studio for macOS.
Not VSCode – which is a VERY different product – but MS Visual Studio Preview for macOS.

Its not as capable as VS for Windows – but its not bad and has evolved a lot since I first started poking around with it.

I’ll try & post my adventures with it here.
And probably also on INN

Switching

I’m happy to se Xojo has decided that maintaining bug base software is not the business we are in
However, the issues that many people have complained about are not JUST about the tool

Some have characterized their feelings about Xojo as Expected behavior working is not Xojo’s strength

And thats not the result of what tool is used to track bug reports or api proposals

That is is a lack of process in how they do what they do. A rigorous process for making sure what goes out the door works as specified would reduce surprises when betas go out to users.
But I don’t believe they have such a thing.
Sure they changed from Feedback to Issues to have abetter tool for tracking whats in each release. Great !
All that does it give you better tracking of changes.
It doesnt mean that when you make changes you have done rigorous testing of those changes and QA before it gets to users

Was a unit test created that exposes the bug?
And JUST that bug ?
Then the bug fixed and now the unit test passes ?

And do those unit tests get run on every check in so regressions are found & fixed long before they get to an alpha build, never mind a beta ?

Trust me I realize that UI testing this way is tougher to automate.
But its necessary to automate what you can (hello AppleScript & Accessibility !)
And where you cant make darned sure you try & test everything that could be affected.
And if you say it works on Xojo Cloud make sure that is tested too !
Don’t just assume that because it works on my desktop it will work there too !

Issues might be a great tool but it alone is not likely to be the answer to better quality releases

Numbers after the change

Xojo recently shifted way from Feedback, their home grown bug tracker, to Issues from GitLab. As part of this they’ve added a number of bots that seem to automatically deal with cases.

Comparisons to my old #’s are difficult because Issues tracks multiple tags per case where Feedback basically had a single status

There are some easy comparisons

In Feedback I had 58 Archived cases, several of which I requested be reopened,
In issues there are 99, with several I’ve asked to be reopened.
Archived is a label I’d like to see tossed out as it is, at least in my experience, a label that just plainly says “Thanks for the report we just don’t care to look at this.”

In Feedback I had had 433 Open cases.
As of today in Issues there are 117.
When I look at my closed cases I see a lot that have been updated recently. But I just don’t have the energy to review all the lines closed in the last 2 weeks. I see some marked as duplicates of other cases.

Beyond that its hard to do direct comparisons.

One thing Issues makes possible is that it is possible to quickly search for all kinds of labels

Like, bugs, archived, not marked fixed, by design, implemented, not actionable or not reproducible

Such a query shows, as I write, 4148 of these

Labelled Bug, reproducible and archived a paltry 11

Or reported by other users

Numbers 2022-05

Current count of my cases in Feedback

Archived 58
Closed (already Exists) 12
Closed (by Design) 49
Closed (Duplicate) 55
Closed (Misc) 37
Closed (No Longer Reproducible) 5
Closed (Not Actionable) 9
Closed (Not Reproducible) 48
Fixed 9
Fixed & Verified 133 (broken down as)
       Build 2
       Compiler 1
       Crashes & assertions 5
       Database Plugins 1
       Debugger 1
       Documentation 37
       Examples 2
       Framework – All 16
       Framework – Web 4
       Framework – Windows 2
       Framework – macOS 4
       IDE – Auto Complete 6
       IDE – Build Automation 2
       IDE – Code Editor 5
       IDE – Constant Editor 1
       IDE – Debugger 1
       IDE – Enum Editor 1
       Ide – Errors & Warning Panel 2
       IDE – FileIO 3
       IDE – Inspector 10
       IDE – Language Reference 1
       IDE – Layout Editor 4
       IDE – Library 1
       IDE – Menu Editor 1
       IDE – Miscellaneous 6
       IDE – Navigator 1
       IDE – Refactoring Tools 1
       IDE -Scripting 1
       IDE – UI 3
       IDE – UI – Menus 1
       IDE – UI – Tabs 1
       N/A 6
       XojoScript 1
Implemented 5
Implemented & Verified 16
Open 433
Resolved 2

XojoScript

An interesting question posed on TOF

is there any way to inject code into a control’s events at runtime?
Or, is there a way to create a function or sub procedure and create its methods, parameters, and insert code at runtime?

The consensus is, to alter compiled code – no. Which I agree with.

The suggestion was to investigate Xojoscript – which I also agree with.

And with careful planning and configuration you CAN make controls that can actually have their “event handlers” altered at runtime.

Here’s a very rudimentary sample that might spark some imagination & use

SVG for Xojo

There are a few Xojo coded SVG handlers

Most do a minimal level of SVG abut dont handle lots of extra fancy bits. Like proper clip path handling, defs with later uses sections, rotation, scaling, gradient fills and several others.

I’ve been lucky enough to get my hands on a VERY VERY VERY early test version of an SVG plugin.

I posted a movie of it in action on INN

Your most infuriating bug report ?

Mine is easy to list. A serious noticeable regression in the debugger.

http://feedback.xojo.com/case/59520
The debugger simply doesnt work as expected and the more I work the more infuriated I get that this bug has existed for over 2 years now

Voting for it hasnt gotten it fixed. And there are other similar bugs that seem related (like step not behaving a expected (http://feedback.xojo.com/case/68263)

Whats YOUR most important bug report for Xojo to fix ?
Bug – not feature request

Numbers 2022

Since the last numbers post Xojo has moved a lot of cases to an”archived” status which I believe is a lot like “we’re not spending time on this unless you say its still relevant”. As well they removed several “open” statuses like Reviewed.

Direct comparisons to my last numbers post are more difficult with these changes. As well its hard to get a list of which Archived cases I have asked to be reopened as they are still happening and that I still experience.

archived 61
closed (already exists) 10
closed (by design) 49
closed (duplicate) 54
closed (misc) 36
closed (no longer reproducible) 5
closed (not actionable) 7
closed (not reproducible) 48
fixed 18
fixed & verified 118
implemented 3
implemented & verified 16
open 425
resolved 2

In total theres been a little movement in the intervening 5 months but not a lot