Save config maintaining file separation

graaggraag
edited August 2012 in Bug report - Feature request
Hi,

I would like to be able to maintain the split of the config data between several ini files while performing orxConfig_Save. This would be very useful for any editors that use Orx config system.

Currently I see two possibilities using SaveFilter.
- Ini files contain strictly defined config sections (I think ScrollEd uses such approach while saving map files)
- Add a key to each section that defines a file it belongs to.

Both options are not really robust :blink: .

I was wandering if the config system could store the name of the ini file where a section was defined for the first time. Then using a SaveFilter would be easy to save only sections that belong to a given file. This would break possibility to define one section across several files but such split is anyway broken with current orxConfig_Save.

Here's how a SaveFilter could look like:
orxBOOL orxFASTCALL SaveFilter
    (const orxSTRING _zSectionName,
     const orxSTRING _zKeyName,
     const orxSTRING _zFileName,
     orxBOOL _bUseEncryption)
{
    orxBOOL saveIt = orxFALSE;
    const orxSTRING isCurrentFile = orxNULL;

    orxConfig_PushSection (_zSectionName);
    const orxSTRING configFile = orxConfig_GetSectionConfigFile();
    /* Check that we are saving the section into original ini file or a backup of therof */
    if(configFile != orxNULL)
        isCurrentFile = orxString_SearchString(_zFileName, configFile);
    orxConfig_PopSection ();

    if (isCurrentFile != orxNULL)
    {
        saveIt = orxTRUE;
    }

    return saveIt;
}

I prepared a proof of concept implementation. You can find a patch in the attachment. For now I've enclosed the implementation inside #ifdef's as I'm not sure if an additional char pointer per config section is an acceptable trade of for standard Orx usage scenarios.

Cheers,
Graag https://forum.orx-project.org/uploads/legacy/fbfiles/files/orxConfig.zip

Comments

  • iarwainiarwain
    edited August 2012
    Hi Graag,

    I like the idea of tracking the originating file for sections though I don't think I can use it a lot myself as I'm heavily relying on inheritance and overriding for my own projects, not mentioning that some core game sections are scattered over different files and tracking per section wouldn't be enough.

    That being said, I'm sure that will work for a lot of different cases so I'll try to integrate your changes in a few days.

    Thanks!
  • graaggraag
    edited August 2012
    Glad to here you find it useful.

    Cheers,
    Graag
  • iarwainiarwain
    edited September 2012
    Hi Graag!

    I finally had the time to implement your idea tonight. It's slightly different using a dictionary to prevent string duplication explosion and I added an accessor called orxConfig_GetSectionOrigin().

    I also modified the command Config.Save (which has a default alias named Save) to now take 3 parameters (of which 2 are optionals).

    If you open a console and type (command and alias are case insensitive, btw):
    save orx.ini
    All the config data will be saved to it.

    Whereas if you type:
    save orx.ini true
    Only sections that originated in orx.ini will be saved there.

    (The second optional parameter of the command is for controlling encryption, disabled by default.)

    For reference, here's the code of the callback I use internally for the command:
    /** Origin save callback
 */
orxBOOL orxFASTCALL orxConfig_OriginSaveCallback(const orxSTRING _zSectionName, const orxSTRING _zKeyName, const orxSTRING _zFileName, orxBOOL _bUseEncryption)
{
  orxBOOL bResult;

  /* Updates result */
  bResult = ((_zKeyName != orxNULL) || (orxString_Compare(_zFileName, orxConfig_GetSectionOrigin(_zSectionName)) == 0)) ? orxTRUE : orxFALSE;

  /* Done! */
  return bResult;
}

    Let me know if you have get issues!

    Cheers!
Sign In or Register to comment.