Start a new topic

"Enable Extension Attribute" tick box

Original Post by: MattN Tue Feb 26 16:45:04 2013


Hello.....


Having just used version 4.2. of Presagis Creator I've noticed you get a warning box pop up if you untick "Enable Extension Attribute" on one of the extension attribute tabs of a node.

<Verify Delete Extension - This will delete the extension data from # node>


Could someone please put me out of my misery and tell me what the API function call is for this (I never knew you could enable/disable this tick box directly for each extension tab, I though it simply became enabled as soon as you set one of the tab's extension attributes and remained unticked if none of the extensions were set).


I just want to be able to disable the "Enable Extension Attribute" tick box for each of our extension tabs but I can't see how I access 'em.

:-(


Thanks for any help offered...


Original Post by: MattN Mon Mar 18 21:43:01 2013


.....forgot to say that...you CAN delete the extensions if you duplicate the whole database first into a new file, then traverse the duplication and delete the extensions as you go. I thought I'd mention it, since it may help you with the fix for the next version of the API (since the work around doesn't seem bullet proof).


Cheers...

Original Post by: MattN Mon Mar 18 10:56:56 2013


Hello again..... :-(


I seem to be having trouble with mgClose() when I've deleted extension records. It would appear that I can mgOpen() a file, traverse it with mgWalk(), removing specific extensions as I go, mgExport() the edited file and all is good (with your workaround as suggested above), however, when I mgClose() the file, it crashes. The exported file looks fine, but (obviously) the process' memory usage goes up (and up!) without being able to perform the mgClose() afterwards when working iteratively on multiple files.


In fact, just mgOpen()'ing a file, mgWalk() it and removing the extensions, and then just mgClose()'ing it crashes (so no exporting or saving). Using my own traversal routine, avoiding mgWalk(), makes no difference (but thought I'd mention it to remove it from the enquiries).


I don't suppsoe you have any suggestions or workarounds, do you? :-(


Thanks...

Original Post by: MattN Thu Feb 28 10:01:31 2013


Excellent, thanks for taking the time to look into this - it's much appreciated. Any idea when the upcoming release is gonna hit the streets?


Thanks again.

Original Post by: SteveThompson Thu Feb 28 01:03:09 2013


Ok... after some further digging around the code, I can now see why you are having trouble.


There appears to be a bug in mgOpenDb when parsing extensions it finds. To make a long story short, mgOpenDb is not encoding the correct information in the opaque mgrec* that it builds for the extension data, attaches to the node and is subsequently returned by mgGetExtRec. When you call mgDelete with this "incomplete" mgrec*, mgDelete can't do what you ask. When you subsequently duplicate the node structure, the "complete" mgrec is built for the extension dup. And that explains why the dup can be deleted.


The conclusion, I'm afraid is not great for you unfortunately. After some poking and prodding I have come up with a workaround (ugly as it is)...


First, I assume your program looks something like this:

db = mgOpenDb("MyFile.flt");

...

extRec = mgGetExtRec(node);

mgDelete (extRec);

...

mgWriteDb(db);

mgCloseDb(db);


If you create or otherwise open another db (and leave it open) before you open MyFile.flt, the extRec is created correctly (too long and too embarrassing to explain why) and mgDelete will subsequently work for you. While this is ugly, there is not much downside or risk by doing this.


Here is what your workaround code would look like:

// if another db is open during the "real" mgOpenDb,

// the extension records are created correctly for mgDelete

// to be able to process them

temp_db = mgNewDb("somename_dontcare.flt");


db = mgOpenDb("MyFile.flt");

...

extRec = mgGetExtRec(node);

mgDelete (extRec);

...

mgWriteDb(db);

mgCloseDb(db);


// just close it when you're done, no harm, no foul

// except knowing this is UGLY!

mgCloseDb(temp_db);


Anyway, thanks for pointing this out to us. I've taken the liberty of fixing it in our upcoming release.


And sorry this workaround is a bit yucky but it seems to work.


Good luck.

Original Post by: SteveThompson Wed Feb 27 21:56:36 2013


ah very good... that suggests that you are using the correct DLLs. Sorry that did not occur to me to make that connection sooner. :red:

Original Post by: MattN Wed Feb 27 21:16:46 2013


Hello again,


I'm not at my workstation right now, but I'm pretty sure it's running with the correct DLLs - I will verify this, though. However, we can be sure that the mgDelete is working correctly with the duplicated node...

Original Post by: SteveThompson Wed Feb 27 17:24:10 2013


Great... sorry that I have to ask this but...


While your app is "linked" with 4.2, are you sure you are "running" the 4.2 DLLs? It is a very common problem that OpenFlight API apps run and "find" the "wrong" DLLs at runtime. Technically this is not an error and sometimes (believe it or not) desirable for some customers. The API DLLs are completely backward compatible so (in most cases) you won't get any kind of "runtime" error if this is happening... but if is happening for you, it would explain why mgDelete is NOT deleting the extension data (since 4.2 is the first version in which mgDelete handled extensions correctly).


To verify your app is "finding" and "running" with the correct version of the API, watch the output of your app. When you call mgInit, the following should be displayed in the command shell window:


I: OpenFlight API version 4.2.0.

I: Site <FLTDATA> registered for plugin <OpenFlight Data Dictionary>.

I: Plugin <fltdata.dll> loaded.


This shows you what version of the API the app is actually running with.


Can you verify that you are running with 4.2?

Original Post by: MattN Wed Feb 27 16:55:56 2013


Thanks for the quick reply. It's a stand-alone app that is exhibiting this behaviour...

Original Post by: SteveThompson Wed Feb 27 16:53:44 2013


I'll dig a little deeper... and just to confirm... are you're running a stand-alone app, plug-in or script?

Original Post by: MattN Wed Feb 27 16:49:12 2013


I'm using 4.2 too. If I open an existing flt model that has a node within it that has extended attribution, and then try and delete that extended attribution record from it, it fails; if I duplicate that node and operate on the duplicate version, it works. It's as if the original node is protected...


Huh? :-|


Thanks for your time...

Original Post by: SteveThompson Wed Feb 27 16:35:11 2013


.....the only way I can get the mgDelete() of an extension record to work is to duplicate the node that I want to remove it from, perform the extension deletion upon the duplicate, and then replace the original node with the duplicated/modified node. Any thoughts?

Hmmm... what version of the API are you using? I verified that this works in 4.2.

Original Post by: SteveThompson Wed Feb 27 16:32:54 2013


I guess I was suggesting that, via the API, when you directly assign an extension a value, the checkbox within Creator (obviously) became enabled; if withini the API no extension attributes were assigned then the checkbox remained disabled within Creator.

That is correct... I just wanted to stress that the attributes on any tab are "all" or "none". They are an indivisible block.

Original Post by: MattN Wed Feb 27 10:07:24 2013


.....the only way I can get the mgDelete() of an extension record to work is to duplicate the node that I want to remove it from, perform the extension deletion upon the duplicate, and then replace the original node with the duplicated/modified node. Any thoughts?

Original Post by: MattN Wed Feb 27 09:16:44 2013


Hi Steve,


I guess I was suggesting that, via the API, when you directly assign an extension a value, the checkbox within Creator (obviously) became enabled; if withini the API no extension attributes were assigned then the checkbox remained disabled within Creator.


Yep, I was fully aware of the the per-node enable/add disable/delete.....but hadn't noticed this ability to disable/delete before. The reason I was particularly interested in it is because I have been unable to get the "mgGetExtRec()" and "mgDelete()" to actually work (the extensions remain regardless), and wondered whether there was an API call I was missing (but it appears mgGetExtRec() is that function!).


Thanks for your time...

Original Post by: SteveThompson Tue Feb 26 18:44:52 2013


When you enable or disable the "Enable Extension Attribute" checkbox on an attribute page extension tab, you are "adding" or "deleting" (respectively) a block of extension data to or from the node whose attribute page you are currently viewing. You're not disabling that extension tab globally. Is that what you hope to do?


Put another way... lets say that the "Enable Extension Attribute" checkbox is checked on attribute page for group whose id is "MyGroup". That means MyGroup has that extension data attached to it. If the checkbox is unset, MyGroup DOESNOT have that extension data attached to it. As you observed when you uncheck this, Creator asks you :

<Verify Delete Extension - This will delete the extension data from # node>

It is verifying that you want to remove that extension data from that node because the action is destructive wrt the node.


You can remove extension data from a node programmatically as follows. This example removes extension data record (whose code is "MyExtension") from node "rec":


// This is C code but it also works in OpenFlight Script

// get the extension record identified by MyExtension

// if extension is NOT attached to rec, will return MG_NULL

extRec = mgGetExtRec (rec, MyExtension);

// if you got one, simply "delete" it

// this "removes" the extension record from "rec"

mgDelete (extRec);


Again, this function only removes the extension data from a specific node. If you want to remove extension data from all nodes, you'd have to mgWalk or otherwise visit each node and remove the data explicitly.


...I never knew you could enable/disable this tick box directly for each extension tab, I thought it simply became enabled as soon as you set one of the tab’s extension attributes and remained unticked if none of the extensions were set).

This is not quite right. All the data fields on a single extension tab comprise one "atomic" extension block. i.e., Your node either has ALL the data on the tab or NONE of the data on the tab. Your node can't have some but not others.


I hope this makes sense.

Login to post a comment