implements #60 EventHandler and ConsHandler #62
Conversation
| @Override | ||
| protected SCIP_Retcode scipExec(Scip scip, SCIP_Event event) { | ||
| assert (event.getEventtype() & EventType.BESTSOLFOUND) != 0 : "Unexpected event caught"; | ||
| Solution solution = new Solution(SCIPJNI.getEventDataSolution(event)); |
There was a problem hiding this comment.
This is how I would envision a user to be implementing an event handler: He get's the raw SCIP_Event passed and has to call one of the SCIPJNI.getEventData*(SCIP_Event) methods to access the union member that corresponds to his event type. Would that be alright? Is it too complicated?
We could also implement custom scipExec* methods for each event type, but the documentation doesn't really say, which union member corresponds to which event type, so it would be a lot of untested code.
|
|
||
| import java.util.Objects; | ||
|
|
||
| public class ResultHolder { |
There was a problem hiding this comment.
I picked this pattern up from the Fico Xpress java library. It corresponds to an output pointer that is passed to the user as a call back and the user is expected to set the result of the handler there.
One could also pass an instance of SCIP and make the corresponding JNI call when the user passes the result immediately, but this would not be safe, if the user somehow leaks the ResultHolder outside of the EventHandler and calls the set method later.
| return messagehdlr; | ||
| } | ||
|
|
||
| /* BEGIN assist functions for accessing SCIP_Event data union members */ |
There was a problem hiding this comment.
I'm not sure if all of those helper methods are necessary, but I couldn't find a different way of accessing the SCIP_Event::data union members. The example code only uses the getEventDataSolution, but I guess the other union members would work as well.
1 participant
Sorry for the large PR, but it turns out EventHandler with the SCIP_Event data union has a lot of possible types.