|
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! ]
|
|
|
|
|
Yes. I apologize as I did not dig deeper to find the __int64.
Thanks again for helping remove the confusion.
|
|
|
|
|
I'm confused too.
<blockquote class="FQ"><div class="FQA">bob16972 wrote:</div>int nObjectCount=m_someArray.GetSize();</blockquote>
Are you compiling for 64 bit or 32 bit? Even if you are compiling for 32 bit, GetSize() returns an int and you are assigning that to an int, so there is no potential for truncation. If you are compiling for 64 bit, I can only assume that the the GetSize() method no longer returns an int, but returns some other type. Are there #ifdef's in the CArray header file that show what it returns differently for a 64 bit compile? If there are then you have to put the same kind of #ifdef's for your declarations prior to the assignment call.
But like I said at the start, I'm confused.
Chris Meech
I am Canadian. [heard in a local bar]
The America I believe in has always understood that natural harmony is only one meal away from monkey burgers. [Stan Shannon]
GOOD DAY FOR: Bean counters, as the Australian Taxation Office said that prostitutes and strippers could claim tax deductions for adult toys and sexy lingerie. [Associated Press]
|
|
|
|
|
GetSize used to return an int.
On VC++ 2003 it returns an INT_PTR
I'm doing everything under 32-bit but the warnings came up so I'm trying to use the INT_PTR but it's like a chain reaction since anything that uses the value needs to be prepared for it. In this case, it's an accessor function for a private member so my return value needs to be INT_PTR I guess and on down the line. It just had enough ripple effect that I thought I needed to question it.
Sorry about the confusion.
|
|
|
|
|
bob16972 wrote: On VC++ 2003 it returns an INT_PTR
That's a pretty significant change.  I'm guessing that this means you are given the address of where the size is stored, and thus when the size changes, in effect you will be notified. Regardless of the reason though, I think you need to change your code to
INT_PTR pObjectCount = m_someArray.GetSize(); and that should compile with the option you previously specified and not produce a warning.
Chris Meech
I am Canadian. [heard in a local bar]
The America I believe in has always understood that natural harmony is only one meal away from monkey burgers. [Stan Shannon]
GOOD DAY FOR: Bean counters, as the Australian Taxation Office said that prostitutes and strippers could claim tax deductions for adult toys and sexy lingerie. [Associated Press]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
