[REBOL] Re: Field event "missing in action"
From: gjones05:mail:orion at: 18-May-2001 5:56
From: "Brett Handley"
> It seems to me that the action of a field is coded to fire
> when edits to the field are finalised by moving off the
> field to another face. But it looks like a close window
> event is not included.
>.. clicking on the close - window
> icon ie the X at the top right
> of the window does not activate the alert... I'm
> wondering how I can get it to fire.
> I know I can trap the close event using detect
> but I don't know how I can use this to solve the
> above problem.
> Why am I doing this? The obvious, set a dirty
> flag. I know a dirty? flag exists in fields and
> that one can trawl through all the entry fields to
> check if any are dirty, but I just want to approach
> it from another viewpoint - besides my application
> works "perfectly" except for trapping of the first
> change and then close window.
I'm not yet fully awake this morning, so my skills in articulation will
likely be in even worse form than usual!
However, if I recall correctly, clicking the close window icon
(actually, any of the icons) on the top of the window frame is occurring
in a different event space (I can't remember the official jargon) than
the rest of the events detected *within* the frame. Purposeful or not,
this leads to the "standard" Windows behavior (at least the Microsoft
version) that clicking that icon allows for all changes to be ignored
(except when the programmer has explicitly programmed in "Apply"
button -type logic). It seems that this is a Windows
feature/deficiency, and not a REBOL oversite. It appears that you
already know (or suspect) this to be the case.
Outside of a work-around methods that you were hinting about, I can only
wish you the best of luck trying to intercept this event in a more
elegeant way from within REBOL. A few years back, I was writing some
console utilities in Delphi 2 that assisted my ISAPI interface to IIS.
I don't recall the circumstances, but I do recall needing to explicitly
close these windows under certain circumstances from inside other
processes. While this might be a more trivial task in a
Unix-variant, it proved to be a real challenge for me in Windows 95. My
brother's work group had tried to solve a similar problem from Visual
BASIC, and he said that they ultimately gave up, and switched to a
totally different programming paradigm. Undaunted, I scoured the
Microsoft documentation on the API's and finally got a solution only by
using the lowest-level API's for spawning processes, so that I could
retain hooks into those processes. Maybe this task is easier now, or
maybe a "real" programmer could have done it more easily, but this was
one of the most challenging tasks I ever undertook.
Excuse my long-winded way of trying to encourage you to use a
work-around if you need the functionality. I get the hives just
thinking about the alternative. Another nice work-around might be to
continuously update the word assigment from the field as each letter is
typed, so that changes in the field are always trapped. Or trapping for
any change in the mouse cursor captures the field data. I don't know
whether the Alt-F4 can be trapped from within REBOL.
Good luck, and feel free to walk to the beat of a different drummer if
the mood strikes! And let me know, please, out of curiosity, if you
find a simple solution.