On Tue, May 31, 2011 at 10:14 AM, Koen Deforche <[email protected]> wrote:
> Hey Gaetano,
>
> 2011/5/26 Gaetano Mendola <[email protected]>:
>> Hi all,
>> In our application we have some realtime plotting (using
>> Wt::Chart::WCartesianChart), when our application
>> decide to plot something is uses a method plot of our class WtTerminal::plot.
>>
>> WtTerminal::plot does (more or less):
>>
>> Wt::WStandardItemModel* myDataModelBuffer = new
>> Wt::WStandardItemModel(...)
>> Wt::WServer::instance()->post(theSessionId,
>>
>> boost::bind(&WtTerminal::swapModel,
>> this,
>>
>> myDataModelBuffer));
>>
>> WtTerminal has inside a pointer to the chart and the method swapModel
>> uses the setModel on the chart,
>> deleting the old one.
>>
>> The problem arises when the instance of WtTerminal is destroyed and
>> there are still pending posts.
>
> So you have a situation where the WApplication is still alive but the
> WtTerminal view is destroyed ? Then indeed you cannot simply bind a
> method of WtTerminal to the POST. You should then post to your
> application and from your application decide whether you can deliver
> the event to the WtTerminal.
>
>> What we plan to do is to put in queue of posts a boost::shared_pointer
>> to a class having the pointer
>> to the chart, so the WtTermina::plot will be something like this:
>>
>> Wt::WStandardItemModel* myDataModelBuffer = new
>> Wt::WStandardItemModel(...)
>> Wt::WServer::instance()->post(theSessionId,
>>
>> boost::bind(&ChartOwner::swapModel,
>>
>> boost::shared_pointer(theChartOwner),
>>
>> myDataModelBuffer));
>>
>> This way when the WtTerminal is destroyed and there are still pending
>> posts the ChartOwner survives
>> the WtTerminal. So far so good.
>>
>> Now the question is: the user decides to close the chart, it pushes a
>> button blocking the posts to be
>> "delivered", the chart is destroyed having a parent (being destroied),
>> when the Wt loop ends then the
>> post still in the queue are delivered but the ChartOwner has now an
>> invalid pointer!
>
> I think the best solution is to deliver the post to an object in that
> application whose existence is tied to the application existence
> (which means that in the worst case you should use the application
> itself).
That will work eventualy but I still feel Wt misses something to manage
those cases.
We solved with a class acting as a WContainerWidget but not taking the
ownership of Chart added, this is the class:
class WtContainerWidget : public Wt::WContainerWidget {
public:
WtContainerWidget(WContainerWidget *parent)
:Wt::WContainerWidget(parent),
theChart(0) {}
virtual ~WtContainerWidget() {
if ( children().size() > 0 ) {
Wt::WContainerWidget::removeWidget(theChart);
}
}
void addWidget( Wt::WWidget *aChart ) {
if ( children().size() > 0 ) {
throw std::runtime_error("WtContainerChart can own only a chart at time");
}
Wt::WContainerWidget::addWidget(aChart);
theChart = aChart;
}
private:
Wt::WWidget* theChart;
};
so we had our chart instance owned by ChartOwner to this container and when the
Wt tree is destroyed the chart inside this container is not destroyed
but simply detached.
I'm not sure if this is too gymnic or not but at least it solved our problems,
for now.
Gaetano
--
cpp-today.blogspot.com
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
