|
Sorry, can't help you there. I've never used MFC sockets - I always use the raw Win32 versions.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
The help files recommend that user messages be defined in the range WM_USER to 0x7fff, but opening the Resource Symbols dialog to create a new ID and letting it choose the value seems to work fine. Does anyone know if there is anything wrong with this?
Best Regards
Cliff Hatch
-- modified at 14:42 Wednesday 24th May, 2006
|
|
|
|
|
Cliff Hatch wrote: The help files recommend that user messages be defined in the range WM_USER to 0x7fff...
It should be WM_APP.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Depends on the usage. If you are defining a message that will only be used within the application, then use WM_APP. If the message is for a control that could be used in other apps the use WM_USER. If it is a message that is used to communicate between different modules then use ::RegisterWindowMessage().
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: If the message is for a control that could be used in other apps the use WM_USER.
WM_USER should not be used at it can conflict with messages that Microsoft uses. RegisterWindowMessage() is the safest/preferred method in any case.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Thanks guys.
I can see that there is a problem if messages conflict, but what's puzzling me is why does it matter what the value is so long as it is unique - and if I use the Resource Symbols dialog to create it, doesn't that guarantee uniqueness?
Is it a matter of standardisation and ease of maintenance perhaps?
Best Regards
Cliff
|
|
|
|
|
|
Thanks Michael, that answers my question perfectly. 
Best Regards
Cliff
|
|
|
|
|
I've created a handler for a user defined message with the following declaration:
afx_msg LRESULT OnIdleScan(WPARAM wPar, LPARAM lPar);
It works, but what value (of type LRESULT) should the function return, and what does the system do with this? I assume it is not passed back via PostMessage, because it doesn't wait for the handler to execute. I'm arbitrarily returning 0 at present.
Best Regards
Cliff Hatch
|
|
|
|
|
The result is not used for PostMessage()'s, but it is when using SendMessage(). The return value is completely up to you. I usually just return 0, if its not important.
I have come across a few messages that are used in this way to indicate success or failure.
I Dream of Absolute Zero
|
|
|
|
|
Thanks for your reply. It makes perfect sense now.
Best Regards
Cliff
|
|
|
|
|
I have read several sources on when to use the extern keyword and when not to, but I still have some confusion.
Could someone explain the proper use of extern when it comes to variables and function:
extern void MyFunction(void);<br />
extern int MyVariable;
Thanks.
|
|
|
|
|
masnu wrote: Could someone explain the proper use of extern when it comes to variables and function:
extern void MyFunction(void);
extern int MyVariable;
In both cases, it specifies external linkage (i.e., is visible from files other than the one in which it's defined).
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
you use extern when you want to tell the compiler the type of a variable or function which is defined in another file.
if you have a variable called blah, of type int, at global scope (not static, or local to a function) in foo.c and you want to use it in bar.c, you would put "extern int blah;" somewhere in bar.c, or in a file that bar.c includes. that way, when the compiler is working on bar.c, it knows the type of the variable 'blah'.
the linker will come around later and make sure all references to 'blah' are looking at the same thing.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Hello. I'm getting some linker errors involving jpeg/png/tiff libraries after converting my project from VS6 to 2005.
------ Build started: Project: MyProject, Configuration: Debug Win32 ------
Linking...
Creating library .\Debug/MyProject.lib and object .\Debug/MyProject.exp
libpng.lib(pngrutil.obj) : error LNK2001: unresolved external symbol __iob
geotiff.lib(cpl_serv.obj) : error LNK2001: unresolved external symbol __iob
libjpeg.lib(jerror.obj) : error LNK2001: unresolved external symbol __iob
libtiff.lib(tif_win32.obj) : error LNK2001: unresolved external symbol __iob
libpng.lib(pngwutil.obj) : error LNK2019: unresolved external symbol __iob referenced in function _png_write_sPLT
libpng.lib(pngerror.obj) : error LNK2001: unresolved external symbol __iob
.\Debug/MyProject.exe : fatal error LNK1120: 1 unresolved externals
-------------------
Any thoughts on why I would be getting these? And how to fix them?
Thanks for any help.
|
|
|
|
|
CodeGoose wrote: Any thoughts on why I would be getting these?
By not linking with the CRT DLL perhaps. 
Do you have the latest SDK installed correctly?
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
|
I do have the latest sdk installed.
I am, however, using the same dll's that I was using under VS6. So maybe I will try recompiling those under 2005 and see how that goes.
Might be back with more questions if that doesn't go well
|
|
|
|
|
Hi All,
As you might know, there are tons of articles accross CodeGuru, CodeProjects, and many other programming info sites about owner-draw components. Some of them describes how to do owner-draw in detail. Many of them provides a re-usable class so that people can download and use.
I like to publish a book that describes how people can do the owner-draw components themselves, explain the solution to the general owner-draw operations.
My questions are:
1. Is there any book with related subjects that has already been published?
2. If there is no such book, is it too late to write such a book that uses Win32 API, MFC, WTL? Or are Win32 API, MFC, WTL considered out of date technologies that there is no market for books that describe the use of these technology any more?
I appreciate if any one can give me some good answers on above questions.
Thanks
|
|
|
|
|
|
Topic in microsoft.public.windowsxp.security_admin
WMI settings for remote access on XP
From: Jerry Bryant [MS] - view profile
Date: Fri, Jan 25 2002 4:09 pm
1. the user needs to either be an admin on the XP machine or have remote
enabled privilege set on the XP machine
2. Win2k needs the SP because XP requires at least Packetlevel
authentication and the SP fixes a bug in Win2k to correctly allow
Packetlevel connections
3. if the XP machine is in a workgroup, you won't be able to remote in
anyways as all incoming connections to the XP machine will be reduced to the
guest account (this is by-design of the OS), if in a domain, it should work
given the previous 2 statements are fulfilled.
How to enable remote privileges on the XP machine:
1. Right Click "My Computer", choose "Manage"
2. Open "Services And Applications", right click over "WMI Control" and
choose "properties"
3. Click on the "Security" Tab, highlight the namespace you want to give
security to (most likely root\cimv2) and click the Security button
4. add the user, and check "Remote Enable"
also check out this: http://support.microsoft.com/kb/q282949/
if you are using XP home in Step #3 behavior cannot be
changed. If you are using XP Pro in a workgroup you can change the behavior
via the local group policy:
Computer\Windows Settings\Security Settings\Local Polices\Security Options:
Network Access: Sharing and security model for local accounts:
In unjoined WinXP Pro the ForceGuest behavior is on by default. This
will cause all inbound connections to be anonymous (null)
connections. Try disabling the ForceGuest behavior by setting the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest
value to 0 and reboot.
The "firewall" option on the LAN connection must be disabled.
Regards
Microsoft MVP in Visual C++
http://blog.joycode.com/jiangsheng
|
|
|
|
|
I'm using the MFC collection data types in a VC++ 2003 application and am getting the "conversion from 'INT_PTR' to 'int', possible loss of data" when calling collection functions like GetSize() and such.
I know these "Warnings" are 64-bit Portability warnings that occur when using the default /Wp64 command line option. I am attempting to accomodate the warnings and adapt my code so that it will compile fine in a 64-bit environment (within reason)
Original code: (Used to work fine in Visual C++ 6.0)
///////////////////////////////////////
// Member variable
CArray<int,int&> m_someArray;
// typical usage
int nObjectCount=m_someArray.GetSize();
///////////////////////////////////////
My question is...
Which type (or typedef) should I use for my offset (int, INT, INT_PTR)?
int nObjectCount=(int)someArray.GetSize(); // OR
INT nObjectCount=(INT)someArray.GetSize(); // OR
INT_PTR nObjectCount=(INT_PTR)someArray.GetSize();
Thanks in advance for any guidance.
|
|
|
|
|
|
I'm not sure if that will properly prepare me for 64-bit compiling later as the standard types are going to remain 32-bit in size. I was under the impression that pointers were the only values that would be 64-bit without explicitly asking for it like _int64, DWORD64, INT64 etc...
size_t is defined as an unsigned int which would still be 32-bit under the 64-Bit Windows abstract data model.
Boy this is confusing...
|
|
|
|
|
size_t is 32 bits long under 32 bits system (unsigned long), but 64 bits long under 64 bits system (__int64) !!!!
so it is exactly what you need, isn't it ?
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
