deleteWindow causes crash on exit

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

deleteWindow causes crash on exit

John Tobe

The EIP Auto Products algorithm creates product windows for each product and then deletes them using DesktopServices’ deleteWindow method.  In 4.1.1 this causes a crash on exit to occur however.  It looks like the problem occurs when the slots are being cleaned up.  This may have existed in 4.1.0 too, but I don’t remember it happening before that.  Any thoughts on what might be wrong?

 

John Tobe

Ball Aerospace & Technologies

2875 Presidential Drive, Suite 180

work: 937-320-4045

cell: 937-477-0691

 


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.
Reply | Threaded
Open this post in threaded view
|

RE: deleteWindow causes crash on exit

Kip Streithorst
Administrator

When and how does your plug-in delete the product windows?  In response to the SIGNAL_NAME(SessionManager, Closed)?  In it’s destructor?  Or another way?

 

Thanks,

Kip

 


From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 11:47 AM
To: [hidden email]
Subject: deleteWindow causes crash on exit

 

The EIP Auto Products algorithm creates product windows for each product and then deletes them using DesktopServices’ deleteWindow method.  In 4.1.1 this causes a crash on exit to occur however.  It looks like the problem occurs when the slots are being cleaned up.  This may have existed in 4.1.0 too, but I don’t remember it happening before that.  Any thoughts on what might be wrong?

 

John Tobe

Ball Aerospace & Technologies

2875 Presidential Drive, Suite 180

work: 937-320-4045

cell: 937-477-0691

 


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.

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.
Reply | Threaded
Open this post in threaded view
|

RE: RE: deleteWindow causes crash on exit

John Tobe

After each product is made I make a call to DesktopServices::getCurrentWorkspaceWindow() to get the window and then pass that into deleteWindow.  Currently I have a workaround to call minimize instead, but I wanted to see if anyone else was having this problem.

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:11 PM
To: [hidden email]
Subject: RE: deleteWindow causes crash on exit

 

When and how does your plug-in delete the product windows?  In response to the SIGNAL_NAME(SessionManager, Closed)?  In it’s destructor?  Or another way?

 

Thanks,

Kip

 


From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 11:47 AM
To: [hidden email]
Subject: deleteWindow causes crash on exit

 

The EIP Auto Products algorithm creates product windows for each product and then deletes them using DesktopServices’ deleteWindow method.  In 4.1.1 this causes a crash on exit to occur however.  It looks like the problem occurs when the slots are being cleaned up.  This may have existed in 4.1.0 too, but I don’t remember it happening before that.  Any thoughts on what might be wrong?

 

John Tobe

Ball Aerospace & Technologies

2875 Presidential Drive, Suite 180

work: 937-320-4045

cell: 937-477-0691

 


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.

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.

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.
Reply | Threaded
Open this post in threaded view
|

RE: RE: RE: deleteWindow causes crash on exit

Dave Hartman

I’m thinking that workaround will fail if you try to start a new session instead of closing Opticks.  You probably need to listen to the SessionClosed signal

 

David Hartman

Software Engineer

2875 Presidential Drive, Fairborn, OH 45324

Phone: (937) 320-7173

Email:  [hidden email]

 


From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:52 PM
To: [hidden email]
Subject: RE: RE: deleteWindow causes crash on exit

 

After each product is made I make a call to DesktopServices::getCurrentWorkspaceWindow() to get the window and then pass that into deleteWindow.  Currently I have a workaround to call minimize instead, but I wanted to see if anyone else was having this problem.

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:11 PM
To: [hidden email]
Subject: RE: deleteWindow causes crash on exit

 

When and how does your plug-in delete the product windows?  In response to the SIGNAL_NAME(SessionManager, Closed)?  In it’s destructor?  Or another way?

 

Thanks,

Kip

 


From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 11:47 AM
To: [hidden email]
Subject: deleteWindow causes crash on exit

 

The EIP Auto Products algorithm creates product windows for each product and then deletes them using DesktopServices’ deleteWindow method.  In 4.1.1 this causes a crash on exit to occur however.  It looks like the problem occurs when the slots are being cleaned up.  This may have existed in 4.1.0 too, but I don’t remember it happening before that.  Any thoughts on what might be wrong?

 

John Tobe

Ball Aerospace & Technologies

2875 Presidential Drive, Suite 180

work: 937-320-4045

cell: 937-477-0691

 


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.

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.

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.

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.
Reply | Threaded
Open this post in threaded view
|

RE: RE: RE: RE: deleteWindow causes crash on exit

John Tobe

I’m not listening to ApplicationClosed, but I tested my workaround to double check and it worked fine.

 


From: Hartman, David [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:00 PM
To: [hidden email]
Subject: RE: RE: RE: deleteWindow causes crash on exit

 

I’m thinking that workaround will fail if you try to start a new session instead of closing Opticks.  You probably need to listen to the SessionClosed signal

 

David Hartman

Software Engineer

2875 Presidential Drive, Fairborn, OH 45324

Phone: (937) 320-7173

Email:  [hidden email]

 


From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:52 PM
To: [hidden email]
Subject: RE: RE: deleteWindow causes crash on exit

 

After each product is made I make a call to DesktopServices::getCurrentWorkspaceWindow() to get the window and then pass that into deleteWindow.  Currently I have a workaround to call minimize instead, but I wanted to see if anyone else was having this problem.

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:11 PM
To: [hidden email]
Subject: RE: deleteWindow causes crash on exit

 

When and how does your plug-in delete the product windows?  In response to the SIGNAL_NAME(SessionManager, Closed)?  In it’s destructor?  Or another way?

 

Thanks,

Kip

 


From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 11:47 AM
To: [hidden email]
Subject: deleteWindow causes crash on exit

 

The EIP Auto Products algorithm creates product windows for each product and then deletes them using DesktopServices’ deleteWindow method.  In 4.1.1 this causes a crash on exit to occur however.  It looks like the problem occurs when the slots are being cleaned up.  This may have existed in 4.1.0 too, but I don’t remember it happening before that.  Any thoughts on what might be wrong?

 

John Tobe

Ball Aerospace & Technologies

2875 Presidential Drive, Suite 180

work: 937-320-4045

cell: 937-477-0691

 


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.

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.

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.

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.

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.
Reply | Threaded
Open this post in threaded view
|

RE: RE: RE: RE: RE: deleteWindow causes crash on exit

Kip Streithorst
Administrator
I just want to clarify what I've been reading.  I'm assuming that Opticks will still crash if in your plug-in you have code like the following:

void foo()
{
        Service<DesktopServices> pDesktop;
        Window* pWindow = pDesktop->createWindow("Test Window", PRODUCT_WINDOW);
        pDesktop->deleteWindow(pWindow);
}

Are the createWindow() and deleteWindow() calls approximately that close.  What kind of code is between the two calls?  And does it crash inside deleteWindow() or does it crash later when you exit the application?

I'm also assuming that code like the following does not cause a crash:

void foo()
{
        Service<DesktopServices> pDesktop;
        WorkspaceWindow* pWindow = dynamic_cast<WorkspaceWindow*>(pDesktop->createWindow("Test Window", PRODUCT_WINDOW));
        pWindow->minimize();
}

Please let me know if my summary and assumptions are correct.

Thanks,
Kip
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:06 PM
To: [hidden email]
Subject: RE: RE: RE: RE: deleteWindow causes crash on exit

I'm not listening to ApplicationClosed, but I tested my workaround to double check and it worked fine.
 
________________________________________
From: Hartman, David [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:00 PM
To: [hidden email]
Subject: RE: RE: RE: deleteWindow causes crash on exit
 
I'm thinking that workaround will fail if you try to start a new session instead of closing Opticks.  You probably need to listen to the SessionClosed signal
 
David Hartman
Software Engineer
2875 Presidential Drive, Fairborn, OH 45324
Phone: (937) 320-7173
Email:  [hidden email]
 
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:52 PM
To: [hidden email]
Subject: RE: RE: deleteWindow causes crash on exit
 
After each product is made I make a call to DesktopServices::getCurrentWorkspaceWindow() to get the window and then pass that into deleteWindow.  Currently I have a workaround to call minimize instead, but I wanted to see if anyone else was having this problem.
 
________________________________________
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:11 PM
To: [hidden email]
Subject: RE: deleteWindow causes crash on exit
 
When and how does your plug-in delete the product windows?  In response to the SIGNAL_NAME(SessionManager, Closed)?  In it's destructor?  Or another way?
 
Thanks,
Kip
 
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 11:47 AM
To: [hidden email]
Subject: deleteWindow causes crash on exit
 
The EIP Auto Products algorithm creates product windows for each product and then deletes them using DesktopServices' deleteWindow method.  In 4.1.1 this causes a crash on exit to occur however.  It looks like the problem occurs when the slots are being cleaned up.  This may have existed in 4.1.0 too, but I don't remember it happening before that.  Any thoughts on what might be wrong?
 
John Tobe
Ball Aerospace & Technologies
2875 Presidential Drive, Suite 180
work: 937-320-4045
cell: 937-477-0691
 



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
|

RE: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

John Tobe
Obviously it's not quite that simple of course.  :)
We create a product window using DesktopServices::deriveProduct, set it up and size everything correctly, save it out using the JPEG view exporter, then delete it.  Opticks then crashes when it is closed.  After further testing, closing the window manually still results in a crash on close, but if the SpatialDataWindow it's associated with is closed before exiting there is no crash.

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 2:29 PM
To: [hidden email]
Subject: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

I just want to clarify what I've been reading.  I'm assuming that Opticks will still crash if in your plug-in you have code like the following:

void foo()
{
        Service<DesktopServices> pDesktop;
        Window* pWindow = pDesktop->createWindow("Test Window", PRODUCT_WINDOW);
        pDesktop->deleteWindow(pWindow);
}

Are the createWindow() and deleteWindow() calls approximately that close.  What kind of code is between the two calls?  And does it crash inside deleteWindow() or does it crash later when you exit the application?

I'm also assuming that code like the following does not cause a crash:

void foo()
{
        Service<DesktopServices> pDesktop;
        WorkspaceWindow* pWindow = dynamic_cast<WorkspaceWindow*>(pDesktop->createWindow("Test Window", PRODUCT_WINDOW));
        pWindow->minimize();
}

Please let me know if my summary and assumptions are correct.

Thanks,
Kip
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:06 PM
To: [hidden email]
Subject: RE: RE: RE: RE: deleteWindow causes crash on exit

I'm not listening to ApplicationClosed, but I tested my workaround to double check and it worked fine.
 
________________________________________
From: Hartman, David [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:00 PM
To: [hidden email]
Subject: RE: RE: RE: deleteWindow causes crash on exit
 
I'm thinking that workaround will fail if you try to start a new session instead of closing Opticks.  You probably need to listen to the SessionClosed signal
 
David Hartman
Software Engineer
2875 Presidential Drive, Fairborn, OH 45324
Phone: (937) 320-7173
Email:  [hidden email]
 
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:52 PM
To: [hidden email]
Subject: RE: RE: deleteWindow causes crash on exit
 
After each product is made I make a call to DesktopServices::getCurrentWorkspaceWindow() to get the window and then pass that into deleteWindow.  Currently I have a workaround to call minimize instead, but I wanted to see if anyone else was having this problem.
 
________________________________________
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:11 PM
To: [hidden email]
Subject: RE: deleteWindow causes crash on exit
 
When and how does your plug-in delete the product windows?  In response to the SIGNAL_NAME(SessionManager, Closed)?  In it's destructor?  Or another way?
 
Thanks,
Kip
 
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 11:47 AM
To: [hidden email]
Subject: deleteWindow causes crash on exit
 
The EIP Auto Products algorithm creates product windows for each product and then deletes them using DesktopServices' deleteWindow method.  In 4.1.1 this causes a crash on exit to occur however.  It looks like the problem occurs when the slots are being cleaned up.  This may have existed in 4.1.0 too, but I don't remember it happening before that.  Any thoughts on what might be wrong?
 
John Tobe
Ball Aerospace & Technologies
2875 Presidential Drive, Suite 180
work: 937-320-4045
cell: 937-477-0691
 



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]

Reply | Threaded
Open this post in threaded view
|

RE: RE: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

Kip Streithorst
Administrator
I've modified a sample plug-in down here to do the following:

   SpatialDataView* pView = pInputArgList->getPlugInArgValue<SpatialDataView>(Executable::ViewArg());
   VERIFYRV(pView != NULL, false);

   Service<DesktopServices> pDesktop;
   ProductWindow* pWindow = pDesktop->deriveProduct(pView);
   VERIFYRV(pWindow != NULL, false);

   ProductView* pProdView = pWindow->getProductView();
   pProdView->zoomExtents();

   FileDescriptor* pDesc = RasterUtilities::generateFileDescriptorForExport(NULL, "C:\\kiptest.jpg");
   ExporterResource exporter("JPEG View Exporter", pProdView, pDesc);
   Exporter* pExporter = exporter->getExporter();
   VERIFYRV(pExporter != NULL, false);
   exporter->createProgressDialog(true);
   VERIFYRV(exporter->execute() == true, false);

   VERIFYRV(pDesktop->deleteWindow(pWindow) == true, false);

And after the plug-in execution, I can close the application without a crash.  Let me know how close this is to your situation.  I can also provide you a binary of this plug-in that you can test in your environment if you let me know what configuration you need (i.e. Debug, Release, 32-bit, 64-bit, Windows or Solaris).

Thanks,
Kip

-----Original Message-----
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 3:19 PM
To: [hidden email]
Subject: RE: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

Obviously it's not quite that simple of course.  :)
We create a product window using DesktopServices::deriveProduct, set it up and size everything correctly, save it out using the JPEG view exporter, then delete it.  Opticks then crashes when it is closed.  After further testing, closing the window manually still results in a crash on close, but if the SpatialDataWindow it's associated with is closed before exiting there is no crash.

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 2:29 PM
To: [hidden email]
Subject: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

I just want to clarify what I've been reading.  I'm assuming that Opticks will still crash if in your plug-in you have code like the following:

void foo()
{
        Service<DesktopServices> pDesktop;
        Window* pWindow = pDesktop->createWindow("Test Window", PRODUCT_WINDOW);
        pDesktop->deleteWindow(pWindow);
}

Are the createWindow() and deleteWindow() calls approximately that close.  What kind of code is between the two calls?  And does it crash inside deleteWindow() or does it crash later when you exit the application?

I'm also assuming that code like the following does not cause a crash:

void foo()
{
        Service<DesktopServices> pDesktop;
        WorkspaceWindow* pWindow = dynamic_cast<WorkspaceWindow*>(pDesktop->createWindow("Test Window", PRODUCT_WINDOW));
        pWindow->minimize();
}

Please let me know if my summary and assumptions are correct.

Thanks,
Kip
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:06 PM
To: [hidden email]
Subject: RE: RE: RE: RE: deleteWindow causes crash on exit

I'm not listening to ApplicationClosed, but I tested my workaround to double check and it worked fine.
 
________________________________________
From: Hartman, David [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:00 PM
To: [hidden email]
Subject: RE: RE: RE: deleteWindow causes crash on exit
 
I'm thinking that workaround will fail if you try to start a new session instead of closing Opticks.  You probably need to listen to the SessionClosed signal
 
David Hartman
Software Engineer
2875 Presidential Drive, Fairborn, OH 45324
Phone: (937) 320-7173
Email:  [hidden email]
 
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:52 PM
To: [hidden email]
Subject: RE: RE: deleteWindow causes crash on exit
 
After each product is made I make a call to DesktopServices::getCurrentWorkspaceWindow() to get the window and then pass that into deleteWindow.  Currently I have a workaround to call minimize instead, but I wanted to see if anyone else was having this problem.
 
________________________________________
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:11 PM
To: [hidden email]
Subject: RE: deleteWindow causes crash on exit
 
When and how does your plug-in delete the product windows?  In response to the SIGNAL_NAME(SessionManager, Closed)?  In it's destructor?  Or another way?
 
Thanks,
Kip
 
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 11:47 AM
To: [hidden email]
Subject: deleteWindow causes crash on exit
 
The EIP Auto Products algorithm creates product windows for each product and then deletes them using DesktopServices' deleteWindow method.  In 4.1.1 this causes a crash on exit to occur however.  It looks like the problem occurs when the slots are being cleaned up.  This may have existed in 4.1.0 too, but I don't remember it happening before that.  Any thoughts on what might be wrong?
 
John Tobe
Ball Aerospace & Technologies
2875 Presidential Drive, Suite 180
work: 937-320-4045
cell: 937-477-0691
 



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]




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
|

RE: RE: RE: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

John Tobe
That's pretty much what we're doing, so it doesn't look like an Opticks issue.  Right now it looks like we're not cleaning something up properly until the dataset is closed.

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Friday, April 04, 2008 12:54 PM
To: [hidden email]
Subject: RE: RE: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

I've modified a sample plug-in down here to do the following:

   SpatialDataView* pView = pInputArgList->getPlugInArgValue<SpatialDataView>(Executable::ViewArg());
   VERIFYRV(pView != NULL, false);

   Service<DesktopServices> pDesktop;
   ProductWindow* pWindow = pDesktop->deriveProduct(pView);
   VERIFYRV(pWindow != NULL, false);

   ProductView* pProdView = pWindow->getProductView();
   pProdView->zoomExtents();

   FileDescriptor* pDesc = RasterUtilities::generateFileDescriptorForExport(NULL, "C:\\kiptest.jpg");
   ExporterResource exporter("JPEG View Exporter", pProdView, pDesc);
   Exporter* pExporter = exporter->getExporter();
   VERIFYRV(pExporter != NULL, false);
   exporter->createProgressDialog(true);
   VERIFYRV(exporter->execute() == true, false);

   VERIFYRV(pDesktop->deleteWindow(pWindow) == true, false);

And after the plug-in execution, I can close the application without a crash.  Let me know how close this is to your situation.  I can also provide you a binary of this plug-in that you can test in your environment if you let me know what configuration you need (i.e. Debug, Release, 32-bit, 64-bit, Windows or Solaris).

Thanks,
Kip

-----Original Message-----
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 3:19 PM
To: [hidden email]
Subject: RE: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

Obviously it's not quite that simple of course.  :)
We create a product window using DesktopServices::deriveProduct, set it up and size everything correctly, save it out using the JPEG view exporter, then delete it.  Opticks then crashes when it is closed.  After further testing, closing the window manually still results in a crash on close, but if the SpatialDataWindow it's associated with is closed before exiting there is no crash.

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 2:29 PM
To: [hidden email]
Subject: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

I just want to clarify what I've been reading.  I'm assuming that Opticks will still crash if in your plug-in you have code like the following:

void foo()
{
        Service<DesktopServices> pDesktop;
        Window* pWindow = pDesktop->createWindow("Test Window", PRODUCT_WINDOW);
        pDesktop->deleteWindow(pWindow);
}

Are the createWindow() and deleteWindow() calls approximately that close.  What kind of code is between the two calls?  And does it crash inside deleteWindow() or does it crash later when you exit the application?

I'm also assuming that code like the following does not cause a crash:

void foo()
{
        Service<DesktopServices> pDesktop;
        WorkspaceWindow* pWindow = dynamic_cast<WorkspaceWindow*>(pDesktop->createWindow("Test Window", PRODUCT_WINDOW));
        pWindow->minimize();
}

Please let me know if my summary and assumptions are correct.

Thanks,
Kip
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:06 PM
To: [hidden email]
Subject: RE: RE: RE: RE: deleteWindow causes crash on exit

I'm not listening to ApplicationClosed, but I tested my workaround to double check and it worked fine.
 
________________________________________
From: Hartman, David [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:00 PM
To: [hidden email]
Subject: RE: RE: RE: deleteWindow causes crash on exit
 
I'm thinking that workaround will fail if you try to start a new session instead of closing Opticks.  You probably need to listen to the SessionClosed signal
 
David Hartman
Software Engineer
2875 Presidential Drive, Fairborn, OH 45324
Phone: (937) 320-7173
Email:  [hidden email]
 
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:52 PM
To: [hidden email]
Subject: RE: RE: deleteWindow causes crash on exit
 
After each product is made I make a call to DesktopServices::getCurrentWorkspaceWindow() to get the window and then pass that into deleteWindow.  Currently I have a workaround to call minimize instead, but I wanted to see if anyone else was having this problem.
 
________________________________________
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:11 PM
To: [hidden email]
Subject: RE: deleteWindow causes crash on exit
 
When and how does your plug-in delete the product windows?  In response to the SIGNAL_NAME(SessionManager, Closed)?  In it's destructor?  Or another way?
 
Thanks,
Kip
 
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 11:47 AM
To: [hidden email]
Subject: deleteWindow causes crash on exit
 
The EIP Auto Products algorithm creates product windows for each product and then deletes them using DesktopServices' deleteWindow method.  In 4.1.1 this causes a crash on exit to occur however.  It looks like the problem occurs when the slots are being cleaned up.  This may have existed in 4.1.0 too, but I don't remember it happening before that.  Any thoughts on what might be wrong?
 
John Tobe
Ball Aerospace & Technologies
2875 Presidential Drive, Suite 180
work: 937-320-4045
cell: 937-477-0691
 



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]




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]

Reply | Threaded
Open this post in threaded view
|

RE: RE: RE: RE: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

Kip Streithorst
Administrator
Well, if you find a problem in Opticks during your investigation, let me know and I can investigate a fix for the problem.

Kip

-----Original Message-----
From: Tobe, John [mailto:[hidden email]]
Sent: Friday, April 04, 2008 2:01 PM
To: [hidden email]
Subject: RE: RE: RE: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

That's pretty much what we're doing, so it doesn't look like an Opticks issue.  Right now it looks like we're not cleaning something up properly until the dataset is closed.

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Friday, April 04, 2008 12:54 PM
To: [hidden email]
Subject: RE: RE: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

I've modified a sample plug-in down here to do the following:

   SpatialDataView* pView = pInputArgList->getPlugInArgValue<SpatialDataView>(Executable::ViewArg());
   VERIFYRV(pView != NULL, false);

   Service<DesktopServices> pDesktop;
   ProductWindow* pWindow = pDesktop->deriveProduct(pView);
   VERIFYRV(pWindow != NULL, false);

   ProductView* pProdView = pWindow->getProductView();
   pProdView->zoomExtents();

   FileDescriptor* pDesc = RasterUtilities::generateFileDescriptorForExport(NULL, "C:\\kiptest.jpg");
   ExporterResource exporter("JPEG View Exporter", pProdView, pDesc);
   Exporter* pExporter = exporter->getExporter();
   VERIFYRV(pExporter != NULL, false);
   exporter->createProgressDialog(true);
   VERIFYRV(exporter->execute() == true, false);

   VERIFYRV(pDesktop->deleteWindow(pWindow) == true, false);

And after the plug-in execution, I can close the application without a crash.  Let me know how close this is to your situation.  I can also provide you a binary of this plug-in that you can test in your environment if you let me know what configuration you need (i.e. Debug, Release, 32-bit, 64-bit, Windows or Solaris).

Thanks,
Kip

-----Original Message-----
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 3:19 PM
To: [hidden email]
Subject: RE: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

Obviously it's not quite that simple of course.  :)
We create a product window using DesktopServices::deriveProduct, set it up and size everything correctly, save it out using the JPEG view exporter, then delete it.  Opticks then crashes when it is closed.  After further testing, closing the window manually still results in a crash on close, but if the SpatialDataWindow it's associated with is closed before exiting there is no crash.

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 2:29 PM
To: [hidden email]
Subject: RE: RE: RE: RE: RE: deleteWindow causes crash on exit

I just want to clarify what I've been reading.  I'm assuming that Opticks will still crash if in your plug-in you have code like the following:

void foo()
{
        Service<DesktopServices> pDesktop;
        Window* pWindow = pDesktop->createWindow("Test Window", PRODUCT_WINDOW);
        pDesktop->deleteWindow(pWindow);
}

Are the createWindow() and deleteWindow() calls approximately that close.  What kind of code is between the two calls?  And does it crash inside deleteWindow() or does it crash later when you exit the application?

I'm also assuming that code like the following does not cause a crash:

void foo()
{
        Service<DesktopServices> pDesktop;
        WorkspaceWindow* pWindow = dynamic_cast<WorkspaceWindow*>(pDesktop->createWindow("Test Window", PRODUCT_WINDOW));
        pWindow->minimize();
}

Please let me know if my summary and assumptions are correct.

Thanks,
Kip
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:06 PM
To: [hidden email]
Subject: RE: RE: RE: RE: deleteWindow causes crash on exit

I'm not listening to ApplicationClosed, but I tested my workaround to double check and it worked fine.
 
________________________________________
From: Hartman, David [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 1:00 PM
To: [hidden email]
Subject: RE: RE: RE: deleteWindow causes crash on exit
 
I'm thinking that workaround will fail if you try to start a new session instead of closing Opticks.  You probably need to listen to the SessionClosed signal
 
David Hartman
Software Engineer
2875 Presidential Drive, Fairborn, OH 45324
Phone: (937) 320-7173
Email:  [hidden email]
 
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:52 PM
To: [hidden email]
Subject: RE: RE: deleteWindow causes crash on exit
 
After each product is made I make a call to DesktopServices::getCurrentWorkspaceWindow() to get the window and then pass that into deleteWindow.  Currently I have a workaround to call minimize instead, but I wanted to see if anyone else was having this problem.
 
________________________________________
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 12:11 PM
To: [hidden email]
Subject: RE: deleteWindow causes crash on exit
 
When and how does your plug-in delete the product windows?  In response to the SIGNAL_NAME(SessionManager, Closed)?  In it's destructor?  Or another way?
 
Thanks,
Kip
 
________________________________________
From: Tobe, John [mailto:[hidden email]]
Sent: Thursday, April 03, 2008 11:47 AM
To: [hidden email]
Subject: deleteWindow causes crash on exit
 
The EIP Auto Products algorithm creates product windows for each product and then deletes them using DesktopServices' deleteWindow method.  In 4.1.1 this causes a crash on exit to occur however.  It looks like the problem occurs when the slots are being cleaned up.  This may have existed in 4.1.0 too, but I don't remember it happening before that.  Any thoughts on what might be wrong?
 
John Tobe
Ball Aerospace & Technologies
2875 Presidential Drive, Suite 180
work: 937-320-4045
cell: 937-477-0691
 



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]




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]




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
|

Geographic Feature + Naming Convention + Product Question

rgoffena
In reply to this post by Kip Streithorst
Has anyone noticed the following before?
1) Start Opticks.
2) Load dataset.
3) Select Geographic Features->Edit This Menu.
4) Within resulting Feature Menu Editor dialog, add a new geographic
feature and provide it with a layer name of "Test Feature".
5) Close Feature Menu Editor dialog.
6) Select Geographic Features->Test Feature.
7) Note that the features is displayed in Elements Tab of Session
Explorer, by filename.
8) Create a product view which results in the spatial data view
resulting from step2 being copied.
9) Note that the copy of the Test Feature is displayed in Elements Tab
of Session Explorer, by layer name and "- Product 1" suffix ("Test
Feature - Product 1").

Step7 and step9 seem to exhibit an inconsistent naming convention.


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
|

RE: Geographic Feature + Naming Convention + Product Question

tclarke
Administrator
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There's no specific reason this happens. You can put a bug in if you'd
like. There are other problems with the current approach which need to
be addressed. The longer term fix will remove the need to copy the
element which will make your bug OBE. I'm not sure when we'll get to
these longer term fixes.

- -----Original Message-----
From: Goffena, Robert [mailto:[hidden email]]
Sent: Monday, May 05, 2008 4:25 PM
To: [hidden email]
Subject: Geographic Feature + Naming Convention + Product Question

Has anyone noticed the following before?
1) Start Opticks.
2) Load dataset.
3) Select Geographic Features->Edit This Menu.
4) Within resulting Feature Menu Editor dialog, add a new geographic
feature and provide it with a layer name of "Test Feature".
5) Close Feature Menu Editor dialog.
6) Select Geographic Features->Test Feature.
7) Note that the features is displayed in Elements Tab of Session
Explorer, by filename.
8) Create a product view which results in the spatial data view
resulting from step2 being copied.
9) Note that the copy of the Test Feature is displayed in Elements Tab
of Session Explorer, by layer name and "- Product 1" suffix ("Test
Feature - Product 1").

Step7 and step9 seem to exhibit an inconsistent naming convention.


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]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFIIGD8+xUTKUxH/LkRAmE8AKCvmUXpiRuWUcIfHdUpyXG+vAhRFQCgx0m/
28ApouU3Y311o9c3mY/iWYQ=
=ua2Q
-----END PGP SIGNATURE-----



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
|

RE: Geographic Feature + Naming Convention + Product Question

Kip Streithorst
Administrator
In reply to this post by rgoffena
Into the gory details...

For most layers in Opticks, the layer and underlying data element can
have a many-to-one relationship (i.e. you can have two different raster
layers that contain one raster element, which means a single raster
element is shared between the two layers).  However, for graphic layer,
annotation layer and aoi layer this is not the case.  Each layer must
have exclusive access to the underlying graphic element, annotation
element or aoi element.  It's this particular fact that makes putting
these layers into product's interesting to say the least.  When these
layers are put into a product, both a new layer and new element must be
created by copying the original layer and element.  It's the creation of
the new graphic element, annotation element or aoi element that becomes
problematic because we need to pick a unique name for the element.
Originally we tried to address this issue by picking a GUID as it's new
name.  Some bugs were reported about this because it looked very ugly
and confusing to the user.  So, the behavior was changed to the current
behavior where the new element is named based upon the original layer's
name and the name of the product (i.e. "OriginalLayerName-ProductName"
).  That is the behavior you are seeing.  The reason this looks odd to
you is because in the Geographic Feature case, the layer name and
element name for the original data have very different names.

Please note that the copying of the underlying element to put these
layers into a product is causing other weirdness as well.  This is the
reason that once a geographic feature is derived into a product it no
longer behaves like a geographic feature layer, but instead behaves like
an annotation layer.  This is because the presence of a child data
element below the original annotation element defines whether it is a
geographic feature layer or regular annotation layer and the copy code
does not also copy this child element.

Before anyone asks removing the exclusive 1-to-1 relationship between
graphic layer and graphic element is not trivial and would certainly
break either source, functional or binary compatibility.

Thanks,
Kip

-----Original Message-----
From: Goffena, Robert [mailto:[hidden email]]
Sent: Monday, May 05, 2008 4:25 PM
To: [hidden email]
Subject: Geographic Feature + Naming Convention + Product Question

Has anyone noticed the following before?
1) Start Opticks.
2) Load dataset.
3) Select Geographic Features->Edit This Menu.
4) Within resulting Feature Menu Editor dialog, add a new geographic
feature and provide it with a layer name of "Test Feature".
5) Close Feature Menu Editor dialog.
6) Select Geographic Features->Test Feature.
7) Note that the features is displayed in Elements Tab of Session
Explorer, by filename.
8) Create a product view which results in the spatial data view
resulting from step2 being copied.
9) Note that the copy of the Test Feature is displayed in Elements Tab
of Session Explorer, by layer name and "- Product 1" suffix ("Test
Feature - Product 1").

Step7 and step9 seem to exhibit an inconsistent naming convention.


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]

Reply | Threaded
Open this post in threaded view
|

RE: RE: Geographic Feature + Naming Convention + Product Question

rgoffena
" It's the creation of
the new graphic element, annotation element or aoi element that becomes
problematic because we need to pick a unique name for the element."
It sounds like: newElementName = "OriginalLayerName-ProductName".
Is there any particular reason newElementName is not being set to
"OriginalElementName-ProductName"?



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

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Tuesday, May 06, 2008 10:04 AM
To: [hidden email]
Subject: RE: Geographic Feature + Naming Convention + Product Question

Into the gory details...

For most layers in Opticks, the layer and underlying data element can
have a many-to-one relationship (i.e. you can have two different raster
layers that contain one raster element, which means a single raster
element is shared between the two layers).  However, for graphic layer,
annotation layer and aoi layer this is not the case.  Each layer must
have exclusive access to the underlying graphic element, annotation
element or aoi element.  It's this particular fact that makes putting
these layers into product's interesting to say the least.  When these
layers are put into a product, both a new layer and new element must be
created by copying the original layer and element.  It's the creation of
the new graphic element, annotation element or aoi element that becomes
problematic because we need to pick a unique name for the element.
Originally we tried to address this issue by picking a GUID as it's new
name.  Some bugs were reported about this because it looked very ugly
and confusing to the user.  So, the behavior was changed to the current
behavior where the new element is named based upon the original layer's
name and the name of the product (i.e. "OriginalLayerName-ProductName"
).  That is the behavior you are seeing.  The reason this looks odd to
you is because in the Geographic Feature case, the layer name and
element name for the original data have very different names.

Please note that the copying of the underlying element to put these
layers into a product is causing other weirdness as well.  This is the
reason that once a geographic feature is derived into a product it no
longer behaves like a geographic feature layer, but instead behaves like
an annotation layer.  This is because the presence of a child data
element below the original annotation element defines whether it is a
geographic feature layer or regular annotation layer and the copy code
does not also copy this child element.

Before anyone asks removing the exclusive 1-to-1 relationship between
graphic layer and graphic element is not trivial and would certainly
break either source, functional or binary compatibility.

Thanks,
Kip

-----Original Message-----
From: Goffena, Robert [mailto:[hidden email]]
Sent: Monday, May 05, 2008 4:25 PM
To: [hidden email]
Subject: Geographic Feature + Naming Convention + Product Question

Has anyone noticed the following before?
1) Start Opticks.
2) Load dataset.
3) Select Geographic Features->Edit This Menu.
4) Within resulting Feature Menu Editor dialog, add a new geographic
feature and provide it with a layer name of "Test Feature".
5) Close Feature Menu Editor dialog.
6) Select Geographic Features->Test Feature.
7) Note that the features is displayed in Elements Tab of Session
Explorer, by filename.
8) Create a product view which results in the spatial data view
resulting from step2 being copied.
9) Note that the copy of the Test Feature is displayed in Elements Tab
of Session Explorer, by layer name and "- Product 1" suffix ("Test
Feature - Product 1").

Step7 and step9 seem to exhibit an inconsistent naming convention.


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]




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
|

RE: RE: RE: Geographic Feature + Naming Convention + Product Question

Kip Streithorst
Administrator
If you would like it to be that way, you can report a bug to that
effect.  I haven't yet heard anyone voice a technical reason as to why
it couldn't be changed to "OriginalElementName-ProductName".

Thanks,
Kip

-----Original Message-----
From: Goffena, Robert [mailto:[hidden email]]
Sent: Tuesday, May 06, 2008 11:18 AM
To: [hidden email]
Subject: RE: RE: Geographic Feature + Naming Convention + Product
Question

" It's the creation of
the new graphic element, annotation element or aoi element that becomes
problematic because we need to pick a unique name for the element."
It sounds like: newElementName = "OriginalLayerName-ProductName".
Is there any particular reason newElementName is not being set to
"OriginalElementName-ProductName"?



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

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Tuesday, May 06, 2008 10:04 AM
To: [hidden email]
Subject: RE: Geographic Feature + Naming Convention + Product Question

Into the gory details...

For most layers in Opticks, the layer and underlying data element can
have a many-to-one relationship (i.e. you can have two different raster
layers that contain one raster element, which means a single raster
element is shared between the two layers).  However, for graphic layer,
annotation layer and aoi layer this is not the case.  Each layer must
have exclusive access to the underlying graphic element, annotation
element or aoi element.  It's this particular fact that makes putting
these layers into product's interesting to say the least.  When these
layers are put into a product, both a new layer and new element must be
created by copying the original layer and element.  It's the creation of
the new graphic element, annotation element or aoi element that becomes
problematic because we need to pick a unique name for the element.
Originally we tried to address this issue by picking a GUID as it's new
name.  Some bugs were reported about this because it looked very ugly
and confusing to the user.  So, the behavior was changed to the current
behavior where the new element is named based upon the original layer's
name and the name of the product (i.e. "OriginalLayerName-ProductName"
).  That is the behavior you are seeing.  The reason this looks odd to
you is because in the Geographic Feature case, the layer name and
element name for the original data have very different names.

Please note that the copying of the underlying element to put these
layers into a product is causing other weirdness as well.  This is the
reason that once a geographic feature is derived into a product it no
longer behaves like a geographic feature layer, but instead behaves like
an annotation layer.  This is because the presence of a child data
element below the original annotation element defines whether it is a
geographic feature layer or regular annotation layer and the copy code
does not also copy this child element.

Before anyone asks removing the exclusive 1-to-1 relationship between
graphic layer and graphic element is not trivial and would certainly
break either source, functional or binary compatibility.

Thanks,
Kip

-----Original Message-----
From: Goffena, Robert [mailto:[hidden email]]
Sent: Monday, May 05, 2008 4:25 PM
To: [hidden email]
Subject: Geographic Feature + Naming Convention + Product Question

Has anyone noticed the following before?
1) Start Opticks.
2) Load dataset.
3) Select Geographic Features->Edit This Menu.
4) Within resulting Feature Menu Editor dialog, add a new geographic
feature and provide it with a layer name of "Test Feature".
5) Close Feature Menu Editor dialog.
6) Select Geographic Features->Test Feature.
7) Note that the features is displayed in Elements Tab of Session
Explorer, by filename.
8) Create a product view which results in the spatial data view
resulting from step2 being copied.
9) Note that the copy of the Test Feature is displayed in Elements Tab
of Session Explorer, by layer name and "- Product 1" suffix ("Test
Feature - Product 1").

Step7 and step9 seem to exhibit an inconsistent naming convention.


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]




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]

Reply | Threaded
Open this post in threaded view
|

RE: RE: RE: RE: Geographic Feature + Naming Convention + Product Question

rgoffena
Added a JIRA issue:  COMETIV-1288.


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

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Wednesday, May 07, 2008 5:18 PM
To: [hidden email]
Subject: RE: RE: RE: Geographic Feature + Naming Convention + Product
Question

If you would like it to be that way, you can report a bug to that
effect.  I haven't yet heard anyone voice a technical reason as to why
it couldn't be changed to "OriginalElementName-ProductName".

Thanks,
Kip

-----Original Message-----
From: Goffena, Robert [mailto:[hidden email]]
Sent: Tuesday, May 06, 2008 11:18 AM
To: [hidden email]
Subject: RE: RE: Geographic Feature + Naming Convention + Product
Question

" It's the creation of
the new graphic element, annotation element or aoi element that becomes
problematic because we need to pick a unique name for the element."
It sounds like: newElementName = "OriginalLayerName-ProductName".
Is there any particular reason newElementName is not being set to
"OriginalElementName-ProductName"?



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

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Tuesday, May 06, 2008 10:04 AM
To: [hidden email]
Subject: RE: Geographic Feature + Naming Convention + Product Question

Into the gory details...

For most layers in Opticks, the layer and underlying data element can
have a many-to-one relationship (i.e. you can have two different raster
layers that contain one raster element, which means a single raster
element is shared between the two layers).  However, for graphic layer,
annotation layer and aoi layer this is not the case.  Each layer must
have exclusive access to the underlying graphic element, annotation
element or aoi element.  It's this particular fact that makes putting
these layers into product's interesting to say the least.  When these
layers are put into a product, both a new layer and new element must be
created by copying the original layer and element.  It's the creation of
the new graphic element, annotation element or aoi element that becomes
problematic because we need to pick a unique name for the element.
Originally we tried to address this issue by picking a GUID as it's new
name.  Some bugs were reported about this because it looked very ugly
and confusing to the user.  So, the behavior was changed to the current
behavior where the new element is named based upon the original layer's
name and the name of the product (i.e. "OriginalLayerName-ProductName"
).  That is the behavior you are seeing.  The reason this looks odd to
you is because in the Geographic Feature case, the layer name and
element name for the original data have very different names.

Please note that the copying of the underlying element to put these
layers into a product is causing other weirdness as well.  This is the
reason that once a geographic feature is derived into a product it no
longer behaves like a geographic feature layer, but instead behaves like
an annotation layer.  This is because the presence of a child data
element below the original annotation element defines whether it is a
geographic feature layer or regular annotation layer and the copy code
does not also copy this child element.

Before anyone asks removing the exclusive 1-to-1 relationship between
graphic layer and graphic element is not trivial and would certainly
break either source, functional or binary compatibility.

Thanks,
Kip

-----Original Message-----
From: Goffena, Robert [mailto:[hidden email]]
Sent: Monday, May 05, 2008 4:25 PM
To: [hidden email]
Subject: Geographic Feature + Naming Convention + Product Question

Has anyone noticed the following before?
1) Start Opticks.
2) Load dataset.
3) Select Geographic Features->Edit This Menu.
4) Within resulting Feature Menu Editor dialog, add a new geographic
feature and provide it with a layer name of "Test Feature".
5) Close Feature Menu Editor dialog.
6) Select Geographic Features->Test Feature.
7) Note that the features is displayed in Elements Tab of Session
Explorer, by filename.
8) Create a product view which results in the spatial data view
resulting from step2 being copied.
9) Note that the copy of the Test Feature is displayed in Elements Tab
of Session Explorer, by layer name and "- Product 1" suffix ("Test
Feature - Product 1").

Step7 and step9 seem to exhibit an inconsistent naming convention.


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]




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]




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]