Than you very much, after some fiddling on google regarding these functions I managed to reroute the message to my custom procedure and now life is getting better.
Thanks to steve as well for pointing in the right direction
I am starting new development of an audio analysis application - basically real time (or as close to real time as possible) FFT and filtering of signal from noise.
I have been looking at Windows multimedia and would like to know if DirectSound would be a better choise.
I am little uncomfortable with Windows MM usage of "buffers" and actually read an article here recomending tripple buffering.
Sounds unnecessary complex.
Any constructive opinions are as always appreciated.
References to "google it " and off the subject commetaries are not welcome.
Thanks for your time.
While messing around with Windows programming I found something odd.
When I have a window at (0,0), and the width is 1680, the height is 1050, and GetSystem metrics says that is the height and width of the screen; however the window does not fill up the entire screen. (e.g. there are exactly three pixels it does not cover on the right)
Any thoughts was to what might be happening?
Okay, two things to add:
- Since I had altered the message processing so that it would be as if the non-client area did not exist, I was using GetClientRect to find the values for position and size. It sets left and top to zero, so the position could have been wrong.
- I had shifted the window up and to the left to place the 0,0 of the client area at 0,0 on the screen. Further testing shows that the calculations I had preformed were correct for a window with no style so this should not have been a problem.
Therefore it would seem I have somehow managed to prevent the non-client area from being created, as all non-child windows normally have a border of some type and a caption even if those things are not specified in the style. Will confirm this later with a few more tests.
Apperently there is no non-client area if you eat the WM_NCCALCSIZE message, so my adjustments to the windows position to account for the non-client area was unneeded. This fact is not in the documentation of the message . Would have saved a lot of trouble. So, my code was correct per the documentation of the Windows API, but it was something they forgot to mention that was the root of the problem (as I had expected, though I was looking in the wrong place).
The output is the expected value (my screen resolution), and the related output for the window size and position is what I expected as well (the as I passed to CreateWindowEx). However, since I can see that the window is smaller than the screen, it means one of the values is a lie.
x -= ::GetSystemMetrics(SM_CXFIXEDFRAME);
y -= ::GetSystemMetrics(SM_CYCAPTION)+::GetSystemMetrics(SM_CYFIXEDFRAME);
r.right = width;
r.bottom = height;
obj.handle = CreateWindowExA(WS_EX_TRANSPARENT|WS_EX_TOPMOST,"CONTEXT",title,0,x,y,width,height,0,0,::GetModuleHandle(0),0);
The WndProc associated with it is crafted to make it as though the non-client area does not exist; it is not drawn, it does not recieve input, hit tests return true only if the point is inside the client area, and WM_NCCALCSIZE returns WVR_VALIDRECTS|WVR_REDRAW (for now, I will do some custom checking later).
For getting the size and position, I use GetClientArea, as the client is effectivly the entire window. The window is filled with a rectangle of its width and height when redrawing. Looking it over it might be that I should use SM_CXBORDER insead of SM_CXFIXEDFRAME, but that would not account for all the missing space.
Despite your previous comment, the above does not use SM_CXSCREEN/SM_CYSCREEN, thus the final values you are using to create your window may not be the full screen size. I also cannot see the point of your call to AdjustWindowRect() in the above. Nor do you show what are the values of width and height. Also what are the initial values of x and y?
It is an inline function; x, y, width, and height are values passed to it.
In the case this thread refers to: x = 0, y = 0, width = GetSystemMetrics(SM_CXSCREEN), height = GetSystemMetrics(SM_CYSCREEN).
AdjustWindowRect causes the bottom and right member variables to be adjusted such that if you create a window using them, the height and width of the client area will be equal to the original values of those variables. This is simpler and less error prone than figuring it out myself.
Do to the nature of the redraw code as it stood at the time I was doing this, everywhere that was not drawn to would be filled with black. I know this because I am doing the drawing with OpenGL and when I had a matrix out of place (it was the default matrix, so only the upper right was being drawn). So that is not an issue.
I suspect this may have something to do with your values of x and y which look like they may be negative. As I said earlier using values of x=0, y=0, cx=SM_CXSCREEN, cy=SM_CYSCREEN the window will fill the monitor. The values you are using are different from this, thus your results are different.
Yes and no, I am doing this because I had once tried to create a fullscreen window and I found an upper limit on the size of a window. This was to see if I had found how to work around that, which I seem to have done. The question is about the possible cause of an oddity I noticed in the process.
Thanks for the links, I think they will be useful soon.
Some files are not 0kb in size, but appear to be corrupted and some files appear to have 0kb in size.
It's more file extension related.
I started thinking if it might be a Windows Firewall related problem, but if it connects I think everything is ok with the Windows Firewall. Or if Windows Firewall abrupt's connection pathway during recv, well need an opinion.
First without a protocol you don't know if the complete content data was transferred or the connection was interrupted. Second you do not have any error handling in the loop, recv() can return -1 in error cases. Third your receive buffer TCPrecv is used to insert data with ostream::operator<< but the text data is never null terminated (or otherwise indicated how long it is). Could that be a problem?
I have been tracing the problem all night, and I even started adding MessageBox functions to help me get to the roots of the problem. It seems the problem is in the wide-char to multi-byte conversion!?
After the conversion I used MessageBox to return the new string and it's all jebrish.