|
Hi, you should use the CDllClass ( why export it otherwise ) or you should make the Coolfunctions static. ( Right now they only have CDllClass scope ).
|
|
|
|
|
If you check out the exported functions (dumpbin /exports for instance), you'll probably see mangling around the export function names. You have to reproduce this mangling in your GetProcAddress call.
The easiest way to export classes however is to dynamically link with the dll instead of using loadlibrary+getprocaddress. In order to do so, you have to include the class header file, and use __declspec(dllimport) instead of __declspc(dllexport). Usually people use a macro :
#ifdef __EXPORTS_DLL__
#define EXPORTED __declspec(dllexport)
#else
#define EXPORTED __declspec(dllimport)
#endif
void EXPORTED DllClass::methodname(...)
{
}
Back to real work : D-23.
|
|
|
|
|
hi
i like to get the default printer name on windowsNT/2000/xp systems. how can i acheive it
actually i am using EnumPrinters() like below
"EnumPrinters(PRINTER_ENUM_DEFAULT,NULL,5,(LPBYTE)pinfo5,dwBytesNeeded,&dwBytesNeeded,&dwReturned);"
but the above function is working on win95/98
its not supporting please help how can i achieve.
thank you
from
venu
|
|
|
|
|
I think in 95/98/Me, you have to monkey with the WIN.INI file to get the info you need. Try something like this:
TCHAR buffer[MAX_PATH];
::GetProfileString("Windows", "device", "", buffer, MAX_PATH);
(Look up GetProfileString on MSDN for more info.)
The printer info should be in that buffer, although I think it also contains some additional stuff (like the port name) so you may have to parse it a little.
Hope this gets you on the right track.
Even a broken clock is right twice a day.
|
|
|
|
|
Look up the ::PrintDlg Win 32 API Function. There is a flag you can set to retrieve the default information. If you are using MFC, CPrintDlg offers the same functionality. You can get the information without displaying the dialog in either case.
|
|
|
|
|
I need to avoid that a dialog get the focus when it's called.
How can I make this ??
[]'s
Cris.
|
|
|
|
|
do not pass WM_SETFOCUS to default window process.
i.e. in MFC
MyCls::OnSetFocus(*)
{
//cancel this line
//CWnd::OnSetFocus(*);
}
includeh10
|
|
|
|
|
In the ClassWizard don't have the WM_SETFOCUS event. But I did write the event and it's not trigged. Do you know why ??
[]'s
|
|
|
|
|
goto last page, select window, it will appear.
includeh10
|
|
|
|
|
What ??
Last page ??
The WM_SETFOCUS don't appear int the MCF Class Wizard dialg.
[]'s
|
|
|
|
|
What ??
Last page ??
Last page of Class wizard!
if still don't understand, let me know with no hesitate!
includeh10
|
|
|
|
|
Ok, thanks for your help ...
[]'s
Cris.
|
|
|
|
|
'ello,
I have a problem with a CListView derived class, it refuses to show the Header control when in report view. I've tried a few things including commenting out all except
GetListCtrl().MofifyStyle(LVS_TYPEMASK,LVS_REPORT);<br />
GetListCtrl().InsertColumn(0,"Test",LVCFMT_LEFT,100);
in OnInitalUpdate().
The app is a appwizard produced SDI app with the "Windows Explorer" option enabled" and has the Listview view options buttons on the toolbar, the selected mode shows as the Details mode when the app starts but the CHeaderCtrl() is never created ( GetListCtrl()->GetHeaderCtrl() returns NULL ).
Another appwizard produced app with all the same modes works ok, anyone else as confused as me?
[EDIT]
Never mInd i forgot to delete the defualt (empty) implmentation of OnStyleChanged [/EDIT]
Richard Green
|
|
|
|
|
Does anyone knows how can i capture mouse movements from the driver of the mouse and not by capturing WM_MOUSEMOVE.
I need somethig like "LowLevelMouseProc" for all windows and not only for 2000 and XP.
Thanks.
|
|
|
|
|
::GetCursorPos
Back to real work : D-23.
|
|
|
|
|
Is there any reason why i should not use RegisterWindowMessage() to define messages specific to my applications (i.e. not used for inter-process communication). MSDN says that I should use WM_USER + i to do this, and not RegisterWindowMessage() , but having read several discussions on the topic I am not sure that I see why...
Any ideas?
Alex
|
|
|
|
|
In fact, RegisterWindowMessage() is the most desireable version of a private message.
(WM_USER+const being the least favorable, WM_APP+const intermediate).
You just have to remember to make your handler-function HRESULT name(WPARAM, LPARAM) and use the ON_REGISTRED_MESSAGE() macro.
|
|
|
|
|
jhwurmbach wrote:
In fact, RegisterWindowMessage() is the most desireable version of a private message.
Is that because they're guaranteed to be unique to the string used to identify them and therefore you get less potential conflicts?
Are you saying that there is no situation where a RegisterWindowsMessage is less preferable to a WM_USER + i one?
Cheers, Alex.
|
|
|
|
|
You should never use WM_USER+i , because some i are already used by some (newer) windows controls. You get almost undebuggable errors when you are reacting to messages that are not meant for you.
Use WM_APP+i , this is guaranteed not to be used by Windows internally.
You then only have conflicts with controls from other sources (commertial or third party).
Use of RegisterWindowsMessage() avoids all this at no cost.
No, I cant think of a situation where WM_USER is more preferable than RegisterWindowsMessage() .
|
|
|
|
|
If you are making your own control, WM_USER+x is fine.
However, for application level messages, I have to agree that RWM is better.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
You should use RegisterWindowMessage only. Read this[^] for details!
Best regards,
Alexandru Savescu
|
|
|
|
|
Alexandru Savescu wrote:
You should use RegisterWindowMessage only. Read this[^] for details!
This (and that on message management) was one of the articles I was referring to in my originaly post. I was wondering why MSDN says that you should only use RegisterWindowsMessage() for inter-process messages and WM_USER + i for the others.
I suppose it's just like a lot of the other bits in MSDN - looks absolutely fine until you talk to other people about it...;)
|
|
|
|
|
What I need to do is compare a series of strings (actually filenames) and find potential duplicates. The strings, however, are unlikely to contain literal duplicates so what I need to do is find similar strings. Has anyone ever had experience of this before?
Cheers
James
|
|
|
|
|
Yes, this is a common need in credit applications (find names mistyped). In your case, I suggest the Levenshtein String (or Edit) Distance algorithm for this. You can find tons of implementations in C++ on google.
lazy isn't my middle name.. its my first.. people just keep calling me Mel cause that's what they put on my drivers license. - Mel Feik
|
|
|
|
|
Thanks for that Daniel. I took a look at it and that solves part of my problem. The other part of the problem is that I need to find duplicates based on whether a string has some elements of another.For example, I would want to match the following filenames
c:\Music\Albums\Vines\01 - Highly Evolved.mp3
c:\Music\Singles\The Vines - Highly Evolved.mp3
f:\Stuff\Vines - Highly Evolved.wma
Do you know if there is a standard way to do this? I don't think there is but I just wanted to make sure.
Cheers
James
|
|
|
|