[Qt-interest] Question SLOT Macro & messing with the QObject::connect method
Dan Milburn
danmilburn at clara.co.uk
Fri Feb 5 09:26:21 CET 2010
Replying to myself because the second option isn't right. The macro of
course needs to be used at the point you construct the string.
Otherwise you will need to just prepend the '1' to the string yourself.
But using the macro at the point the string is originally constructed is
easier.
Dan
>
>> 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.
More information about the Qt-interest-old
mailing list