Jump to content
  • Advertisement
Sign in to follow this  
SpreeTree

Exposing classes in a dll and implementation

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Basiror
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


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 this post


Link to post
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 this post


Link to post
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 typedef
typedef int (*FOnClickCallBack)(class CGuiEntry* _entry, etc...);

// In your class
class 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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!