Preventing Object Deletion Between PlugIn Calls

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Preventing Object Deletion Between PlugIn Calls

rgoffena
BACKGROUND:
I have a plugin which sequentially invokes a number of other plugins:
PlugInRunner::execute
{
   SpatialDataView* pView = currentDisplayedSpatialDataView();
   ProgressResource pProgress;

   ExecutableResource1 pAlgorithm1("algorithm1", "", pProgress.get(), false)
   PlugInArgList& pArgs1 = pAlgorithm1.getPlugInArgList();
   pArgs1->setPlugInArgValue( "View", pView );
   pAlgorithm1.execute();

   ExecutableResource pAlgorithm2("algorithm1", "", pProgress.get(), false)
   PlugInArgList& pArgs1 = pAlgorithm2.getPlugInArgList();
   pArgs1->setPlugInArgValue( "View", pView );
   pAlgorithm2.execute();

   ExecutableResource pAlgorithm3("algorithm1", "", pProgress.get(), false)
   PlugInArgList& pArgs1 = pAlgorithm3.getPlugInArgList();
   pArgs1->setPlugInArgValue( "View", pView );
   pAlgorithm3.execute();
}

Currently, with my code, the user is potentially able to close the view at certain times, and this can cause an application crash.

Todd indicated this could happen because the Qt is accepting user input for a short time when the progress dialog is first displayed for each plugin (thusly allowing the user to click the close button on the spatial data window.)


POSSIBLE SOLUTIONS:
1) Pass an AttachmentPtr<SpatialDataView> to the PlugInArgLists as a void ptr.  Each plugin would check for a null spatial data view.
2) Modify Opticks so that windows other than the progress dialog will not accept user input when the progress dialog is first updated in each plugin (thusly preventing Qt from receiving the user click on the spatial data window's x-button).


QUESTIONS:
1) Can anyone recommend another way to prevent the user from closing the spatial data view, in between execution of algorithm1, algorithm2, and algorithm3?  
2) Similar behavior may be exhibited with Opticks wizards.  Has anyone seen this behavior with Opticks wizards?
3) Is there a need/desire to provide PlugInArg types of AttachmentPtr<RasterElement>, AttachmentPtr<SpatialDataView>, etc, in addition to the already supplied PlugInArg types of RasterElement, SpatialDataView, etc?


Robert Goffena
Ball Aerospace & Technologies Corp.
2875 Presidential Dr.
Fairborn, OH 45324-6269
Phone:  (937) 320-4096
Fax:  (937) 429-1687
Email:  [hidden email]




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Preventing Object Deletion Between PlugIn Calls

Kip Streithorst
Administrator
The other option you have available to you is to make sure that the ProgressDlg stays visible the entire time, because when the dialog is visible it is modal preventing the user from performing any other action.  You can accomplish that as follows:

PlugInRunner::execute
{
   Service<ConfigurationSetttings>()->setSessionSetting(Progress::getSettingAutoCloseKey(), false);
   ProgressResource pProgress;
   pProgress->updateText("Text", 1, NORMAL);
   SpatialDataView* pView = currentDisplayedSpatialDataView();

   ExecutableResource1 pAlgorithm1("algorithm1", "", pProgress.get(), false)
   PlugInArgList& pArgs1 = pAlgorithm1.getPlugInArgList();
   pArgs1->setPlugInArgValue( "View", pView );
   pAlgorithm1.execute();

   ExecutableResource pAlgorithm2("algorithm1", "", pProgress.get(), false)
   PlugInArgList& pArgs1 = pAlgorithm2.getPlugInArgList();
   pArgs1->setPlugInArgValue( "View", pView );
   pAlgorithm2.execute();

   ExecutableResource pAlgorithm3("algorithm1", "", pProgress.get(), false)
   PlugInArgList& pArgs1 = pAlgorithm3.getPlugInArgList();
   pArgs1->setPlugInArgValue( "View", pView );
   pAlgorithm3.execute();

   Service<ConfigurationSettings>()->deleteSessionSetting(Progress::getSettingAutoCloseKey());
}

You'll notice that with the two calls to ConfigurationSettings, I have temporarily disabled the auto-close behavior of the progress dialog.  This will prevent the dialog from hiding, (i.e. releasing modality) when the progress reaches 100%.  I have moved the creation of the progress dialog before the request for the current view and I have logged some progress to the progress object before requesting the view.  This will ensure that the progress dialog is displayed (i.e. it will become modal).

This should accomplish what you're looking for.

Thanks,
Kip

-----Original Message-----
From: Goffena, Robert [mailto:[hidden email]]
Sent: Thursday, February 14, 2008 11:02 AM
To: [hidden email]
Subject: Preventing Object Deletion Between PlugIn Calls

BACKGROUND:
I have a plugin which sequentially invokes a number of other plugins:
PlugInRunner::execute
{
   SpatialDataView* pView = currentDisplayedSpatialDataView();
   ProgressResource pProgress;

   ExecutableResource1 pAlgorithm1("algorithm1", "", pProgress.get(), false)
   PlugInArgList& pArgs1 = pAlgorithm1.getPlugInArgList();
   pArgs1->setPlugInArgValue( "View", pView );
   pAlgorithm1.execute();

   ExecutableResource pAlgorithm2("algorithm1", "", pProgress.get(), false)
   PlugInArgList& pArgs1 = pAlgorithm2.getPlugInArgList();
   pArgs1->setPlugInArgValue( "View", pView );
   pAlgorithm2.execute();

   ExecutableResource pAlgorithm3("algorithm1", "", pProgress.get(), false)
   PlugInArgList& pArgs1 = pAlgorithm3.getPlugInArgList();
   pArgs1->setPlugInArgValue( "View", pView );
   pAlgorithm3.execute();
}

Currently, with my code, the user is potentially able to close the view at certain times, and this can cause an application crash.

Todd indicated this could happen because the Qt is accepting user input for a short time when the progress dialog is first displayed for each plugin (thusly allowing the user to click the close button on the spatial data window.)


POSSIBLE SOLUTIONS:
1) Pass an AttachmentPtr<SpatialDataView> to the PlugInArgLists as a void ptr.  Each plugin would check for a null spatial data view.
2) Modify Opticks so that windows other than the progress dialog will not accept user input when the progress dialog is first updated in each plugin (thusly preventing Qt from receiving the user click on the spatial data window's x-button).


QUESTIONS:
1) Can anyone recommend another way to prevent the user from closing the spatial data view, in between execution of algorithm1, algorithm2, and algorithm3?  
2) Similar behavior may be exhibited with Opticks wizards.  Has anyone seen this behavior with Opticks wizards?
3) Is there a need/desire to provide PlugInArg types of AttachmentPtr<RasterElement>, AttachmentPtr<SpatialDataView>, etc, in addition to the already supplied PlugInArg types of RasterElement, SpatialDataView, etc?


Robert Goffena
Ball Aerospace & Technologies Corp.
2875 Presidential Dr.
Fairborn, OH 45324-6269
Phone:  (937) 320-4096
Fax:  (937) 429-1687
Email:  [hidden email]




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...