Chart Object now can be added to MMF HWA applications

The Chart Object I wrote for Multimedia Fusion 2 would not allow itself to be added to hardware accelerated (HWA) applications. At the time the object was released, this was a separate runtime. It was disallowed as it didn’t appear to work properly with it – nothing would be displayed (except for the pie chart mode, which writes to an internal buffer first).

Today I started work to make the Chart Object HWA compatible (although not actually take advantage of the HWA). The first thing I did was remove the tests which stopped it being added to HWA applications. I tried it, and it seemed to ‘just work’ so long as the ‘Display Mode’ setting in the application properties is not ‘Direct3D 8′ or ‘Direct3D 9′ (both of which may cause crashes).

Well, I thought this would probably do for now. I’d be interested to know if there are any people who are strongly bothered by the inability to use it with Direct3D. Perhaps if it is an actual problems I will convert it to use off-screen buffers, but I’d prefer not to.

Download the version of Chart Object without the HWA checks

Edit: A quote I found from my notes from Fimbul which – probably fairly – describes the situation:

[T]he graph object. It’s great, but it’ll probably never see HWA, java, etc. It has an excellent function that allows you to get the coordinates for the points, so if you want, you can plot a graph yourself, but you can’t use that in the other runtimes (and I think it glitches even in HWA if you try to use it there). This is another example of something that is already using a form of coding, but that instead of being “click-friendly”, it’s mostly “click-impossible”.

Alas, it was created before alternative run-times, but released at about the same time as them.

Work on Multimedia Fusion extensions

A few of my extensions have known problems with it. I don’t particularly enjoy working on these projects; actually, I pretty much hate it. I have much better things I could be doing. However,  I will try to make the changes when I can.

The known problems are:

Chart Object

• No support for HWA, which means it doesn’t work in the latest version of MMF
• No support for Unicode titles, etc.

Ini++

• Crash to do with encryption

String Replacer

• Suspected crash turned out to be due to a different object

Spell check Object

• Lack of support for additional characters (such as accented characters)

String Replacer

• Lack of support for additional characters (such as accented characters)

None of these will be much fun at all to work on, or particularly rewarding, so don’t expect progress to be quick. However, hopefully it will happen someday.

Why so many versions of Ini++?

It is often asked why there are so many versions of the Ini++ object. I’ve explained the answer a few times on the Clickteam forums, but I thought it would be worth while explaining it here too.

The answer is: There’s not.

The situation is that there are versions of the Ini++ object. The original, and Ini++ v1.5. The latter was made when the Ini++ object behaviour changed. In particular, it no longer enforced items and groups to be in sorted order. Therefore I could not release this as an update to the original, as it could break peoples code. To make things worse, this was not something which could be an option either (without some rewriting of code in the original). It was called Ini++ v1.5 as a nod to Multimedia Fusion v1.5, which was Multimedia Fusion v1.0 plus many new features.

Naturally, there have been different releases of the ‘Ini++ Object’ and the ‘Ini++ v1.5′ objects, but both kept calling themselves that name. There is no ‘Ini++ v1.6′ object. There is no  ’Ini++ v1.1′. Just the two mentioned. They have the file names ‘Ini++.mfx’ and ‘Ini++15.mfx’ respectively.

So why the confusion?

The problem stems from the fact that although the behaviour of Ini++ v1.5 changed from that of the original, it was still compatible with the original Ini++ object. That is, if you took ‘Ini++15.mfx’ and renamed it to ‘Ini++.mfx’, then any MMF application using the old version would suddenly be ‘upgraded’ to the new version. If you knew your program wasn’t going to stop working because of the changes, this was a great way to make use of the new features without copying over all the events to the new object. Quite a lot of people did this.

It was entirely deliberate that you could do this. In fact, Ini++ v1.5 has a few actions which have no menu items exactly for this purpose. For if they were removed from the code, then this renaming method might not work.

You would expect that if you did this you would see two identical looking objects in the ‘Create new object’ dialog. The same icon, the same text: ‘Ini++ v1.5 Object’. In fact, this is not what you see. Multimedia Fusion will rename the second object to ensure it doesn’t have the same name, so you actually end up with ‘Ini++ v1.5 Object’ and ‘Ini++ v1.5 Object 2′.

The first one (selected in the picture) actually has the file name ‘Ini++.mfx’ and the second has the file name ‘Ini++15.mfx’.

An earlier version of the Ini++ v1.5 Object called itself simply the ‘Ini++ v1.5′ object. Therefore if both ‘Ini++.mfx’ and ‘Ini++15.mfx’ were that version, you would in fact get ‘Ini++ v1.5′ and ‘Ini++ v1.6′ in the dialog, as it intelligently renames. Therefore any object calling itself ‘Ini++ v1.6′ is just an illusion. (Indeed, the title of the object was renamed after it was noticed this happened to avoid this confusion)

But perhaps you are seeing this anyway, despite not being one of the people who renamed ‘Ini++15.mfx’ to ‘Ini++.mfx’? Unfortunately, this is common. The first installer for the first release of Ini++ v1.5 actually installed the file as ‘Ini++.mfx’, which was obviously complicated the situation. (I didn’t make this installer. Later installers install it correctly.) I believe that the one of the extension updaters for MMF will also distribute Ini++ v1.5 with the filename ‘Ini++.mfx’. Combined, this means that nearly everybody will have this problem.

Perhaps I will solve this in future by having the next installer install the original version of Ini++ as well. Or perhaps by making sure it is uninstalled (as you shouldn’t really be using it anymore anyway – it exists only for compatibility reasons now).

So which version is the latest version? Well, it is quite possible they are both the same version. Make sure you are using the version with the file name ‘Ini++15.mfx’ (you can tell this by selecting the object and clicking the ‘About’ tab in the properties viewer). Ensure this is up to date by installing the latest release. If you don’t use ‘Ini++.mfx’, perhaps you should delete it.

Chart Object Released

So, at last, I’ve released the Chart Object, along with the latest version of Ini++ v1.5. I have written many posts about the progress of the Chart Object, so it is great to finally get it released. I’m sure there will be an initial set of bugs, but hopefully there won’t be anything too major.

The Ini++ v1.5 object has a large number of bug fixes from the original release, and works much better. It is worth noting that the compression algorithm is different that before, so if you use compression it cannot open old Ini files.

The latest bug fix in Ini++ v1.5 is to do with the loading of subgroups, which didn’t work very well previously. Essentially, this is a feature which changes the loading and saving routines to take tabs into account. Groups which are indenting are considered ‘subgroups’. So for instance,

[Group]
a = 1
	[Subgroup]
	a = 2

has the group ‘Group’ and which has the subgroup ‘Subgroup’. The object does not support subgroups in memory, so it is faked by renaming groups to their path. It is hence loading in memory as:

[Group]
a = 1
[Group/Subgroup]
a = 2

This feature was always present, but it was previously fairly buggy.

Ini++ bug fixes

I haven’t forgotten about Ini++ and the Chart Object. In fact, some bugs in the former were delaying the release of the latter. I want them to be released at the same time in order to stop the ‘version hell’ that is the current state of Ini++ (i.e. too many versions floating around, some with bugs). It’s a shame really, because I want the Chart object out of the door.

So mid-September I was told about some bugs. By January I had time to work on them (as I was working on the Chart object before hand, getting ready for what I thought was the release) and had managed to reproduce the bugs, with Pixelthief’s invaluable help. Unfortunately, with only bits of weekends to work on them, as well as problems to do with which computers I have debuggers on, it took ages. I program at work a lot, so I rarely feel like going home and programming as it is. Debugging, definitely not. Still, I carried on and last night I think I finally cracked it!

I fixed quite a lot of bugs on the way. Most of them are small and probably had no effect, but certainly some of them did as it seems to work now. I am so glad to get it out of the way! If, indeed, I have.

Hopefully I can release it through Clickteam fairly soon. It’s late enough already!

One thing: The latest version’s compression is incompatible with the old versions compression. It will not open any compressed files saved in the new version. I hope this is OK with everybody. I switched to zlib for the compression, whilst before I used a library which appears to have had some bugs in it (and was generally unsafe on corrupt files). The penalty for this is a much bigger file size. (About 60kB bigger for the Runtime version.) It’s still all tiny by today’s standards though.

Stay tuned!

Ini++ Update: New ‘Undo’ feature

Ini++ has a new feature, by the request of HolyMonkey.

Everything that the object does which changes data can now be undone. The object stores a list of things which have been done. When desired, the ‘undo’ action can be called to revert the last set of changes. A new condition ‘Has undo’ can be used to see if the undo buffer has anything in it or not.

The undo buffer can be infinite size, of some finite size (so that it remembers the last, say, 8 actions) or zero, which disables it. By default it is zero, as if you do not use this feature, it will waste memory.

This allows people who have developed Multimedia Fusion applications around the Ini++ object to add ‘Undo’ capability ’for free’ (i.e. with little or no extra work). It also means that people who want to design applications with an ‘undo’ feature can easily do it if they centre their program around Ini++.

You can also undo undoes with the redo feature. The redo buffer size can be separately kept. Redoes can be undone with the undo action, if that makes sense. Ini++ also automatically clears the redo buffer when the any changes are made to the data (except via the Undo or Redo actions).

Caveats: Undo functions do not necessarily retrain the group ordering. You will need to request this as a feature if you want that. Undo functions do not necessarily strip out redundant operations (i.e. setting an item to the same value as it currently is, or deleting a non-existing item), although it may and behaviour may change. Request as a feature if you think you know how it is best done. Finally, operations in your program may translate into multiple operations to the Ini++ object, and so you may need the ‘undo’ button in your program to undo more than once depending on what operations were previously done.

A new example demonstrates a simple level editor that takes only 6 or so events and supports ‘undo’ and ‘redo’. It is Unicode only because I accidentally opened saved it in MMF  Unicode. Opps. Speaking of which, there are lots of improvements in the Unicode support. Saving/loading alterable strings and global strings now works fine in Unicode mode, although it is work noting that internally it will always use ANSI strings. This means that you may not get what you put in if it is a character from the extended set.

In addition, some other bugs have been fixed, and so you should update even if you do not plan to use these features.

Now I hope I never have to touch this object again! Hopefully it will be out the way so I can actually release the Chart object, which has been finished for ages but needs a stable release of Ini++ before I can get it out the door.

Download

New Expression Editor for Multimedia Fusion

These days, Microsoft Word has a really good equation editor built into it:

On the other hand, look at Multimedia Fusions expression editor:

I thought it’d be great if Multimedia Fusion had proper equation editor. If you typed something like “1/2″ it would automatically turn it into a fraction, or you could use buttons like in the first screenshot. Furthermore, I envisioned a tree on the right where you could drag-and-drop icons from, which would represent expressions. Clicking an expression would show a pane at the bottom of the screen with various options. I thought that perhaps an icon could also have some descriptive text associated with it.

The final difference is you’d be allowed to introduce variable names and at the bottom you could define them. This can make expressions a lot easier to read.

I actually programmed most of this, and I made something which translated MMF expressions to a visual display. However, I am now at the stage of making them editable and I just can’t be bothered anymore. I pretty much want to get out of all this MMF programming, at least until MMF3.

Another idea was a similar editor for editing strings, built around the idea of a jigsaw puzzle style interface where you join things together, and also apply functions to sets of jigsaw puzzles (denoted by a background). I didn’t even start programming this, however.

Whilst I am here, the latest news with Ini++ is as follows: The undo features are all finished, as mentioned in this post. However, the Load Object function was crashing (in either normal or Unicode version of MMF), so I am looking into that, and we’ll have to see what Yves says. I’ve also a request from somebody else to add another feature, and I’ll see if I have to do that. Some of the Unicode versions bugs have been fixed, however. For instance, saving global strings now works (even if loading global strings does not). When this is out the way I can finally get the Chart object out, which I am really keen to do.

Creating Extensions in MMF

At the Click Convention, Chris Branch spoke about creating extensions within Multimedia Fusion itself. I think this is a great idea, and I think that the Ini++ object is an example of why.

The Ini++ object is fundamentally very simple: It is an associated-array of associated-arrays of strings. However, data structures like that are not easy to work with in MMF, and so the object wraps at this up for you. It also includes other functions, for instance hashing, encryption, debugging dialog boxes and integration with object objects. Finally it has a load of actions which could theoretically be programmed yourself such as merging and searching.

So the Ini++ object really is not a difficult thing. So it should be easy to port it to Java and Flash and iPhone and so forth – but it isn’t.

The problem is, it is too big. There is a lot of code, and a lot of actions. Ini++ will never be ported. I wouldn’t want to anyway: The Ini++ v2.0 object (which to some degree exists, but has never been released) is so much more elegant. The original evolved, but this was designed. It is so much nicer. But I don’t have the time or will to work on that, let alone porting the original object.

But imagine this: Suppose the C++ (or whatever) component of Ini++ was very small. Maybe just based around a hash-table object which also had some features to do things which would otherwise be slow (sorting and searching for instance). Then all the features like ‘Merge into other Ini++ object’ and ‘Sort items of groups’ and so forth could be programmed in MMF itself. It is automatically portable! The difficulties are hidden from the user, but not put into my code. It is great!

It makes a lot of sense really. Somebody once wanted Ini++ to export to CSV. Have you ever used this feature? I bet you haven’t. I haven’t. So why should it be in the code? It is sitting there, making the object less portable, whilst adding absolutely nothing to nearly everybody else.

Saving the details of an object (as the ‘Save Object’ function does) would be positively better written in MMF. I assume what the internals of the object will look like, but that might change. Indeed, it has changed with the Unicode version of MMF – Saving alterable or global strings will only give you the first character. I guess I should fix that before the final Ini++ v1.5 release – I’ll put it on my list now. (Edit: The latest versions have fixed this.)

If it was coded in MMF, there would be no need for changes at all. It would be better. You might say there would be a loss of speed, but I doubt it’d be a big deal.

I think the elegance of the idea is brilliant. When MMF3 comes along, if it supports this feature I won’t be recreating an Ini++ type object directly. I will strip it down to its bare bones and make the rest within MMF3. It is much more elegant.

MMF Object Updates for Unicode

Some of my MMF objects have been updated to make them work in the Unicode version of MMF. This does not mean they support Unicode, it just means that they still run on the Unicode version. In particular, actions where you could type the name of an object and it would interact with it now work again.

The updated objects:

• Ini++ v1.5
• Substring Replace
• List & Set Object II

Note that the List & Set Object release is the first since the new List control actions have been added.

Please report any bugs.

Update: The Ini++ object has been updated again to fix a bug with the properties.

List & Set Object interacts with default MMF List Control

The List & Set Object I am working on for MMF has a new feature where it can put its content into a List object (as in, the List control GUI component that comes with MMF), or take content from a List object. This is in recognition that this is something which will often be needed to be done.

New actions in the List & Set Object

I’m not going to release the update just yet as I am aware it won’t work on the Unicode versions of Multimedia Fusion. The Ini++ object also has this problem with its Chart object integration and integration with other Ini++ objects. The Substring replace object has the problem in its integration with the Array object. It comes about because the name of object is stored in Unicode in the Unicode versions of MMF, whilst the object expects it to be in single-byte format.

With this update to Ini++, the object will soon go out of beta, and the Chart object is very near to release we well. However, for this to happen Yves has to e-mail me back, but he has just got back from holiday.