<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello David,<br>
<br>
Thanks for your message.<br>
For comparison, i am afraid that nobody would expect that events from<br>
the mouse would be detected and processed with any<br>
xgetmouse_left(..), xgetmouse_right(..), xgetmouse_center(..), <br>
xgetmouse_wheel(...)<br>
mouse family, according to the triggering button, rather than simply<br>
xgetmouse(...)<br>
<br>
Yet, it is somewhat what it is presently proposed for windows events.<br>
<br>
If a case-processing would certainly be required, it is a common
situation.<br>
A switch with 100 alternatives may be said as big, with 5 ones: is
likely <br>
very common.<br>
<br>
By the way, as you have noticed, with a single callback, an action that
<br>
should be done for several types of events could be written only once.<br>
<br>
>From defining a common callback function myWindowEventHandler(trigger,
params)<br>
called by <br>
<font face="Arial"><font face="Courier New, Courier, monospace">resizefcn
= </font></font><tt>"</tt><tt>myWindowEventHandler(''resize'',...)"</tt><br>
or by <br>
<font face="Arial"><font face="Courier New, Courier, monospace">closerequestfcn
</font></font><tt>= "</tt><tt>myWindowEventHandler(''close'',...)</tt><tt>"</tt><font
face="Arial"><font face="Courier New, Courier, monospace"><br>
</font></font>or by <br>
<font face="Arial"><font face="Courier New, Courier, monospace">iconifyfcn
=</font></font><tt> "</tt><tt>myWindowEventHandler(''iconify'',...)</tt><tt>"</tt><font
face="Arial"><font face="Courier New, Courier, monospace"><br>
</font></font>to only<br>
<tt>callback = "myWindowEventHandler(...)"</tt><br>
the trigger'sid being implicitly passed to the handler in argin#1<br>
there is a small step resuming N similar properties into a single one.<br>
<br>
IMO, multiplying very similar properties does not make at all the <br>
language clearer. There are already quite numerous examples<br>
in Scilab of such similar ungathered features that make the language<br>
rather obscur.<br>
<br>
This is why this kind of situation should be discussed and if possible<br>
avoided before being implemented, spread, and used. <br>
Afterwards, backcompatibility issues are somewhat locking.<br>
<br>
Regards<br>
Samuel<br>
<br>
Le 26/07/2012 08:22, David Chèze a écrit :
<blockquote cite="mid:1343283763410-4024638.post@n3.nabble.com"
type="cite">
<pre wrap="">Hi Samuel,
compared by other similar programming language that provide a GUI maker, as
far i know, events are generated very specifically for each target behavior,
1 event <=> 1 callback function : i guess it is to keep function code as
short/clear as possible, by preventing kind of big switch{} or if then
elseif... The drawback is that it's not so easy to manage common behavior
for similar events and the whole code is then bigger, maybe more risk to
write wrong things in that case.
David
--
View this message in context: <a class="moz-txt-link-freetext" href="http://mailinglists.scilab.org/General-callback-for-events-on-figures-tp4024637p4024638.html">http://mailinglists.scilab.org/General-callback-for-events-on-figures-tp4024637p4024638.html</a>
Sent from the Scilab users - Mailing Lists Archives mailing list archive at Nabble.com.
--
To unsubscribe from this mailing-list, please send an empty mail to
<a class="moz-txt-link-abbreviated" href="mailto:users-unsubscribe@lists.scilab.org">users-unsubscribe@lists.scilab.org</a>
To check the archives of this mailing list, see
<a class="moz-txt-link-freetext" href="http://mailinglists.scilab.org/">http://mailinglists.scilab.org/</a>
</pre>
</blockquote>
<br>
</body>
</html>