Hyperion Entertainment Message Boards

From the application AutoDoc:

Please refer to the PrefsObjectsExample demo about more examples
on how to use the PrefsObjects system.

Where is this elusive demo?

@mritter0

Oh please don't get me started on the Application Library/PrefsObjects autodoc!

More seriously: what kind of help/example do you need in relation to PrefsObjects?

mritter0 wrote:From the application AutoDoc:

Please refer to the PrefsObjectsExample demo about more examples
on how to use the PrefsObjects system.

Where is this elusive demo?

Is it not here?:

SDK:Examples/Application/PrefsObjectsExample/PrefsObjectsExample.c

I wouldn't use it myself, it produces horid unstructured xml, where the only relation between a key and value is that value follows immediatly after the key.

I use expat and my own sane xml prefs formats for SketchBlock.

@broadblues

Yes, the PrefsObjects XML file structure is quite unbelievable. Keys should have been declared as attributes and not as elements preceding other elements. The design probably comes from the time when one could take an idea and make it part of AmigaOS without consulting anyone else. Shared objects is another example.

broadblues wrote: Is it not here?:

SDK:Examples/Application/PrefsObjectsExample/PrefsObjectsExample.c

I can't find it in the new SDK or the previous one.

trixie wrote: Yes, the PrefsObjects XML file structure is quite unbelievable. Keys should have been declared as attributes and not as elements preceding other elements. The design probably comes from the time when one could take an idea and make it part of AmigaOS without consulting anyone else. Shared objects is another example.

I'm tempted to voice my opinion about useless additions and useful things removed but it probably won't do any good at this point

xenic wrote:

broadblues wrote: Is it not here?:

SDK:Examples/Application/PrefsObjectsExample/PrefsObjectsExample.c

I can't find it in the new SDK or the previous one.

Oh, seems that the Application examples aren't in the SDK.

The examples directory structure has changed abit, so something like Reaction examples and menuclass have moved under GUI, but Applcation seems missing completly.
Don't know if that's intentional (out of date example for instance) or not.

I opened another can of worms.

I was going to update my program's prefs file from IFF to PrefsObject XML style since it is the "new standard". No example code to get a start with. The AutoDocs don't have any examples.

The examples directory structure has changed abit, so something like Reaction examples and menuclass have moved under GUI, but Applcation seems missing completly.

I didn't even see the new MenuClass examples until I had posted a few questions that would have been taken care of if I had known they were there.

So I wasn't blind this time; not seeing the Application examples.


The PrefsEditor in Utilities drawer can't load any program's XML prefs file that I tried (CodeBench, Ringhio,...) Am I wasting my time using PrefsObject system?

The PrefsEditor in Utilities drawer can't load any program's XML prefs file that I tried (CodeBench, Ringhio,...)

They are using their own custom xml format, prefs editor is not a general xml editor, just a prefsobject "broken" xml editor.

Am I wasting my time using PrefsObject system?

All a matter of choice, if you have working IFF based -prefs code, there no compulsion to 'upgrade'.

Whilst I'm not a fan, one usefuil aspect of the prefs object approach is that you can manually edit the prefs file, so not every preference needs a GUI to control it, useful for rarely used options. This is also true of custom Xml solutions or even plain text based ones (like YAM uses) less so of IFF.

broadblues wrote: I wouldn't use it myself, it produces horid unstructured xml, where the only relation between a key and value is that value follows immediatly after the key.

Well if there are problems with the current pobjects format then they can be fixed in application.library.

Currently application.library reads and writes version 1.0 pobjects files but it should be simple enough to make a new version of the library that reads version 1.0 and version 2.0 pobjects file and writes in the latter format only.

If you have suggestions on how the new pobjects format should look then please post them here.