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

Modify event: advice needed

Newbie

Modify event: advice needed

I have been trying to create "dynamic gentext" for a simple DTD
we have. Since the DTD (and FOSI) is simple, there is no noticeable
overhead associated with regenerating gentext continuosly.

However, I have now run out of ideas. My initial approach was to
use the insert_tag hook, which allowed me to regenerate whenever
a tag was inserted. I then went on to use the cut and paste
hooks, but discovered they are not triggered when removing tags
with backspace, but I can live with that.

What has me completely at a loss is to find out if the attribytes
of a tag has been modified. The modify_tag hook is useless in
this case since it is called _before_ the modify attribute
panel shows up, so at that time I do not know what the value will be.

What would be elegant would be to have just two callbacks, one
called whenever a tag is inserted or deleted (after the event),
and one whenever a tag is modified (once again, after the event).

I considered remapping modify_tag, I seem to remember that there is
a way of accessing the buitin commands even when there is an
alias of the same name, but I can't find anything in the documentation.

Something like this would solve the problem (I think):

alias modify_tag {
builtin modify_tag
set gentext = on
}

Is there a simpler solution that I have overlooked or is this as hard
as it seems ? Has anybody been doing something similar ?

Per-ÃÂ
ke Ling
--
Per-ÃÂ
ke Ling (note: Per-Åke, transliteration Per-Ake)
email: Per-Ake.Ling@uab.ericsson.se phone: +46 8 727 5674
Ericsson Utvecklings AB mobile: +46 70 790 2446
AXE Research and Development fax: +46 8 727 3463
Tags (2)
3 REPLIES 3

Modify event: advice needed

Per-ÃÂ
ke,

> I seem to remember that there is
> a way of accessing the buitin commands even when there is an
> alias of the same name

the way I changed change_tag to make it work on the element where the
caret is, rather than the element *to the left* of the caret (which
was causing everybody to spend hours scratching their heads in
wonderment) is this, and I believe you should be able to modify it
for your purposes:

function change_tag(tag=")
{
select_element(1);
caret 0,+1;
if ( "$tag" == " )
{
change_tag -panel
}
else
{
change_tag $tag
}
}
alias change_tag {
change_tag("$1")
}

alias ct {
change_tag("$1")
}

as you can see, you can access the built-in change_tag from within the
function, even though you've aliased change_tag to call the function 😉
pretty cool...

Eduardo

Modify event: advice needed

I'm now at a point of total frustration:

First I tried the obvious solution (thanks to Eduardo Gutentag and
Paul Klock):

alias modify_tag {
main::modify_tag
set gentext = on
}

but it didn't work. After doing

alias modify_tag {
response("MT1")
main::modify_tag
response("MT2")
set gentext = on
}

I discovered that as soon as the attribute panel appears, the second response
was called, so this solution was out (after some thought I realized that
if this had worked, then the attribute panel would be blocking the
edit window, which it obviously doesn't).

Second, thanks to a creative and unorthodox suggestion from Allen Seifert
I tried the following:

function windowDestroyCB(win_id) {
response("wd_cb: >$win_id$doc$oid$sdoc_id$op$win_id$doc$oid$sdoc_id$op$win_id

Modify event: advice needed

The modify_tag callback hands the callback function the
window ID of the dialog (modify tag dialogs were "docs"
in the 5.0.x days--this is no longer true). The "sdoc_id"
argument below:

modifyTagCallback(doc, oid, sdoc_id, op)

is actually a window id. So the appropriate callback to
register should be a window-level destroy callback, e.g.,

window_set(sdoc_id,"destroyCallback","windowDestroyCB")

You are then faced with detecting whether or not attributes
have changed (could do an array compare of oid_attr_list()
before and after). set gentext=on if the lists are different.

If there's a timing problem, you can consider using a
timer_add_callback function to delay the gentext-setting,
but I don't think this will be the case.

Paul