Help with communication between modules

In a nutshell, add-on vessels will need to override callback methods in VESSEL2, but add-on MFDs and plug-in modules will only need to use VESSEL.
Well, sometimes I need an XRVesselCtrl. . . :P:speakcool:
 
OH! Computerex, if you're still watching the thread: what were you passing as the char* argument to KeyDown? Perhaps spacecraftx.dll is attempting to read into that char * array to determine the keyboard states of modifier keys, and if it's not a valid char * array, it'll fail.

Well the Stawars Physics MFD just calls the clbkConsumeBufferedKey method of the Blast vessel, which has it's own dll. I am not calling the clbkConsumeBufferedKey of any spacecraftx.dll vessel..
 
When you need to "communicate" with a specific dll (and that dll typically runs as a singleton) it will be better in the long run, to talk to it directly. Trying to sqeeze every message through one or two paramaters, is not always feasible. You need to go through some form of translation on both sides which takes up valuable cpu cycles.

Now if you want to publish this dll as some type of SDK for further use by other developers, it just makes everything much more friendlier and easy to use by calling a method directly using a method name and parameters rather than an obscure code....
 
Thanks. If I understand this correctly, oapiGetVesselInterface is casting a VESSEL2* to a VESSEL*. dynamic_cast<VESSEL2*> will inspect the object that is passed to it and determine if it is a complete VESSEL2 class.
Short answer Yes.

Long answer: Yes, but technically oapiGetVesselInterface doesn't perform a cast. It uses polymorphism and just returns it as the base class (VESSEL). I don't think dynamic_cast<VESSEL2*> inspects the object itself, but looks it up in a table to determine whether it was derived from VESSEL2.
 
Long answer: Yes, but technically oapiGetVesselInterface doesn't perform a cast. It uses polymorphism and just returns it as the base class (VESSEL). I don't think dynamic_cast<VESSEL2*> inspects the object itself, but looks it up in a table to determine whether it was derived from VESSEL2.
Thanks for the long answer. I did a bit more research after your suggestion and discovered that I needed to have Run Time Type Information (RTTI) enabled when compiling my project because dynamic_cast uses it to determine the object type, ie, it looks it up in a table as you suggest.
 
Back
Top