[Qt-interest] Question SLOT Macro & messing with the QObject::connect method

[kent williams]

Yes. That's what I tried before I started reading the Qt headers to
figure out what I actually needed to do.  If you do something like
this:

connect(button,SIGNAL(triggered()),this,"SLOT(handleMenuItems())");

Then you get a message like this:

Object::connect: Use the SLOT or SIGNAL macro to connect
BTMainWindow::SLOT(handleMenuItems())

Because what QObject::connect actually needs to do its job is

connect(button,SIGNAL(triggered()),this,"1handleMenuItems()");


On Thu, Feb 4, 2010 at 1:53 PM, Jefferson Bandeira <jbsilva at ufrj.br> wrote:
> Have you tried passing SLOT(handleMenuItems()) as an argument insteaf of
> "handleMenuItems()"?
>
> 2010/2/4 kent williams <nkwmailinglists at gmail.com>
>>
>> I just have the habit of turning any block of code I need to use over
>> and over again into a convenience function.  I'd think EVERYONE would
>> want to have that habit, but when I read other people's code it sure
>> seems like they're a lot more excited by Cut & Paste in their editor
>> than they are about functional decomposition as a programming
>> technique.
>>
>> Anyway Creating menus is one of those things I do more than once, so I
>> made it a function.
>>
>> So in my code I have something like this:
>>
>> QMenu *menu = new QMenu(this); // this being the main window of the
>> application
>> const char *items[] = { "First Item", "Second Item", "Third Item", 0 };
>> this->MakeMenu(menu, "handleMenuItems()", items);
>>
>> I COULD create actions one at a time and add them to the menu, but in
>> this case, I just have to write 3 lines of code. Plus, if I want to
>> change something about how my menus are constructed, I only have to
>> fix the MakeMenu method, not change the code every place I make a
>> menu.
>>
>> What it really boils down to is this: Qt defines this method for QObject:
>> bool QObject::connect( const QObject * sender,
>>                                  const char * signal,
>>                                  const QObject * receiver,
>>                                  const char * method,
>>                                  Qt::ConnectionType type =
>> Qt::AutoConnection );
>>
>> But the strings for the parameter signal and method encode their type
>> with a prepended '1', '2', or '3'.  Now I've been programming
>> computers since 1983, I really have no trouble prepending a digit on
>> my signal/slot string.  What I was asking is this:
>>
>> Is there a better way to do this that is more consistent with the
>> spirit of Qt, or did the Qt authors figure people would just read the
>> headers and hack it together the way I did?
>>
>> On Thu, Feb 4, 2010 at 1:19 PM, Jefferson Bandeira <jbsilva at ufrj.br>
>> wrote:
>> > I really can't see what exactly you're trying to do with that piece of
>> > code,
>> > are you trying to introduce Custom Slots at runtime? 'Cause i think it's
>> > not
>> > supported at all, if it's not this, could you clarify a bit what exactly
>> > are
>> > you trying to do?
>> >
>> > 2010/2/4 kent williams <nkwmailinglists at gmail.com>
>> >>
>> >> I don't think you understand what Slot does.
>> >>
>> >> #define SLOT(a) "1"#a
>> >>
>> >> # is the preprocessor 'stringify' operation.  It takes the argument
>> >> and turns it into a string literal. For example
>> >> SLOT(kickme())
>> >>
>> >> is turned by the C Preprocessor into
>> >>
>> >> "1" "kickme()"
>> >>
>> >> and since adjacent string literals are merged, it will become
>> >>
>> >> "1kickme()"
>> >>
>> >> So you can _ONLY_ use the SLOT macro at compile time.
>> >>
>> >> At runtime, say, if you want to stick a bunch of boilerplate Qt code
>> >> into a convenience function, you just can't use SLOT(), because
>> >> there's no way to go from a passed const char * parameter back to a
>> >> string literal to use for a SLOT parameter.  You  can fake it -- which
>> >> is what I do -- create a string at runtime with a literal '1'
>> >> prepended.
>> >>
>> >> The problem, as I see it, is that with respect to proper C++ the
>> >> SIGNAL/SLOT/METHOD business is stuck in the compile-time realm, even
>> >> the the whole POINT of Qt's Signals and Slots paradigm is that the
>> >> connections between signals and slots happen at runtime!
>> >>
>> >>
>> >> On Thu, Feb 4, 2010 at 11:17 AM, Ian Thomson <Ian.Thomson at iongeo.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > kent williams wrote:
>> >> >>
>> >> >> So my question is this: is there a non-evil way to get around SLOT()
>> >> >> requiring a string literal instead of a char * variable?
>> >> >
>> >> > Isn't the const char* you're talking about a literal somewhere else
>> >> > in
>> >> > your
>> >> > program? Call SLOT() on it there.
>> >> >
>> >> >
>> >> > Cheers,
>> >> > Ian.
>> >> >
>> >> _______________________________________________
>> >> Qt-interest mailing list
>> >> Qt-interest at trolltech.com
>> >> http://lists.trolltech.com/mailman/listinfo/qt-interest
>> >
>> >
>> >
>> > --
>> > Jefferson Bandeira
>> >
>> >
>> > _______________________________________________
>> > Qt-interest mailing list
>> > Qt-interest at trolltech.com
>> > http://lists.trolltech.com/mailman/listinfo/qt-interest
>> >
>> >
>>
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at trolltech.com
>> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
>
>
> --
> Jefferson Bandeira
>
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
>