|
Thanks.
If we look at the MSDN help for GetProcAddress it says "The GetProcAddress function retrieves the address of an exported function or variable from the specified dynamic-link library (DLL)." Hence, we cannot use GetProcAddress in this scenario.
Regards,
Paresh.
|
|
|
|
|
It is possible, just a little messy.
Steve
|
|
|
|
|
Please let me know if you find a way.
Regards,
Paresh.
|
|
|
|
|
First you have to find the mangled name of the function you want to import. Probably the easiest way to do this is generate a linker error. For example:
class CMyClass
{
public:
void MyFunction();
};
void main()
{
CMyClass mc;
mc.MyFunction();
}
Since the function CMyClass::MyFunction is not defined (it is declared) the linker produces the following error message:
“error LNK2001: unresolved external symbol "public: void __thiscall CMyClass::MyFunction(void)" (?MyFunction@CMyClass@@QAEXXZ)”
I have underlined the mangled name.
Use this name when calling GetProcAddress
Assume the following typedef:
typedef void (CMyClass::*PMyFunction)();
Then our code would look like this:
FARPROC pRaw = GetProcAddress(hModule, "?MyFunction@CMyClass@@QAEXXZ");
PMyFunction pFun;
*(FARPROC*)&pFun = p;
CMyClass mc;
(mc.*pFun)();
All in all it's a bad design and should not be contemplated; the whole think stinks of hack. Use COM instead.
Steve
|
|
|
|
|
|
|
Or can put the following code in DLL to create object for the class MyClass in Client Application
extern "C" __declspec(dllexport) MyClass* CreateObjectofMyClass()
{
return new MyClass();
}
extern "C" __declspec(dllexport) MyClass* DeleteObjectofMyClass(MyClass *a)
{
delete a;
}
VIBIN
"Fool's run away,where angle's fear to tread"
|
|
|
|
|
This will not help as it stands. The DLL contains the class’s functions and the EXE (what loads the DLL and wants to call into it) will contain the class definition only (no function definitions). You still need the addresses of the functions of the class in the DLL; you’ve only got the address of the class itself. You can get around this by using virtual functions however.
Steve
|
|
|
|
|
Please refer this[^].
Please also have a look at this[^].
Regards,
Paresh.
|
|
|
|
|
This works for me in Visual Studio 2008 / C++ for a static member function of a class, if there's only one class in the DLL:
* Define the class .h and .cpp files in the usual way. __declspec(dllexport) seems neither necessary nor helpful. For example:
class MyClass
{
public:
static int func (int argc, char * argv []);
};
* Create a .def file for the DLL project: Project | Add New Item... | Module-Definition File (.def)
* In the .def file, export the name(s) of the static member function(s) that you want to find through GetProcAddress(). For example:
LIBRARY "DLLProjectName"
EXPORTS func
* Note that the .def file doesn't declare any MyClass:: scope. I get linker "undefined symbol" errors if I try to include the class scope. I get linker ambiguity errors if there are multiple definitions of func in the library, even if they're at different class or namespace scopes.
* Set the project properties to use the .def file: Project | Properties | Linker | Input | Module Definition File
* In the program that will use this library, load the DLL with LoadLibrary(). Note that the DLL file name needs to be passed as a wchar_t* (not just char*).
* Get the function pointer with GetProcAddress with the un-scoped name you put in the .def file:
HINSTANCE lib = LoadLibrary (...);
typedef int (* FuncT) (int, char * []);
FuncT func = FuncT (GetProcAddress (lib, "func"));
func (argc, argv);
* I don't know why this works without a class scope on func, or why it fails if I try to include the scope.
* The .def file seems to handle the C++ name decoration issues; it's not necessary to know the decorated name.
* I couldn't get this to work with only __declspec(dllexport) and no .def file.
* With the .def file, __declspec(dllexport) doesn't seem to make any difference.
* I haven't yet tried to create an instance of the class and invoke it's non-static functions from the loading program (outside of the DLL itself). I guess that's next on the agenda. Maybe I'll need
to __declspec(dllexport) the class for that ...
|
|
|
|
|
Hi,
I have defined handlers for WM_LBUTTONDOWN and WM_LBUTTONUP. The routines do receive control when pressing/releasing the button, EXCEPT if the mouse is over a static control - and I want to gain control exactly in that situation. In fact, the handlers don't receive the control if the mouse is over any control on the main window, only if the mouse is over an area of the main window, where there is no control.
I can process the CLICKED event for that control, but that's not what I need.
This particular control does not have any message handler. The documentation states
If the mouse is not captured, the message is posted to the window beneath the cursor
but ON_WM_LBUTTONDOWN and LBUTTONUP don't accept a specification of the control. How can I catch this event related to a specific control?
|
|
|
|
|
You can subclass your control. Suppose you have a static control on which you want to handle the notifications for WM_LBUTTONDOWN and WM_LBUTTONUP. Derive a class from CStatic( say you name the derived class as CExStatic). Create a member variable for the static control and change CStatic to CExStatic.( Add the header file CExStatic.) You can implement the notifications and handle the behavior in the derived class.
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
I was afraid of this answer, I thought I can somehow avoid the trouble. Anyway, thanks.
|
|
|
|
|
If you use the SS_NOTIFY style on your static controls they will notify their parent window when the user clicks on them.
It's not rocket surgery!
Within you lies the power for good, use it!!!
|
|
|
|
|
That's what I too believed, however, that is not so.
I had an ON_BN_CLICKED handler for this control, which worked, but as it turned out, SS_NOTIFY does not cause the xBUTTONxxx events pass to the parent.
|
|
|
|
|
Vancouver wrote: I thought I can somehow avoid the trouble
It's not much trouble. MFC does the work for you 
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
It was not MUCH trouble, for sure, but it increases the amount of code, it requires two new source files, it requires duplicating some handlers. I am not lazy to do that, but I like compact code, the smaller the better.
Plus, my SetCursor is not working any more, not only in the new handlers, but not even in the main window, and I don't see the connection.
|
|
|
|
|
Vancouver wrote: Plus, my SetCursor is not working any more, not only in the new handlers, but not even in the main window, and I don't see the connection.
Not working how? Do you have a cursor defined for the window class or have you set it to NULL?
Also, how have you subclassed the control?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
As I posted, it worked yesterday, before I subclassed the control, and it is not working any more. I can't claim, that the subclassing is to blame, as it is not working in the main window either.
The questions indicate, that there is no point to discuss this subject here and now. I have to work backwards and see, at which point the problem appears respectively disappears.
|
|
|
|
|
Vancouver wrote: The questions indicate, that there is no point to discuss this subject here and now. I have to work backwards and see, at which point the problem appears respectively disappears.
Cool.
I would start with just an empty, CStatic-derived class - with just the constructor implemented.
Create objects of the derived type to encapsulate the CStatic controls in the window.
Everything should work normally at that point. If not, then the problem is elsewhere - maybe
an existing problem has been exposed.
Once it works like that, add the mouse button handlers to the derived class. Initially, your
implementation can just call the base class implementation. Once that is done, you'd probably
simply need to notify the parent window of the clicks - via a message, member method, etc.
That should be the extent of the subclassing necessary for the controls 
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Mark, I have to disappoint you. I am in the middle(?) of a program, many thousands of code lines. I don't intend to go back in time and in code.
I had come to the idea, that it would be nice to have a feature controlled with the mouse button hold down. (No, I don't need any suggestions, how to realize that. I only need "my cursor" back.)
|
|
|
|
|
Ok no problem
There's lots of us here that can help with the cursor problem if needed!
Good luck!
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I'm guessing it's not possible to export a Class method - unless it's static?
So I would need to provide a class wrapper around my DLL exported functions?
Just curious
I'm finding the only constant in software development is change it self.
|
|
|
|
|
See if this[^] helps.
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
how can i get the item value of selected records in a list control.
thanks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
