PDA

View Full Version : Access a class without using Signals/Slots



impeteperry
10th January 2010, 00:01
Hi.
I have
connect ( newProject, SIGNAL ( returnUserInput ( QString, QString ) ),
existProject, SLOT ( slotReturnUserInput ( QString, QString ) ) );
What would the code be if I didn't use the Signal/Slot procedure to accomplish the same thing?

Thanks

Note: my email has changed to "edperry26@gmail.com"

squidge
10th January 2010, 00:27
newProject would have to contain a class pointer to existProject and call the function directly, just as a standard C++ method call. Yeuck.

impeteperry
10th January 2010, 02:35
Thanks Yeuck, but that is what I'm looking for. In my 84 years there are a lot things I've forgoteen. I started programming in 1970. long btfore C, C++, windows Etc. Since 2000, I've been using Linux, and Qt since I heard of it. (I can't remember when). I am having trouble and/or patience in relearning a language I haven't used in ten years or so and thought this might be a simple way getting a translation from Singnal/Slots to C++.

Thanks again for you reply

pete Perry

waynew
10th January 2010, 02:56
Pete - also being an old timer and not used to OOP, when all else fails, I just use a global variable. Not elegant, but it works.

impeteperry
10th January 2010, 05:36
What I need is the actual C++ code to do what I showed in my Signal/Slots. I did a lot o programming in C++ when I was programming in "XP" and before MS, but I think seeing the actual C++ version of my Qt sample will be most helpful in triggering my old weary mind.

Thanks

squidge
10th January 2010, 12:14
Well, the connect call doesn't translate to much, but if we add a signal emit also, you'll get something like this:



CLASS B;
CLASS A
{
public:
B *bptr;
void somefunc();
};

CLASS B
{
public:
slotReturnUserInput(QString qs1, QString qs2);
};

void A::somefunc()
{
bptr->slotReturnUserInput("sometext","sometext");
}

void B::slotReturnUserInput(QString qs1, QString qs2)
{
some code
}


Personally however, if your going along that route, I'd use "getUserInput" in class A and get class B to call it, rather than having class A call back class B, which is just nasty and not self-contained.