|
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.
|
|
|
|
|
Use this:
CListCtrl::GetFirstSelectedItemPosition()
CListCtrl::GetNextSelectedItem()
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
Is it possible to place an expaned macro inside a string literal?
#define NUMBER 123
...
strcmp(SomeString, "NUMBER"); I want the strcmp line to expand to:
strcmp(SomeString, "123"); I need to use the macro as both a string and an integer, and I want to avoid atoi() etc.
I looked at the # and ## preprocessor operators but can not seem to get them to work.
Any ideas greatly appreciated.
Darker than a black steer's tookus on a moonless praire night
Within you lies the power for good, use it!!!
|
|
|
|
|
I got the following from the source of Boost's preprocessor library:
// CommandLine.cpp : Defines the entry point for the console application.
//
#include "StdAfx.h"
#include <iostream>
#define STRINGIZE(text) STRINGIZE_A((text))
#define STRINGIZE_A(arg) STRINGIZE_B ## (arg)
#define STRINGIZE_B(arg) STRINGIZE_I ## arg
#define STRINGIZE_I(text) #text
#define NUMBER Hello
void main()
{
using namespace std;
cout << STRINGIZE(NUMBER) << endl;
}
Steve
|
|
|
|
|
That works, Thanks!
Now I just have to figure out how it works. Looks like black magic to me so far.
It's not rocket surgery!
Within you lies the power for good, use it!!!
|
|
|
|
|
To me it looks like gibberish, a bunch of no-op macro steps.
The intermediate steps just wrap several () around the arg.
Just unroll them to see:
SS(T) == SS_A((T))
SS(T) == SS_B(((T)))
SS(T) == SS_I(((T)))
SS(T) == (((#T)))
You may as well as used SS_I(T) to start with.
I have to believe they use SS_A, SS_B, SS_I elsewhere as part of other macros as well.
[EDIT]
Whoops, just tried it, looks like it does do something.
[/EDIT]
-- modified at 20:02 Monday 30th April, 2007
...cmk
Save the whales - collect the whole set
|
|
|
|
|
An explanation to what Stephen posted.
What would be ideal would be:
#define NUMBER 123
#define ASSTR(X) #X
But, when used in:
strcmp(SomeString, ASSTR(NUMBER));
We get:
strcmp(SomeString, "NUMBER"); because the token is converted _before_ it is checked for further macro expansion.
So we have to remove the expansion by one level (the boost example adds an extra 2 levels for some reason):
#define NUMBER 123
#define STR(X) #X
#define ASSTR(X) STR(X)
Now we get:
strcmp(SomeString, "123");
This is because:
- first ASSTR(NUMBER) is replaced with STR(NUMBER)
- _then_ the macro is checked for further explansion and NUMBER is replaced with 123 _before_ STR() is resolved
- so we get STR(123) which gives "123".
...cmk
Save the whales - collect the whole set
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
