Any Mah Jong players here?

I’ve been learning the game recently, and became frustrated with scoring it. I therefore ended up making a scoring app (using the rules from http://www.mahjongbritishrules.com) as a “real world” introduction to making a proper Toolbox app.

Would anyone potentially find such an app useful? It’s not really in a “distributable” form yet but I’m prepared to get an allocation and tidy it up if there’s some interest.

Of course. I love Mah-jong :)

Excellent! Hopefully I’ll be able to get a release out sometime next week.

It’ll be good to have an existing player give it a go, as you’ll probably notice if some of the scoring logic isn’t quite right (although I’ve tested it with all of the example hands on the British Rules site).

When I was a student (late 1950s) I played Mah Jongg regularly with three friends. Our scoring rules were not standard. Seeing that the game operates on multiples of four, we inferred the existence of a fourth dragon; the invisible blue dragon. A late friend of mine, Jamal Nasrul Islam, actually got a Thirteen Unique Wonders hand once: One of each of the 4 Winds, one of each of the 3 (visible :) dragons, a 1 and a 9 from each suit, with one of those doubled.

I believe there was a point in China’s recent history when it used Mexican currency and Mah Jongg was its most lucrative export. But times change.

My allocation request has been accepted so I’ll get an initial version online after work :)

Without further ado, download here.

While unfinished, this version should handle all scoring correctly. If you find anything wrong, then let me know. I want to know everything, from “this score is wrong” to “it crashes when I do this” and even “the Style Guide says that this should be 2 pixels to the right”.

Hopefully it’s easy enough to use (after all, it’s easy to be blind to faults in something you’ve made yourself). You can set the number of players and their names from the icon bar menu, and can add scores and advance to the next round from the main window menu. Any usability suggestions appreciated :)

I’ve started work on a feature to let you save your progress and resume at a later date, but I’m not yet sure when it’ll be in the public version.

Enjoy!

Seems to works OK. Thanks!

Good to hear! I have the bulk of the load/save code working now so I just need to finish that off; it needs to save a few more variables and then I need to set up a UI for it – this means I get to learn about more toolbox objects!

Is it coded in C?

It is.

I sometimes asking myself how complicated it is to do Wimp programming in C :)
Anyway, that’s off topic.

I sometimes asking myself how complicated it is to do Wimp programming in C

Much easier than it is in BASIC – and think it’s fair to say that I’ve done enough of both over the years. :-)

It’s my thread so I’m allowed to go off topic :)

I use C# in my day job so C was the natural choice for this project (especially since the Style Guide strongly recommends using C). C# doesn’t have pointers or manual memory management though, so it’s still been a slight challenge, but I’ve got there in the end.

The “notation” for manipulating Wimp elements is a bit different though! In C#, forms (windows) and controls (gadgets) have names and variables. For example, if you have a window called MyForm with a gadget called Message, then you can do something like:

MyForm.Message.Text = "Hello World";

The RISC OS equivalent would be:

displayfield_set_value(0, MyForm, Message, "Hello World");

The underlying concept is similar, but the code is completely different. This was especially confusing when I changed a writable field to a display field and wondered why it stopped working; in C# the code for both would be identical, but in RISC OS had to change writablefield_set_value to displayfield_set_value.

It’s a little more frustrating when you want to use the contents of a gadget, because you can’t just do something like this (grammar aside):

string intro = $"Dear {CustomerName.Text}, thank you for your e-mail.";

Instead, you need to grab the contents of “CustomerName” and put it into a C variable by using writablefield_get_value, and then build up your “intro” string.

There is a minimal “skeleton” on page 202 of the Acorn C/C++ manual, although it needs more events set up before it’s any use. The Toolbox examples included with the DDE were also invaluable.

if you have a window called MyForm with a gadget called Message, then you can do something like [in C#]:

MyForm.Message.Text = "Hello World";

The RISC OS equivalent [in C] would be:

displayfield_set_value(0, MyForm, Message, "Hello World");

The RISC OS BASIC+Basalt equivalent would be:

`MyForm#Message.Value = "Hello World"

you can’t just do something like this (grammar aside):

string intro = $"Dear {CustomerName.Text}, thank you for your e-mail.";

Instead, you need to grab the contents of “CustomerName” and put it into a C variable by using writablefield_get_value, and then build up your “intro” string.

But:

intro$ = "Dear "+`MyForm#CustomerName.Value+", thank you for your e-mail."

[C is] Much easier than it is in BASIC

Is it? ;-)

Very interesting. Thanks.

I still think that BASIC is much simpler ;@) but then I would!

Or should I say with Basalt is is much easier :@P

I do think that, if you have the right frame of mind, writing large applications in C is going to be more flexible and easier to maintain, and in nearly all cases they will run faster. However, BASIC has been used for large programs, and for smaller programs the development cycle can be quicker.

The problem pointed out by Chris is likely to be more to do with the C Toolbox libraries than the language itself. They implement the TB SWIs directly in a procedural manner and do not really acknowledge the OOP nature of the TB model. Neither do the AppBasic libraries.

Basalt does do this, and can make things more convenient and speedy, but BASIC can be used with a nod to OOP without too much trouble. It can even be forced into a much closer relationship with some effort, but that might not be worthwhile. So you could have:

PROCValue(MyForm,Message,"Hello World") – the set operation

matched with:

message$=FNValue(MyForm,Message) – the get operation

and hence, from the example above:

intro$ = "Dear "+FNValue(MyForm,CustomerName)+", thank you for your e-mail."

A new version is now available for download. The main change in this version is the addition of save/load functionality.

I’m not planning any other functional changes¹ (suggestions are welcome though!) but the next release will tidy up a few things. I re-read the Style Guide from cover to cover last night and came up with a rather large list of tweaks that I’d like to implement, so “watch this space”.

¹ Edit: I forgot that I haven’t implemented Discard/Cancel/Save yet. That’s still on the to-do list.

Popularity seems to have dropped off (the second release only got 1/5th as many downloads as the first one), but nevertheless I have a new version available for download. Changes are as follows:

• Redesigned “Enter score” dialogue box. It’s now long and thin instead of big and bulky; I’m pondering making a phone version of the app so this is a first step in making the UI consistent. It might be a bit easier to go down the list instead of side-to-side too.
• Implemented Discard/Cancel/Save functionality. It’ll now warn you if you quit without saving.
• Added a sprite for when the window is iconised.
• No longer swallows F12 (oops!).
• Added help text throughout the app.
• Added scroll bar so that the app can be used on low-resolution systems.
• Double-clicking a saved file in Filer no longer launches a second instance of Seasonal if it’s already running.
• Dragging a file to the icon bar now works.
• Other minor UI improvements.

I still have one known issue (pressing Cancel in a dialogue box closes the window but doesn’t actually cancel the changes) so I intend to put out another release at some point. I also think I’ll put the current alpha in PackMan after being prompted by a recent forum post :)

Another week, another update: Version 0.10 is now available for download, and should appear in PackMan soon. I’ve fixed the “Cancel” issue along with another bug where scores could be recorded under the wrong player if you had multiple “Enter score” dialogue boxes open at the same time.

This is the last of my planned releases; any future updates will be in response to bug reports or feature requests.

Well, I found a bug (loading a file when you have unsaved changes caused the changes to be lost without warning) and have fixed it. You can get the new version from the usual place or wait for it to come through PackMan.

But that’s not the real news! I got sick of massaging the huge amount of “plumbing” code necessary for the DCS toolbox object (showing DCS, showing SaveAs, responding to PreQuit messages, objecting to shutdown, resuming shutdown, etc.) and figured that there must be a better way. I ended up writing a separate C library that does most of the work. Seasonal is now using this new library and the code is about 40 lines shorter as a result. If there’s any interest then I’ll write some documentation and create a new thread about it.