i just wanted to mention that i've "resolved" the problem...
even if i didn't solve exactly what has going wrong...
it's now "effectively avoided" and that's as far as i went...
what i did was:
1 - add a DestroyFunc to precede every local function
definition i created...
2 - change the order of my MoveRaise function definition
to have the "M Move" segment before the "I Raise"
segment...
3 - change the Mouse binding for the function from
ALT-Any context to ALT-FSIW ("A M" to "A FSIW")...
(BTW: the function was already bound to "T" for
any - "A" - context)
after these changes... the "bad behavior" completely vanished...
i can't be certain which fixed it... but...
i think "1" should only effect "predefined" functions, and
i'm unaware of any predefined "MoveRaise" function...
IMHO "2" should not have a noticable effect at all...
and finally, the changes in "3" would simply remove what i
considered an "unnecessary" (but could be termed "inappropriate")
binding of the MoveRaise function to the root window...
also, the "D" binding would be removed, but i'm not completely
familiar with the possible effects of that binding yet...
finally, i should mention... the only context of Mouse action that
APPEARED to cause any problem was "W" (the old MoveRaise did exactly
what it should do on "FSIT" contexts... it even seemed to
appropriately ignore the unused "R" binding)...
anyways... all this is academic for me now...
just hoping to spread the info in case it helps someone else solve
a similar problem... and in case it helps anyone identify either
the "bug" or "what i may have been doing wrong"...
B. Karhan
[EMAIL PROTECTED]
A little birdy told me that Benjamin Karhan said:
]
] i've noticed that fvwm 2.5.25 (and the recent snapshots, like 20080322
] and 20080330 specifically) exhibits a somewhat aggravating
] behavior with window event handling (not present in the 2.4.x branch
] definately).
]
] i kept putting off mentioning it because it didn't generate
] the types of things that would be useful for debugging
] (debug messages, core dumps, error messages, etc etc)
] but it's happened frequently enough (at least a few dozen times)
] that it seems to be a genuine "bug" somewhere...
]
] the problem can generally be described as "window events do not seem
] to take effect, on occasion, until one moves the mouse"...
] specific (non-fatal, but exasperating) examples of this include:
]
] - window title updates: title occasionally doesn't update
] after the normal control-code sequence... until one moves
] the mouse pointer
]
] - window closing: sometimes a window which was closed will
] remain (albeit blank and non-functional) until one again
] moves the mouse
]
] the most problematic example (and only once so far) i've seen is:
]
] - upon using the "animated window move" through a keyboard
] sequence, the window would not move until one moved the
] mouse, and after the window moved the mouse (although
] still present and "movable" around the screen) ceased to
] function as a "pointer" (i.e. no clicking registered,
] no focus changes, etc)
]
] i've built the above versions on CentOS4.6, CentOS 5.1, Slackware 11.0,
] and Solaris 10... and it SEEMS (although i could be wrong) to have
] effected them all...
]
] anyways... just wanted to bring it to everyone's attention...
] in the hopes that it may eventually warrant some fixing...
]
] B. Karhan
] [EMAIL PROTECTED]
]
