<br><br><div class="gmail_quote">On Wed, Aug 11, 2010 at 9:13 AM, John Verzani <span dir="ltr"><<a href="mailto:verzani@math.csi.cuny.edu">verzani@math.csi.cuny.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
When defining classes and setting methods (qsetClass, qsetMethod) the environment has the object "this" and "super" available to it. Would this be possible within a callback set by qconnect? In RGtk2 and tcltk there is a way to get the object within the callback without having to use global variables or pass that object in through user.data.<br clear="all">
<br>E.g., something like this<br><br>b <- Qt$QPushButton("click me")<br>qconnect(b, "pressed", function(...) print(this$text))<br><br>It is easy enough to hack qconnect to add in "this" to the environment of the handler, but I'm not sure how "super" would be done.<br>
<font color="#888888">
<br></font></blockquote><div><br><br>I agree that it would be convenient to have a pointer to the sender. I don't like the idea the idea of using 'this' though. Usually, my signal handlers are a method in another class, so 'this' would conflict. Also, conceptually it does not make sense, as the handler is usually not a method of the sender. Same with super. <br>
<br>The reason Qt does not pass the instance to the handler is that the handlers are methods that should be invokable even when there is no signal emission. Also, the handler is always a closure, with the enclosing "environment" being another instance that can easily hold a reference to the sender. This works well for me, although I can see that a simple Hello World application might run into some difficulties. Or cases where a slot is connected to many signals, but then the protected QObject::sender method is available for those using a class. Even then, many signals provide additional arguments that make the sender irrelevant.<br>
<br>We could add a 'sender' variable to the enclosure. However, qtbase is in some ways extending the R language by adding the 'this' and 'super' keywords. If possible, we should limit the number of keywords. Also, an arbitrary R function is distinct from a method, which is by definition enclosed within an instance that essentially contains the 'this' and 'super' objects. I would rather not mess with the enclosing environment of a signal handler.<br>
<br>What if we tried to bring things back towards GTK+, C# events, etc, and just have the sender passed as the first argument? Obviously, we would not want this in many cases, so it would need to be an option that is off by default. <br>
<br>qconnect(b, "pressed", function(x) print(x$text()), sender = TRUE)<br><br>Would this work?<br>Honestly, my original plan was just to have people use the user-data. If they need additional user-data, perhaps it is time to start thinking about a class.<br>
<br>Thanks,<br>Michael<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><font color="#888888">-- <br>John Verzani<br>Chair, Department of Mathematics<br>
College of Staten Island, CUNY<br><a href="mailto:verzani@math.csi.cuny.edu" target="_blank">verzani@math.csi.cuny.edu</a><br>
</font><br>_______________________________________________<br>
Qtinterfaces-devel mailing list<br>
<a href="mailto:Qtinterfaces-devel@lists.r-forge.r-project.org">Qtinterfaces-devel@lists.r-forge.r-project.org</a><br>
<a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/qtinterfaces-devel" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/qtinterfaces-devel</a><br>
<br></blockquote></div><br>