Variable Number of Properties - Proof of Concept

[LB]

For all extension developers who have always wanted to have a property interface similar to the global values and alterable values where you can add and remove values, I have a very limited proof of concept extension here that does just that - you click a button to add a new property and click another to remove it. It turned out to be less work than I expected, just a lot of careful reading of the MMF2 SDK help file. I did this in rSDK but the procedure should be the same in EDIF and the regular SDK

Here is the VC++2008 project: http://www.LB-Stuff.com/MMF2/Extensions/ProofOfConcept_VariableNumberOfProperties.zip
[size:8pt](This of course uses my own modified template, but who of us doesn't have modified templates? )[/size]

And for non-extension-developers who want to see this coolness for themselves, here is an MFX file you can plop into your MMF2\Extensions\ folder: http://www.LB-Stuff.com/MMF2/Extensions/VariableProps.mfx

Again, this is just a simple proof of concept - I and I expect others may exploit this to do cool things. In fact I made this because, although I cannot find the thread, I recall somone along the lines of Crazy_Ivan/DizzyDoo/Dines/someone asking if it was possible to do just this.
[size:8pt](If you remember who it was and can find the thread please link it)[/size]

[Tim]

Hey LB, I personally didn't request it but I'm sure it will help me and other extension developers in the future
Haven't had a chance to download it yet, but I plan to

[LB]

Sorry, well it was Dines it turns out:
http://www.clickteam.com/epicenter/ubbthreads.php?ubb=showflat&Number=147787#Post1477 87
It was Dines trying to make a variable number of properties and Jaffob saying it was impossible that drove me to make this. Of course, I couldn't make this for a long time because I had no idea how properties worked until just recently. However I think I did not satisfy the variable number of actions/conditions/expressions that his extension would need...that's for another time...

However there's still one thread missing, my post in the above thread reminded me that someone had mentioned not being able to do this. I think that was a second and more direct reason I made this...

Well, anyway, I'm off to make something cool with this after I finish something else..

[Tim]

Well I'm sure I'll use this in a future project or extension
Thanks for providing this!

[Atom]

This is a really great idea LB, thanks

[JimJam]

Its very interesting. But I don't exactly see the implications of it yet.

How exactly is this any different from just using alterable values? I mean, what exact use does adding property values at edit-time have for the extension user? With terms such as "Value A, Value B, etc" I can't really find how this would be used.

I understand its a proof-of-concept: You proved that this concept does work! But for what use? You can't really invent something without an explicit use. Otherwise your invention is useless!

The only real use I can think of off the top of my head would be to create pre-defined data in an 1D array type object. But that seems kind of limited.

Property values are usually pre-defined set-up values for an extension. How exactly does adding pre-defined values dynamically improve an extension's use? "Dynamically generated pre-defined data" is kind of an oxymoron.

Forgive me if I seem to be pooping on your parade -- I do find it amazing that this is possible -- but I just don't see the implication. Care to tell us what it is that this could be used for?

[LB]

I limited this to 26 prenamed number properties, but this can be expanded to allow you to use any number of any of the properties MMF2 supports with any name. And 524,287 possible properties, of one kind or of many kinds, is a lot. The power behind this is that A, you no longer have the "Oh no I ran out of alterable values!" problem, and B, widgets would suddenly be able to have so much more to them with custom properties. And, since all the major stuff is done edit time, the runtime to get/set the properties could be easily ported to different runtimes. This is what I am doing now to pass the time until MMF3 comes with this as a built-in feature.

[LB]

Although I cannot edit my post above, I would like to point out another discovery in Props.h:

#define PROPOPT_REMOVABLE		0x00000008		// The property can be deleted by the user
#define PROPOPT_RENAMABLE		0x00000010		// The property can be renamed by the user
#define PROPOPT_MOVABLE			0x00000020		// The property can be moved by the user (list only)
#define	PROPOPT_LIST			0x00000040		// The property is a list

Now, I have no idea how these are meant to be implemented, but I know that they can be passed manually to a PropData stucture. I will do some testing and see if these are only for internal MMF2 things or if they can be used by extensions too

[JimJam]

...A, you no longer have the "Oh no I ran out of alterable values!" problem, and B, widgets would suddenly be able to have so much more to them with custom properties... ...could be easily ported to different runtimes...

Ok, so your greater idea here is to essentially make a "widget" object. Something that can have as many "Properties" as you want, while not using up any of MMF2's built in Alterable Values. Thats a good idea. Most of my widgets don't use any of the "graphical" features of the Active Object anyway. They are more or less functional invisible objects.

And if you could get Clickteam staff to help you integrate this sort of functionality into the Active Object itself (in this version of MMF), we could be looking at an "Active Object Plus" type of object. Which would be great!

But I'm sure they will save this kind of functionality for MMF3, obviously. Would be great if it could be used in MMF2, since as you've shown its easily within the reach of possibility.

EDIT:
Ok, I think I really get it now. I really do see the grander usefulness of this concept. I must have not really seen it because I was so tired last night when I posted!

Keep up the good work, this is amazing stuff! And really see if you can get Clickteam's aproval. I really think the true usefulness of this kind of extension can only be fully realized with Clickteam's cooperation. If you set up the frame work, and make it simple enough, they should be able to implement it easily without putting a damper in their own plans.