Skip to main content
1-Visitor
January 22, 2010
Question

Another ACL question

  • January 22, 2010
  • 6 replies
  • 1557 views
Greetings Adepters,

We have an ACL which is exhibiting some strange behavior (to us, anyway).

Here's a code snippet:

# Make sure the original element can be removed, i.e., it's not a required element
oid_select(obj, 0, 1, 1);
if(cut_valid()==0)
{
undo;
response("This element cannot have its context swapped because it is a required element. You may be able to insert the context counterpart for this element.");
return;
}

# Remove the existing element
oid_delete(obj);
response("deleted");

# See if the "new" element can be inserted here
if(in_context(newElem)==0)
{
response("The element " . newElem . " can not be created here because it will invalidate the document.");
undo;
return;
}

insert_string -sgml "$xformresult";

****END SNIPPET****

This code works fine as is, but if you comment out the 'response("deleted");' it fails by somehow determining that the new element cannot be inserted here, even though it is valid, per the DTD.
We tried a "wait" command in place of the response, but that doesn't seem to have any effect.

Does anyone have a clue?



    6 replies

    1-Visitor
    January 22, 2010
    Did you try : redisplay after the oid_delete ?



    Yves DENIARD
    Systèmes d'Information Logistique
    MBDA France
    1, avenue Réaumur
    92358 le Plessis-Robinson CEDEX
    tél. : 01.71.54.27.39
    mail : yves.deniard@mbda-systems.com <">mailto:yves.deniard@mbda.fr>
    ebenton1-VisitorAuthor
    1-Visitor
    January 22, 2010
    Not yet. We will let you know the results.
    ebenton1-VisitorAuthor
    1-Visitor
    January 22, 2010
    Thank you. That seems to work. Unfortunately, it makes the whole Editor window go white while it redraws the screen. I wonder if there is a more elegant way to do this.

    Thanks again.
    1-Visitor
    January 22, 2010
    The problem (I think) is that EPIC, if you delete the current oid doesn't know its new current oid.

    So may be if you memorise (in $my_oid_before), before the oid_delete command, the oid of the object placed just before the one you want to delete, you will be able to use :

    goto_oid($my_oid_before,-3);

    to place EPIC just after the end of the tag pointed by my_oid_before. (using $ at the beginning of the variable if you are not in a function)



    Note : another problem of redisplay is that it will slow down excessivly your program if you use it many times.

    Yves DENIARD
    Systèmes d'Information Logistique
    MBDA France
    1, avenue Réaumur
    92358 le Plessis-Robinson CEDEX
    tél. : 01.71.54.27.39
    mail : yves.deniard@mbda-systems.com <">mailto:yves.deniard@mbda.fr>
    1-Visitor
    January 22, 2010
    Don't keep using redisplay if you try the oid solution that is (if oid_to_delete is the oid to delete) :

    If (oid_prev(oid_to_delete)==oid_null()){

    oidbefore=oid_parent(oid_to_delete);

    typeoid="oidparent";

    }else{

    oidbefore=oid_prev(oid_to_delete);

    typeoid="oidprev";

    }

    Here : Your delete command

    If (typeoid=="oidprev"){

    #placement after the end tag of the preceding sibling

    goto_oid(oidbefore,-3)

    }else{

    #placement after the start tag of the parent

    goto_oid(oidbefore,0)

    }

    Here your insert command.



    I would like to know an easier way if exists !!



    Have a good WE.

    Yves DENIARD
    Systèmes d'Information Logistique
    MBDA France
    1, avenue Réaumur
    92358 le Plessis-Robinson CEDEX
    tél. : 01.71.54.27.39
    mail : yves.deniard@mbda-systems.com <">mailto:yves.deniard@mbda.fr>
    January 22, 2010
    I suggest you file a call about this one. I had a quick chat internally
    and it might be something we fixed in a recent release but we are not
    sure. But whatever it is, this is not the correct behavior.



    John Dreystadt
    Software Development Director
    Arbortext - PTC
    734-352-2835
    -