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

[Dan Milburn]

> 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())");

If that line is exactly what you're doing, then there's a good reason 
it's not working.  You've put "SLOT" in a string literal, when what you 
actually wanted to do was use the SLOT macro.

What you need is either:

MakeMenu( menu, SLOT(handleMenuItems()), items );
followed by

MakeMenu( QMenu *menu, const char *slot, items )
{
     ...
     connect( button, SIGNAL(triggered()), this, slot );
}

or use MakeMenu( menu, "handleMenuItems()", items ); and use the SLOT 
macro at the point of the connect call.

Dan

> 
> 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.