Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Strange oid_modify_attr behavior


Strange oid_modify_attr behavior

Good day Adepters,

I'm getting some strange behavior using the oid_modify_attr() function.
I've used this function in the past with no problems, now it isn't doing
what I am asking. I've done some debugging and can see why in my script
the modify attr isn't working though entering the same information from the
command line works.

What I am attempting to do is modify an older script of mine to assign
unique IDs. I had made part of the original script grab (and if needed,
truncate the .sgm) file name, then merge this with a unique number
maintained in an external file. Well, new job wants a similar function,
only they want to have a specific REQUIRED attribute value in place of the
file name. This particular attribute can be used one or more times in a
given document. The most recent value is the one that needs to be used.
That was an easy change as long as there was a value entered.

As most of us know, Murphy was an optimist. So we also know that there
will not always be a value assigned to the REQUIRED attribute I need for my
script to work as desired. Where my problem comes up is when I have the
script searching for a value in the attribute and find it empty. I stop
the processing, open a dialog box (using a readvar -prompt) so the author
can enter a value. Then I have the script try to modify the attribute
based on the string value the author has just entered. Nothing happens.

I have entered a couple of debug statements into my script. I check the
oid value before and after I try to modify the attribute. The value is the
same. I have verified the value from the command line. Next, I decided to
see what element I was working with. It is here that I found why the
modify attribute function isn't working from the script. From the command
line, oid_name(oid_current_tag()) (I used this rather than $tagname to be
consistent with what the script would have to read) gives me the element
name containing the attribute I want to modify. In the script, the
oid_name() gives me _subchars ($tagname gives me the desired element).
Well _subchars does not contain the attribute, so nothing is changed.

Has anyone else had this happen and if so, how did you overcome it? I am
using Adept 9.0.1 with Win 2000.

Many thanks,

Lynn E. Hales
Information Techology Consultant


At 09:05 2001 01 18 -0500, wrote:
>I'm getting some strange behavior using the oid_modify_attr() function.

>In the script, the
>oid_name() gives me _subchars ($tagname gives me the desired element).
>Well _subchars does not contain the attribute, so nothing is changed.

There may be better solutions (PaulK might know), and without more
details, I can't give you a definitive answer, but I can at least
give some hints. _subchars is an oid inserted into the in-memory document
data structure (of course, not really into the persistent form of the
document itself) by Epic to help represent the generated text. It is
not an element or actual PI, but it is an oid to Epic, and your
oid_modify_attr() function is "tripping" over it.

One thing you could do is "set gentext=off" in your script first.
That should make the _subchars oid disappear, and then your
oid_modify_attr() should work.

You should realize, though, that there could be other oids "in
the way" (e.g., PIs, maybe entity boundary oids), so to make your
code more robust, you could add a loop to make sure that you always
have an element oid before you attempt oid_modify_attr() on it.

For example, if you've set "o" to what you think is the oid
of the start tag that contains the attribute in question, you
might insert something like the following to ensure that "o"
is really the oid of the element's start tag:

while (oid_valid(o) && oid_type(o) != 0) { o = oid_parent(o) }

(I don't promise this is necessarily the best way, just something
to try.)

You might also consider experimenting with oid_caret() versus
oid_current_tag() (see the online help). The latter should
only return tag objects and should return the tag that would
be affected by the modify_tag command (you could try that
command instead of the oid_modify_attr function).

I'm looking at Epic 4.0 help text, and there may be some differences
between this and Adept 9.0.1 in this area, so you may still have
some investigating to do, but I hope this gives you some avenues
to try.



Hi Lynn,

> adepters-digest Friday, 19 January 19101 Volume 02 : Number 967

[ snip ... ]