|
It turns out that you do not need a macro at all to do what you want.
Try this -
DWORD d = 'cmap';
Please note the single quotation marks.
|
|
|
|
|
Nice!
Out of curiosity what compiler are you using? I think I may have tried that back on VS8 but with errors.
Waldermort
|
|
|
|
|
I currently use VS2010, but I'm sure this works in older compilers, because this type of assignment is used to tag memory allocations in kernel mode code from ages ago.
|
|
|
|
|
WalderMort wrote: Any suggestions?
Why, yes: don't use macros, they make your code unreadable 
No, seriously: using macros is dangerous, with very few exceptions. Regarding your example, your choice of symbol alone already breaks two common safeguards against macro problems:
1. Do not ever use a symbol with starting '_'! This is what the system libraries use internaly to prevent name clashes with any symbols the programmer may define! The problem with name clashes and macros is that macros clash silently, and may break system libraries, resulting in very hard to trace runtime errors (or compiler error,s, if you're lucky)
2. Use capital letters for symbols denoting const or #define symbols. This, also, has to do with preventing name clashes. It may seem overkill, but better be safe than sorry.
I've spent many, many weeks hunting down errors caused my macro name clashes caused by other people's code (and in some cases even by MS #defines!). Do yourself (and everyone else) a favor and don't add to that misery!
|
|
|
|
|
Hi all,
I am trying to play video files in my application. i have used MCIWndCreate function but i am having a problem.
I want to display video on my screen of a particular size, for aciheving this i have created a static control and passed its handle to MCIWndCreate. Video is displayed of its size only but it is cuting from sides i.e its not showing full video.
i have written this line of code
HWND h = m_static1.GetSafeHwnd();
m_Player = MCIWndCreate(h,AfxGetInstanceHandle(),
WS_CHILD | WS_VISIBLE|MCIWNDF_NOPLAYBAR, _T("D:\\2.mpeg"));
How can i do this??
Thanks in advance
|
|
|
|
|
I see from the docs [^]that you've also got the two flags MCIWNDF_NOAUTOSIZEWINDOW and MCIWNDF_NOAUTOSIZEMOVIE - one for preventing the window being sized to fit the movie, the other for preventing the movie being resized to fit the window.
I'd be inclined to try adding the first flag. (never used any of these functions)
|
|
|
|
|
Hello!
I've got a problem with a CHtmlView derived View on Windows 7.
The CHtmlView derived View is embedded in a CTabView with the following code:
int COSTabbedView::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (CTabView::OnCreate(lpCreateStruct) == -1)
return -1;
AddView (RUNTIME_CLASS (CResultView), _T("Results"), 100);
AddView (RUNTIME_CLASS (CBrowserView), _T("Certificate"), 101);
return 0;
}
The view itself is initialized by:
void CBrowserView::OnInitialUpdate()
{
CHtmlView::OnInitialUpdate();
Navigate2(_T("http://www.google.de"));
}
On a Windows XP machine this works fine. The view displays the requested page.
On Windows 7 the status bar of my application says something like "Downloading from www.google.de" and then a new Internet Explorer window will open and display the site but not with "www.google.de" in the address bar, but the path of the temporary downloaded file (!?).
I've been searching around for several days now and found out at least one interesting thing:
When I use Spy++ on WinXP I see the following windows below my view window:
Shell Embedding
+ Shell DocObject View
+ Internet Explorer_Server
On Windows 7 the "Shell DocObject View" and the "Internet Explorer_Server" window are missing.
So I debugged into the creation of the CHtmlView window but they both behave the same on Win7 and XP.
Does anyone have a hint what is going wrong here?
|
|
|
|
|
I need to implement TCP hole punching in my application. I tried to google to find any sample implementation but could not get.
Please suggest me idea behind TCP hole punhing with example...
|
|
|
|
|
|
UDP/TCP hole punching is Communication between two computers without opening ports,
using a third computer to set up the connection
UDP/TCP hole punching is NOT a security violation in any way, even though the name suggests it is.
Once the hole has been punched in the firewall, only connections from the specified client
are accepted through it, it isn't like anyone can get in through the hole.
Get the win32 DLL here:
http://www.cis.nctu.edu.tw/~gis87577/xDreaming/XSTUNT/index.html[^]
It works like this:
A--->proxy --------proxy<---B
|
S
Let A be the client requesting the connection
Let B be the client that is responding to the request
Let S be the server that they contact to initiate the connection
A sends a connection request to S
S responds with B's IP and port info, and sends A's IP and port info to B
A sends a UDP/TCP packet to B, which B's router firewall drops but it still punches a hole in A's own firewall where B can connect
B sends a UDP/TCP packet to A, that both punches a hole in their own firewall, and reaches A through the hole that they punched in their own firewall
A and B can now communicate through their established connection without the help of S
All this does is make both A and B's firewalls think that they have initiated the connection,
just as it would let packets from a web server through ONLY if the client had initiated the connection
to the web server and the packets were expected.
This is not a security risk and software that uses this method should not be looked down upon,
this is how p2p software like AIM and most VoIP clients initiate connections.
TCP hole punching Algorithm
Let A and B be the two hosts, each in its own private network;
N1 and N2 are the two NAT devices;
S is a public server with a well-known globally reachable IP address.
A and B each begin a TCP conversation with S;
the NAT devices N1 and N2 create TCP translation states and assign temporary external port numbers
S relays these port numbers back to A and B
A and B contact each others' NAT devices directly on the translated ports;
the NAT devices use the previously created translation states and send the packets to A and B
The Low TTL is calculated as follow:
Send SYN with TTL of i=1
Wait for ICMP TTL Exceeded message
i = i + 1, loop
Loop until "ICMP TTL Exceeded" messages are no longer received.
The own NAT host has been traversed.
The LOW TTL Value = i + 1.
If the NAT host supports "ICMP TTL Exceeded" messages to internal hosts, then the RST reply from buddy can be inspected.
The LOW TTL Value = i - 1.
http://en.wikipedia.org/wiki/TCP_hole_punching
http://nutss.gforge.cis.cornell.edu/stunt.php
http://en.wikipedia.org/wiki/STUN
|
|
|
|
|
|
|
Pretty sure it can be more complicated than the other replies suggest.
Presuming a physical connection between two computers exists then the control of that channel will certainly fall under one or more routers and possibly one or more firewalls.
If any one of those precludes communication then the linkage will fail.
So one must know that all of them exist and be prepared to configure all of them.
|
|
|
|
|
I've created a custom control, using the low level win32 api, which displays an animation. Using a thread I render a frame, or rather update the parts need it, and call InvalidateRect passing the area that was changed. In the main thread I handle WM_PAINT with the BeginPaint EndPaint pair AND use the paintstruct's rect to repaint only the area required.
The rendering is backed by a TimerQueue, an event and a thread that waits on the event.
I couldn't work out why my CPU usage was hovering around 80%. Each frame involves a lot of alpha blending hence the need to only update the changed parts.
After 2 days I've narrowed the problem to BeginPaint. MSDN states, and this is GDI 101, when handling a WM_PAINT message BeginPaint and EndPaint should be called to validate the invalid rect, otherwise windows will continue to post the message.
Well, it's just not happening. The window has not been validated and my code has been rendering the full client area (lot's of work) on each call. If I add a ValidateRect in my handler the problem goes away and CPU down to 0-1%.
My question is why? Is this a bug or am I missing something?
Waldermort
|
|
|
|
|
WalderMort wrote: a ValidateRect in my handler the problem goes away
I think that's the correct way.
Don't know if it's a bug or not.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
|
Hmpf! I stand corrected. I was going off of faint memory. Like I said, "I thought".
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
Well, if the documentation says you have to do it and the experimentation shows that you have to do it, seems like it's working as designed. Not a bug, the rules.
|
|
|
|
|
Chuck O'Toole wrote: Well, if the documentation says you have to do it and the experimentation shows that you have to do it, seems like it's working as designed. Not a bug, the rules.
But the documentation doesn't say that, infact it says that since I am calling BeginPaint there is no need to call ValidateRect. http://msdn.microsoft.com/en-us/library/dd145194(VS.85).aspx[^]
Waldermort
|
|
|
|
|
Well, you don't show how you do the re-drawing of the area in your WM_PAINT processing. Where did you place the call to ValidateRect()? Immediately on entry or just before the EndPaint()? Is it possible that you are calling some other functions that cause the invalidate to happen (explicitly or implicitly) before the call to ValidateRect()?
|
|
|
|
|
It's too much code to simply paste here. You'll have to take my word for it that there is no way for the rect to be invalidated other than when I explicitly call for it.
My code works like this. bitmap A is updated from a thread. Thread calls InvalidateRect when done updating a frame. bitmap B contains the window background and doesn't change. bitmap C is a double buffer. When WM_PAINT arrives, call BeginPaint, alpha blend bitmap A with B onto C and BitBlt bitmap C to the screen. When done call EndPaint.
Like I said this is GDI 101, and I have never had a problem like this with previous versions of windows or Visual Studio.
As it stands now, calling ValidateRect from anywhere in the WM_PAINT handler solves the problem. I currently have it after the call to EndPaint. Without this call, WM_PAINT is being sent from window creation and always with the full client area. Even though at that time my drawing routines have not yet begun. And yes I do call Begin End on EVERY WM_PAINT.
On another note, passing the message onto DefWindowProc, after those two calls, also results in undesired behaviour. rectangles are being validated but not those that are in the paint struct.
I'm really beginning to think this is a bug.
Waldermort
|
|
|
|
|
Of course, if this were a newly introduced bug in Windows (not saying that it isn't) then we'd expect to see a lot more programs going into high cpu usage processing WM_PAINT messages.
Theory goes that the EndPaint() call will take care of the ValidateRect() on the .rcPaint member of the PAINTSTRUCT you received in BeginPaint(). Is that the same thing you are using in your manual ValidateRect() call? Is there a possibility that it is being clobbered during your paint processing? If .rcPaint changed between Begin and End that would explain what you see. You say you use that member to do your re-drawing, read-only?
|
|
|
|
|
Chuck O'Toole wrote: Theory goes that the EndPaint() call will take care of the ValidateRect() on the .rcPaint member of the PAINTSTRUCT you received in BeginPaint(). Is that the same thing you are using in your manual ValidateRect() call? Is there a possibility that it is being clobbered during your paint processing? If .rcPaint changed between Begin and End that would explain what you see. You say you use that member to do your re-drawing, read-only?
BeginPaint() actually.
Like you said though, if it were a bug... which makes me think there must be a problem in my code somewhere.
Anyway, found it! Deep in there was a legacy debug routine to update the entire screen. Now to find out who made it and then...
Thanks for the suggestions though.
Waldermort
|
|
|
|
|
Hi Friends,
My software server listens on a particular port using dedicated "listener thread" . We accept the connections from client and serve this request on different threads.
Under high input requests from client (12000 approx/sec), the "listener thread" dies. Any suggestion for this kind of problem?
Currently it looks to me that the select or accept call is possibly the reason behind. Should we use pselect or simialr to this?
~ Vikram S
|
|
|
|
|
vikrams wrote: the "listener thread" dies.
Please clarify "dies." Is there an error?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
