Subject: coredumps with Destroy...

From: [email-masked]
Date: Mon, 16 Nov 1998 10:49:48 +0100

fvwm2 coredumps if a function or menu destroys itself
(via DestryMenu or DestroyFunc). Any idead how to avoid
this?

  AddToFunc suicide
   + "I" DestroyFunc suicide

I was thinking about a counter that is increased every time
that a function is called and decreased if the function ends.
Only functions/menus with zero count can be destroyed.

Another problem are recursive functions.

  AddToFunc recurse
   + "I" Function recurse

This coredumps too after a while.

The whole chain of functions could be aborted if the counter
reaches a recursion depth of x. Or better have a global counter
for recursion depth (i.e. passed to subfunctions).

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Michael M Han <[email-masked]>
Date: Mon, 16 Nov 1998 09:58:59 -0800

Previously...
>Only functions/menus with zero count can be destroyed.

I seem to remember this being mentioned in the past. I forget exactly
why this occurs. I was digging around in ComplexFunction() yesterday
though... It probably has something to do with ComplexFunction()
iterating over mi's, which are about to get clobbered by the
DestroyFunc... maybe before setting mi=mi->next, there should be a
quick check to see if mi is still around, and break if it's gone
missing? Though really elegant would be to allow for functions like:

AddToFunc dynamic-func "I" DestroyFunc dynamic-func
+ "I" foo
+ "I" bar

where foo & bar are Reads, PipeReads, etc... Not sure about how to
handle something like that.

>for recursion depth (i.e. passed to subfunctions).

Hah, that's funny. Also very ugly is binding a function "I" to a
keyboard shortcut and having autorepeat... That really bent fvwm out
of shape.

Incidentally, does anyone know what in the world "CLICK_AND_A_HALF" is
all about? It's not at all documented, from what I can tell...
_________
mike ([email-masked])
Indian burns are not our cultural heritage
 - The collected wisdom of Bart Simpson
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked]
Date: Mon, 16 Nov 1998 18:58:25 +0100

> all about? It's not at all documented, from what I can tell...

Press button, release button, press button.

Bye

Dominik

---

From: Michael M Han <[email-masked]>
Date: Mon, 16 Nov 1998 10:13:11 -0800

Previously...
>Press button, release button, press button.

Well, yeah, the code revealed that much to me, but I was more
referring to the fact that there's an undocumented feature in fvwm,
which AFAICT has been around for as long as I've used fvwm, that I
never knew about because it's undocumented.

I guess more to the point, should click and a half functions exist? If
so, it should be documented. If not, not.
_________
mike ([email-masked])
I will not sleep through my education
 - The collected wisdom of Bart Simpson
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked]
Date: Mon, 16 Nov 1998 19:12:15 +0100

> so, it should be documented. If not, not.

If my memory is correct there is no one-and-a-half click for functions
(although it would be cool). I think that was used only for some
obscure bugfix or feature somewhere.

Bye

Dominik