> I've been trying to squash some usability annoyances lately. One issue
> I've had is that I have a global key event handler that should catch the
> enter key (user selects a file in the list window, then presses enter to
> automatically run the preferred associated app for that kind of file).
> The associated app is launched with a call to system(), so it is running
> as a separate process. For sample, the associated app may be the vi text
> editor running in a terminal shell:
>
> system("aterm -e vi $FILE &");
>
> The user looks at/changes the file and eventually closes it by typing
>
> :q[enter]
>
> Now, back in my filemanager, a shortcut keypress is passed to the global
> key handler callback function with the enter key event. It seems that the
> child process and it's window does not fully consume the enter key press
> event, but it gets duplicated back up to the parent (the file manager).
Hmm, I wonder if "system" is the best way to do this? A long (long) time ago I
wrote a filemanager and ended up *not* using system to invoke the clicked-on
items, as I was getting all manner of weirdness (though probably due to my
dodgy code...)
Oh, I see that Matt suggests trying to fork first - that might be a Good Idea!
Indeed, I'll stop now, it looks like Matt's ideas are better then mine...
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
