In my tool, both DLLs containing my extension information are loading correctly. I call...

mgWalk(db_rec,templateWalk, mgNULL, (void*)&options;, MWALK_VERTEX | MWALK_MASTER | MWALK_NOREADONLY)

which returns successfully. As the nodes were walked, For each node type in my tree, I have code like this...

    Options* options = (Options*)userDataPtr;
    if (options->deleteNodes)
    {
        deleteExtRecord(db_poly_rec, myExt1);
        deleteExtRecord(db_poly_rec, myExt2);
        deleteExtRecord(db_poly_rec, myExt3);
    }

and deleteExtRecord looks like this...

void deleteExtRecord(mgrec* parentRec, mgcode ep2Record)
{
    mgrec* delNode = mgGetExtRec(parentRec, ep2Record);
    if (delNode)
        g_deleteRecords.push_back(delNode);
}

where g_deleteRecords is a

std::vector<mgrec*>

Then, after mgWalk finishes, I run this...

        size_t delRecLen = g_deleteRecords.size();
    for (size_t i = 0; i < delRecLen; i++)
    {
        if (mgDelete(g_deleteRecords) == mgFALSE)
        {
            char msgbuf[1024 + 1];
            mgGetLastError(msgbuf, 1024);
            printf("%s\n", msgbuf);
        }
    }
    g_deleteRecords.clear();

But, not only does mgGetLastError not work for mgDelete, but every delete is failing for some reason. Any ideas? FYI, I'm pushing the records onto a vector and deleting them after the walk to avoid any potential weirdness that might arise from deleting records during the walk. Is that necessary?

But, not only does mgGetLastError not work for mgDelete,

Unfortunately not all functions that can fail log a message for mgGetLastError. Some do, some don't.

Any ideas?

Your code certainly looks correct. Can you tell us what version of the OpenFlight API you are using? I tried (a variant of) your code using 4.2 and see that mgGetExtRec + mgDelete is removing the tag-along extension record correctly.

FYI, I’m pushing the records onto a vector and deleting them after the walk to avoid any potential weirdness that might arise from deleting records during the walk. Is that necessary?

In this case it is not necessary but I don't think it can hurt. If your extension records are "tag-along" records, deleting them during the mgWalk won't hurt. Only when you delete stand-alone (node) extensions records, mgWalk can get wonky if you delete during the traversal (in the pre-function at least).

In conclusion, I don't see anything wrong with your code. Try deleting the tag-along extensions during the mgWalk and see if mgDelete gives you different results. I'd be interested if it did.

Let us know what you find out. And tell us what version of the API you are using. I can check for known bugs in past versions if I know which one you're using.

I am using version 4.2.

After I delete the extension tags, I call

    if (!mgExportDb(db_rec, options.outputFullPath, MEFN_OPENFLIGHT, MEFV_1570, MG_NULL))
    {
        mgCloseDb(db_rec);
        return -1;
    }

    mgCloseDb(db_rec);
    return 0;

The purpose of my tool is to export current files to an older version to be compatible with our legacy software. I also tried deleting the tags during mgWalk and the results were the same when I opened up the files in Creator - the tags were still enabled.

Hmmm... there goes my theory that the older version might have had a bug...

Everything you are doing should work.

Are you doing this in a stand-alone app or Creator plugin?

In either case, are the extension DLLs that created this extension data being loaded (in your app or in Creator)? Perhaps without the DLLs in memory, the API can't quite understand what you are doing.

It's a stand alone app and the DLLs are loading successfully (at least, that's what the messages that are being printed out say).

How about we approach this question from a different angle. Under what conditions does mgDelete fail? If I know that, perhaps I can investigate the problem a little further on my end.

Sorry for lack of response recently.

Have you made any progress in the mean time?

After inspecting the code, there are many functions in the mgDelete chain that can derail the function from completing. The theme seems to be that the API can't figure out what the extension data is - which does happen when the DLL that "owns" these extensions cannot be loaded. I will try to rig up a stand-alone app here in the office today to try to replicate this. I have a test plugin (in Creator) that does NOT exhibit this problem. Perhaps there is something missing here when Creator is not involved.

A longshot...

You are not trying to modify a node that is "under" an external reference by any chance? i.e. you open the master file and walk to a node that is under an x-ref? When you do this, you cannot modify the node in the x-ref, only nodes that are directly in the master file.

I haven't made any progress. Would it be possible for me to send you a zip of my extension DLLs and my visual studio (2010) project with code?

If you are on maintenance, the best way to do this would be to pack up the files and open a support issue with Presagis Customer Support. That way it all gets tracked, etc and you are guaranteed that we will look at it.

If you are not on maintenance, you can zip up and attach to this thread and I'll have a look when I can but can make no promises.