|
Does anybody know how to achieve desktop resizing effect similar for example to what infogate or netzero do?
JRN
|
|
|
|
|
I'm not sure what netzero does, but I do know that creating an AppBar (like the taskbar) can change the size of the Work Area of the desktop.
Chris Richardson
|
|
|
|
|
Thanks a lot!. Here's a link to an article on how to create AppBars:
http://www.microsoft.com/msj/defaulttop.asp?page=/msj/archive/s274.htm
|
|
|
|
|
Hi,
I wanna load some overloeded function exported from a dll by using LoadLibrary and GetProcAddress.
This is the way the exported function is declared in the dll:
BOOL CDllClass::CoolFunction(const char* pszChar,DWORD dwProperty)
{
...
}
BOOL CDllClass::CoolFunction(LPCWSTR pszChar,DWORD dwProperty)
{
...
}
The CDllClass is exported with __declspec(dllexport)
I try to load CoolFunction in this way:
typedef BOOL (CALLBACK* LPFNFUNC)(const char*,DWORD);
...
HMODULE m_hDll = LoadLibrary("mydll.dll");
if (!m_hDll)
{
AfxMessageBox("Error: Cannot find mydll.dll");
return;
}
LPFNFUNC fnMyFunc = (LPFNFUNC)GetProcAddress(m_hDll,"CoolFunction");
if (fnMyFunc == NULL)
{
AfxMessageBox("Error: fnMyFunc == NULL");
return;
}
Problem: GetProcAddress returns NULL.
Question: How does GetProcAddress know which overloeded function to load? Is there some other problem in this code snippet?
Thanks
R.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
