faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: True RAD still missing in KDevelop 3.4
by slougi on Tuesday 20/Mar/2007, @02:52
|
| Ok, and I did know that. Perhaps I posted in haste. However, the usual model is to connect to the QAbstractButton::clicked signal, and not to reimplement the event handlers. I'd argue that reimplementing an event handler is quite a lot more involved than responding to a signal. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: True RAD still missing in KDevelop 3.4
by slougi on Tuesday 20/Mar/2007, @03:12
|
Adding to my previous post (again having posted to quickly :), there is also the issue of which event handler to reimplement.
Let's take the simple mouse click. For correct handling, the mouseReleaseEvent is probably correct, and if you want to go there it could probably be automated in the IDE to reimplement this function. Were it not automated, it would be quite easy to make the mistake of reimplementing for instance mousePressEvent, at which point the applications behaviour would deviate from other applications.
Also, as far as I know, Qt events differ from Delphi events in several aspects. It's been a while since I wrote any delphi code, but as I recall events there are more like static slot connections. That is, a certain callback is defined (usually in the form holding e.g. the button), and the button from which the event originated is passed as a parameter. I don't have any profound insights (not that I usually have any :) on what this difference means, just pointing it out.
QMetaObject::connectSlotsByName could probably be used in an IDE to achieve something similar to Delphi.
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|