|
I have a very simple DLL
dll header
__declspec(dllexport) int StartUp();
dll cpp
__declspec(dllexport) int StartUp()
{
return 42;
}
my console app
typedef int (*MYPROC)();
int _tmain(int argc, _TCHAR* argv[])
{
HMODULE c1 = LoadLibrary(L"client1.dll");
MYPROC ProcAdd = (MYPROC) GetProcAddress(c1, "StartUp");
int i = (ProcAdd)();
return 0;
}
GetProcAddress fails, returning NULL. (LoadLibrary suceed)
ANy ideas why?
|
|
|
|
|
I would guess name mangling. Try making your code look like this:
extern "C" __declspec(dllexport) int StartUp();
Steve
|
|
|
|
|
Thanks 
|
|
|
|
|
To complement what Stephen said: in C++ you have the ability to overload a function (that is, provide the same name but different arguments type or a different number of argument). Thus, in that case, a function is identified not only by its name but also by its parameters.
In C, function overloading doesn't exist thus functions are identified only by their name.
This mechanism is used by the linker to identify the different functions, in C he will use only the function name and in C++ he will use the function name plus a 'description' of the parameter list.
So, if you declare that the function has a C linkage (by using the keyword extern "C"), you specify that the function use the C linkage, meaning that only its name is used to identify it. But that also mean that you won't be able to overload the function.
|
|
|
|
|
For future reference, you can run dumpbin /exports or depends on the DLL to see exactly what the exported name is. In your case, your original code wasn't working because the function was exported as a C++ function and was given a decorated name by the compiler.
|
|
|
|
|
Hey,
I've created an SDI MFC app that needs to switch between several standard view classes and a Direct3D surface. I've managed to do this by preserving the HDC, destroying the CView, creating a new one, attaching the HDC then creating a new directx surface within the view class.
The Texture for each triangle set is loaded from a file when the vertex buffer is created. This means the textures are reloaded everytime the view is changed, which is taking too long.
I've tried not releasing the texture buffers between view switches, but the textures then get mixed up and some are missing.
My question is, what is the best way cache / store textures that need to be reloaded alot ?
Also do i need to destroy the DirectX Render Surface at all or can it be hidden behind a CView class?
Thanks
|
|
|
|
|
This is how I have done things:
1. Create a class for loading and unloading textures.
2. Track the filename of each texture loaded.
3. Keep a reference count for each texture.
4. If the texture is already loaded, return the same pointer.
When more than one method requests the same texture they get the same pointer. You can lock the texture by increasing the ref count and release it when the ref count reaches 0. If you keep this class in global scope, you will never need to reload the same texture more than once.
spacecadet10 wrote: Also do i need to destroy the DirectX Render Surface at all or can it be hidden behind a CView class?
You need to release everything you create. Usualy D3D will attempt this on exit, but it's better for you to do it.
|
|
|
|
|
Thanks for the response chap.
I've tried to do that but i'm using the D3DXCreateTextureFromFile() method to load a mixture of bmp and dds files.
when the LPDIRECT3DDEVICE8 i used to load the file gets released, everytime the user switches to a different view class, the textures get all screwed up.
Is it possible to temporarily hide the Direct 3D device, while looking at another view ?
Cheers
|
|
|
|
|
I'm am currently writing an application where a user tries to find his way in a maze. I want the user to be able to control his movements either by clicking on 3 buttons in the main window, or by using these 3 arrow keys: up, left, right. The 3 buttons are linked to the three functions: OnBgofront(), OnBturnleft() and OnBturnright() - those three functions manage the maze navigation. When the user wants to start the maze, he clicks the button labeled GO which is linked to the OnBgo() function.
My problem is that, after the GO button is clicked, if the user start by pressing one of the arrow keys instead of using one of the three buttons, nothing happens: no movement in the maze. On the other hand, if one of the 3 buttons is clicked, there is a movement in the maze, and then after that the arrow keys behave normally (ie the functions OnBgofront(), OnBturnleft() and OnBturnright() are called). Could you tell me how I could modify my code so that the user can use the arrow keys whithout having to press one of the 3 buttons first?
A BIG thank you in advance
Marc
oh! here is the OnBgo function code:
void MyAppDlg::OnBgo( )
{
MSG tMsg;
m_bRunning = true;
:
:
while ( m_bRunning )
{
:
MyGrid.display (m_maze);
:
while ( ::PeekMessage(&tMsg, NULL, 0, 0, PM_REMOVE))
{
if (tMsg.message == WM_KEYUP)
{
switch ( tMsg.wParam )
{
case VK_UP:
OnBgofront();
break;
case VK_LEFT:
OnBturnleft();
break;
case VK_RIGHT:
OnBturnright();
break;
case VK_ESCAPE:
m_bRunning = false;
}
}
else
{
::TranslateMessage(&tMsg);
::DispatchMessage(&tMsg);
}
}
}
}
Marc Melillo
biomedical engineer
Universite de Montreal
marc.melillo@umontreal.ca
|
|
|
|
|
I used the CSplitterWnd::GetActivePane(int&, int&) function and it worked fine with VC++ 6.0.
Recently I started the process of moving the code to the new VC++ 2005.
Under VC++ 2005, the code compiled OK but it does not run because the GetActivePane function
is somehow made obsolete (see afxext.inl). Any idea why?
So how do I get this function back or any ways to get around of this problem?
Thanks
Ted
|
|
|
|
|
I'm still on 2003 but I see nothing in the 2005 docs online that says the method is obsolete.
That would break alot of MFC apps.
They do move stuff around between MFC versions though (from cpp files to inline, etc.) which
can potentially cause problems (shouldn't affect runtime though).
Are you sure you aren't mixing MFC versions anywhere?
Mark
|
|
|
|
|
I'm pretty sure I'm not mixing the versions.
I checked MSDN and nothing was said about GetActivePane being obsolete. Might be
a bug/mistake on MS side?
Also, VC++ 2005 changed the scope of variables defined for a loop and generates
errors in cases like this:
for(int i = 0; i < 10; i++)
A = i*2;
for(i = 11; i < 50; i++) // this will generate an error, as i is not declared.
B = i*3;
Have to edit a lot of source code to remove the compiler errors.
Ted
|
|
|
|
|
TedWu wrote: Also, VC++ 2005 changed the scope of variables defined for a loop and generates
errors in cases like this:
Great  I have that to look forward to as well.
I thought that was changed in the C++ language a long time ago but I remember being surpised
that in VC.NET 2003 it still had to be coded like you've shown.
Mark
|
|
|
|
|
Found out what the problem is. MS changed the function call to
GetActivePane(int *, int *) from GetActivePane(int &, int &).
They left the old one there so your code will compile but won't run.
That's going to break up a lot of programs.
|
|
|
|
|
Ohhh. Several things changed like that from VC6.
TedWu wrote: They left the old one there so your code will compile but won't run.
That's messed up  I'd rather it fail compile so I can change the code appropriately.
Thanks for letting me know!
Mark
|
|
|
|
|
In VS.NET 2003 F4 would provide a browser for viewing/adding/editing/deleting message handlers and virtual functions - I'm completely unable to find the same in VS 2005 Pro. Has this functionality been dropped into a wormhole or ... something? Can anyone help?
Also the 'Add Message Handler' wizard chokes terminally on source that has been through the VS.NET 2003 mill a thousand time. Ach - this on SP1 as well. Come on 'softies - this is almost as bad as the VC++ 4.0 bollix.
Thx++
Jerry.
|
|
|
|
|
Hi Jerry,
Open the "Class View" and right click on your dialog class,
then take properties, and a window will popup with buttons at
the top for events, messages, etc.
You are right, it is not intuitive.
Brian
|
|
|
|
|
Brian, many thanks. I wonder if there is a shortcut to / pin for this view.
|
|
|
|
|
I have a DLL where I'm exporting a class...
No problem if I'm using implicit linking (inclufing the headerfile in my application, and linking to the lib-file)
Is it possible to use the exported class when using explicit linking (Loadlibrary and GetProcAddress)
TIA
|
|
|
|
|
Anders Molin wrote: Is it possible to use the exported class when using explicit linking (Loadlibrary and GetProcAddress)
No, explicit linkage can only retrieve the address of a function. It cannot 'import' a class.
But, you could still do it using a little 'trick': use a function that create the class instance and returns it. Or even better: it returns an interface of the class (this way, you only need to distribute the header containing the interface with your dll and not the cpp file of the class)
|
|
|
|
|
Yeah, I was already planning to just export en "interface", eg. a class with only abstract functions.
But if my function returns a pointer to a class derived from the interface, can the application just use it then (if it have the header file)?
If multible applications or dll's lolad my dll, is there any way to make sure they get a pointer to the same instance of the class?
Yes, I'm not that good with DLL's, it's really one of my weeker sides 
|
|
|
|
|
Anders Molin wrote: But if my function returns a pointer to a class derived from the interface, can the application just use it then (if it have the header file)?
Don't return a pointer to the derived class but to the base class. So it should look like this (this code is only in the dll):
class CBaseClass
{
};
class CChildClass : public CBaseClass
{
};
DLL_EXPORT CBaseClass* GetClass
{
return new CChildClass;
}
In this way, the application will only need to know the interface of the class (so you won't need to add the cpp file of your child class in the application that uses the DLL).
Anders Molin wrote: If multible applications or dll's lolad my dll, is there any way to make sure they get a pointer to the same instance of the class?
For this part, I don't know. The 'standard' singleton pattern won't work in this case because static variables in your dll are not accessible from the application.
|
|
|
|
|
Thanks 
I did plan to just return a pointer to the base class, I did express it badly. Sorry...
Cedric Moonen wrote: For this part, I don't know. The 'standard' singleton pattern won't work in this case because static variables in your dll are not accessible from the application.
Exactly...
My DLL is loaded from multible DLL's which are all loaded from a single application... The class is some communication layer, and all the different dll's need to get a pointer to the same instance of this class so they all can send data through the same TCP connection... (does that make sense?)
Any ideas anyone?
|
|
|
|
|
I believe yes, the same way you can allocate and return a pointer to a struct from a DLL's function and still be able to access its members in the calling application.
You have to make sure that both the DLL and the calling application agree on the object being returned. Normally, sharing the same .H file for the object does the trick, but when dealing with objects that have a vtbl in them, you need to also watch out for implementation-specific details. For example, if MS VC++ puts the vtbl at the beginning of the object in memory, and MinGW's gcc expects it at the end of the object in memory, you will not be able to share the DLL between the two. The same technically goes for references, but all implementations I have experience with use pointers behind the scenes. (Trivia: this is why you can pass a pointer to an object to an exported VC++ function that expects a reference to one and it will work correctly).
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Hello,
I have a query regarding recordset retrieval. This is what I have so far.
1.An SDI application(name:Database) without database support and CDatabaseView derived from CFormView
2.A second dialog(name:Dialog1) and its class Cdialog1.
3.A new MFC class CMySet derived fron Crecordset.
4.CDialog1 has a foreign variable m_pSet of type CMySet
The DB connection opens properly using CDatabse.OpenEx()
then i have the following code to open a recordset. "user" is one of the tables I have selected.
CDialog1 dlg;
dlg.m_pSet = new CMySet(m_pDB);
str = "SELECT * FROM User;";
dlg.m_pSet->Open(AFX_DB_USE_DEFAULT_TYPE,str,CRecordset::none)
I get an error at this point, while executing,saying "error retrieving record".Actually on clickin a button on the first main form(which just has a pic) I wanted to have a screen for username and password whiich has to be verified from the DB.
Am i wrong in my approach somewhere. the application builds and compiles jus fine. Kindly help.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
