Exposing classes in a dll and implementation

This topic is 4916 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I’m currently trying to convert my gui class code to a separate dll and I am having a few design issues that hopefully someone here can help me out with. My gui system has lots of different elements (Buttons, text boxes, list boxes etc.), and they all need to be exposed to the host program. All the gui objects inherit from a CGuiEntry class, which contains all the inherited functions that are needed in all gui objects (GetPrimarySelected, GetPrimaryReleased etc.), so this too needs to be exposed to the host system. So I have a system when I have exposed two class types
CGuiEntry
|
|
CGuiButton (for example)

Now my problem comes with fleshing out all the functions declared in the CGuiEntry class (as both classes are abstract to allow them to be exported from the dll) I obviously need a CGuiButtonImplementation class, which actually does all the GuiButton stuff, which is your basic dll export method of doing things. BUT, I don’t want to have to add GetPrimarySelected, GetPrimaryReleased etc.) to ALL my gui objects, as that would be a total waste of time. But I need them to be defined somewhere. My current idea is to have _another_ class CGuiEntryImplementation, which defines all the functions, and is inherited by CGuiButton. Then, in CGuiButton, define the functions as follows
inline int  GetPrimarySelected(void)   { return CGuiEntryImplementation::GetPrimarySelectedImp(); }

So in other words I have something like (all the classes ABOVE the line are exposed to the host application)
CGuiEntry
|
|
CGuiButton
|
----------------------------------------------------
|
|       CGuiEntryImplementation
|          /
|         /
|        /
|       /
CGuiButtonImplementation

(Wow it worked!) Now personally, I do not like that method, as it still involves me writing all the virtual functions out in the derived classes (but at least I don’t have to do the actual implementation). But I cannot think of a more elegant solution that allows me to expose both the CGuiEntry and CGuiButton classes (they both need to be exposed so host applications can put all there gui objects into one list and call Draw on each one. I don’t want to have separate lists, as there are currently 10 different elements and that will probably increase) If you can give me any ideas or even better solutions to this I would be very grateful. Thanks in advance Spree

Share on other sites
I don't want to sound glib, but seriously just don't do the DLL thing. It's a waste of time. There is no need to have any part of your engine in a DLL. You will spend so much time figuring out link errors, passing around data, and all that crap ... to really get nothing.

Consider what a DLL is for: dynamic loading of functionality. Now, do you really think there will be a time when you will _not_ need the GUI in your engine?

Just about any use of a DLL in a game engine is without purpose, and will cost you significant development time. Just statically link the functionality. If you want a separate build without the code in it, make a separate project to build it that way.

Share on other sites
well for small projects that might be right, but if you want to allows others to modify the actual game you had to put things into a dll otherwise you had to release the entire engine code see hl1

Share on other sites
Quote:
 Original post by Basirorwell for small projects that might be right, but if you want to allows others to modify the actual game you had to put things into a dll otherwise you had to release the entire engine code see hl1

Sure, but even then you can limit what you put into a DLL to a single client-code library. Or you can make your game scripted, and open up scripting.

I just think too many people focus on the DLL path when they are working on an engine (and this is from experience doing it myself).

Share on other sites
I dunno about you guys, but my game engine is going to have an editor of some sort which is a totally seperate EXE. And while I have no idea about the specifics of doing such a chore, I would bet that a dll would make it way easier to have 2 seperate applications using the same code. ;) Unless you use your game exe as your editor exe, but that seems like a design error to me.

Needles, I prefer to make dlls. Though I dont get any link errors.

Now, for the original post. Why do they have to be abstract to export from a dll? Maybe I'm missing something, lol. I have a pair of dll's in my engine (so far) and almost all of my classes are exportable.

I think all you should need is a CGuiEntry base class, which is abstract as you said, for the most part. Being abstract means having at least one pure virtual function (correct here if I'm wrong), but it doesnt mean ALL of them have to be pure virtual. I think you might be assuming that an abstract class can have no implementation (or maybe I'm assuming it can, lol). Reguardless, you would want everything that all GUI elements share to be in CGuiEntry, such as Draw() and OnClick, OnHover, OnDrag (wouldnt it be cool to have drag/drop and movable gui elements) type events. And depending on how you store your gui objects, calling Draw() on them is trivial simple if the functions. Every subclass of CGuiEntry will then draw themselves, and recieve all common events, which they will all handle differently depending on their implementation. Another great thing would be to have your GUI support callbacks, but I've no idea how to implement that (tried once long ago, and failed).

Maybe I'm missing the problem..

Share on other sites
The only implementation a base dll class can have is that which is carried out in any inline functions, defined within the classes .h file. But, if you include (on Windows based machines) the associated .lib file, then it can have all the functionality you want.

But unfortunatly, you cant included the .lib file on all platform, so I need my system to be absolutly dynamically linked.

But I have found a solution, which is to have the CGuiEntityImplementation class contained within the CGuiEntry, which means I can then dynamically call the correct implementation based on the gui object I am using at the time.

As for callbacks, they are pretty simple to implement.

You could have callbacks defined for OnClick for example:

// Define the callback typedeftypedef int (*FOnClickCallBack)(class CGuiEntry* _entry, etc...);// In your classclass CGuiButton{protected:  FOnClickCallBack  onClickCallBack;  // Etc. Etc.  // Init the callback  CGuiButton::CGuiButton(void)  {    onClickCallBack = NULL;  }  // Etc. Etc.};

The in your button code for example:

void CGuiButton::AssignOnClickCallBack(FOnClickCallBack _callBack){  onClickCallBack = _callBack;}

And then when the button is finally clicked
void CGuiButton::OnClick(void){  // Do you click stuff here  // Call the callback  if (onClickCallBack)    onClickCallBac(this);}

As for the original comment about not using Dll's, I can understand the need for a project not using Dll's if the project is a small one man affair. But my engine is being used by many different people, all with different needs. Some dont need the Gui (or any of the other plugins), some do if only for debug purposes.

As the engine automatically checks for and loads the dll's it finds, then the host application doesnt have to be changed in anyway, just remove the dll and your done.

The engine has been Dll based for two years, and I have of course had a few problems, but if the project and code is correctly designed and implemented, then any linking errors are pretty simple to resolve.

Spree

• What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 15
• 9
• 11
• 9
• 9
• Forum Statistics

• Total Topics
634134
• Total Posts
3015742
×