On 03/16/2011 03:43 PM, Vishesh Handa wrote: > > > On Wed, Mar 16, 2011 at 8:01 PM, Sebastian Trüg <tr...@kde.org > <mailto:tr...@kde.org>> wrote: > > On 03/16/2011 03:20 PM, Vishesh Handa wrote: > > > > > > On Wed, Mar 16, 2011 at 7:37 PM, Sebastian Trüg <tr...@kde.org > <mailto:tr...@kde.org> > > <mailto:tr...@kde.org <mailto:tr...@kde.org>>> wrote: > > > > OK, so we only need a stopQuery() in the setQuery method, > right? IMHO > > that is much cleaner and easier to understand than setting > current query > > to 0. > > > > > > That too won't work. Here is why - > > > > You run a query A, it finishes executing itself and then deletes > itself. > > You then run query B, it will try to stop query A by deleting it. But > > since it has already been deleted - Crash. > > i dont think so. The query deletes itself async and before that emits > the finished signal which results in m_currentQuery being set to 0.... > aha, that is what is missing! > > > I tried that. The problem is that I still gets 1 result from the old query. > Try it out - > run - select ?r where { ?r nie:url ?url . } > and then - > select ?url where { ?r nie:url ?url . } LIMIT 10 > while the first query is still running.
I fixed that now. Got a bit confused. I agree that your solution uses less code but IMHO it is cleaner to disconnect the old query instead of checking the pointer in the query result slot. If you feel strongly about it we can revert though.... Cheers, Sebastian > > The only way I could think of solving this was by checking if the > query > > we were getting results for was the m_currentQuery, and otherwise > > deleting it. That code was removed in the patch provided. > > > > > > On 03/16/2011 02:58 PM, Vishesh Handa wrote: > > > This patch ( now committed ) is not that useful. > > > > > > The only thing it does is sets the time elapsed when you > click the > > "Stop > > > Query" button. And it removes the old code which allowed you to > > > automatically stop the old query if you ran a new one. > > > > > > When a query finishes execution, or is closed, it automatically > > deletes > > > itself and therefore disconnects itself from all signals and > slots. > > > > > > I know the setting of 'd->m_currentQuery = 0' was not completely > > > obvious. But it did what it was supposed to. The query if it > was still > > > being executed would have been deleted when more results > were received > > > in slotNextResultReady() > > > > > > I'll either revert this patch or fix it. > > > > > > On Wed, Mar 16, 2011 at 4:37 PM, Who Knows <who...@gmail.com > <mailto:who...@gmail.com> > > <mailto:who...@gmail.com <mailto:who...@gmail.com>> > > > <mailto:who...@gmail.com <mailto:who...@gmail.com> > <mailto:who...@gmail.com <mailto:who...@gmail.com>>>> wrote: > > > > > > The previous patch affected the copyright somehow so i am > > sending a > > > new one. > > > > > > > > > - Smit Shah (My real name) > > > > > > _______________________________________________ > > > Nepomuk mailing list > > > Nepomuk@kde.org <mailto:Nepomuk@kde.org> > <mailto:Nepomuk@kde.org <mailto:Nepomuk@kde.org>> > > <mailto:Nepomuk@kde.org <mailto:Nepomuk@kde.org> > <mailto:Nepomuk@kde.org <mailto:Nepomuk@kde.org>>> > > > https://mail.kde.org/mailman/listinfo/nepomuk > > > > > > > > > > > > > > > -- > > > Vishesh Handa > > > > > > > > > > > > _______________________________________________ > > > Nepomuk mailing list > > > Nepomuk@kde.org <mailto:Nepomuk@kde.org> > <mailto:Nepomuk@kde.org <mailto:Nepomuk@kde.org>> > > > https://mail.kde.org/mailman/listinfo/nepomuk > > _______________________________________________ > > Nepomuk mailing list > > Nepomuk@kde.org <mailto:Nepomuk@kde.org> > <mailto:Nepomuk@kde.org <mailto:Nepomuk@kde.org>> > > https://mail.kde.org/mailman/listinfo/nepomuk > > > > > > > > > > -- > > Vishesh Handa > > > > > -- > Vishesh Handa _______________________________________________ Nepomuk mailing list Nepomuk@kde.org https://mail.kde.org/mailman/listinfo/nepomuk
