|
Thanks, James
but the problems is the when I simulate a dropped connection by killing the process of running our client application
GetQueuedCompletionStatus(...) reruns 0, and GetLastError() return 0 too.
It's pretty confusing because I read the msdn docs and
ERROR_SUCCESS - 0 The operation completed successfully.
If the function /GetQueuedCompletionStatus/ dequeues a completion packet for a successful I/O operation from the completion port, the return value is nonzero.
So I still do not know what to do when GetQueuedCompletionStatus 1 with 0 bytes read....
Thanks,
Yani
|
|
|
|
|
Sorry - no further ideas... Except that if you never send an empty packet over, you might be able to use an read bytes value of zero to indicate closure of the socket...
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
thanks
I had same problem 
|
|
|
|
|
I'm having a few problems while trying to correctly display and position the controls on my dialog.
This is a simple Win32 project, of which there are very few examples and tutorials. Why is MFC forced upon us?
Anyway. I am trapping the WM_SIZE and calling the following function:
void ResizeWindow(HWND hwnd, RECT& rMain)
{
RECT rNewMain;
HWND hList,hListBorder,hComment,hCommentBorder;
RECT rList,rListBorder,rComment,rCommentBorder;
GetWindowRect(hwnd,&rNewMain);
static int minW = rMain.right - rMain.left;
static int minH = rMain.bottom - rMain.top;
int width = rNewMain.right - rNewMain.left;
int height = rNewMain.bottom - rNewMain.top;
bool resize = false;
if (width < minW) {
resize = true;
width = minW;
}
if (height < minH) {
resize = true;
height = minH;
}
if (resize) {
SetWindowPos(hwnd,NULL,0,0,width,height,SWP_NOZORDER | SWP_NOMOVE);
return;
}
int changeW = width - (rMain.right-rMain.left);
int changeH = height - (rMain.bottom-rMain.top);
hList = GetDlgItem(hwnd,IDC_LIST);
GetWindowRect(hList,&rList);
hListBorder = GetDlgItem(hwnd,IDC_LIST_BORDER);
GetWindowRect(hListBorder,&rListBorder);
hComment = GetDlgItem(hwnd,IDC_COMMENT);
GetWindowRect(hComment,&rComment);
hCommentBorder = GetDlgItem(hwnd,IDC_COMMENT_BORDER);
GetWindowRect(hCommentBorder,&rCommentBorder);
SetWindowPos(hListBorder,NULL,
0,
0,
(rListBorder.right - rListBorder.left) + changeW,
(rListBorder.bottom - rListBorder.top) + changeH,
SWP_NOZORDER | SWP_NOMOVE);
SetWindowPos(hList,NULL,
0,
0,
(rList.right - rList.left) + changeW,
(rList.bottom - rList.top) + changeH,
SWP_NOZORDER | SWP_NOMOVE);
SetWindowPos(hCommentBorder,NULL,
rCommentBorder.left,
rCommentBorder.top + changeH,
(rCommentBorder.right - rCommentBorder.left) + changeW,
(rCommentBorder.bottom - rCommentBorder.top),
SWP_NOZORDER);
SetWindowPos(hComment,NULL,
rComment.left,
rComment.top,
(rComment.right - rComment.left) + changeW,
(rComment.bottom - rComment.top),
SWP_NOZORDER);
rMain.bottom += changeH;
rMain.right += changeW;
}
The resizing works without a hitch, but for the 'Comment' controls, I want them to remain at the bottom of the window and only for their width to change. Problem is, those controls simply disappear when resizing the window. I have also tried using the MoveWindow() function with exactly the same results. Any ideas?
Also, when clicking the 'Maximize' button, the window maximizes but the controls remain unaffected. I thought WM_SIZE was supposed to catch it with SIZE_MAXIMIZED in the wParam?
And another little problem is the flickering. I have noticed that WM_SIZE is sent repeatedly while the window is being resized, but according to MSDN it's supposed to be sent after the window size has changed. Whats the deal?
|
|
|
|
|
waldermort wrote: Why is MFC forced upon us?
It's not. That's what the developers themselves have chosen to use, hence the count of MFC examples likely outnumbers the count of Win32 examples.
I have an MFC example of this here. It uses GetClientRect(), GetWindowRect(), ScreenToClient(), OffsetRect(), and MoveWindow().
waldermort wrote: GetWindowRect(hwnd,&rNewMain); // store the origional size // prevent resizing less than this
Call GetClientRect() in response to the WM_INITDIALOG message.
waldermort wrote: // set the smallest size bool resize = false; if (width < minW) { resize = true; width = minW; } if (height < minH) { resize = true; height = minH; } if (resize) { SetWindowPos(hwnd,NULL,0,0,width,height,SWP_NOZORDER | SWP_NOMOVE); return; }
You'll also want to handle the WM_GETMINMAXINFO message. Here is where you'd take care of the dialog's minimum size.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Thanks for pointing out the WM_GETMINMAXINFO, I have changed my code accordingly. Regarding my dissapearing windows, I am lost and confused. I changed the code to do some debugging:
SetWindowPos(hComment,NULL,
0,
0,
(rComment.right - rComment.left) + changeW,
(rComment.bottom - rComment.top),
SWP_NOZORDER | SWP_NOOWNERZORDER);
Setting a breakpoint on the above gives some strange results.
On the first break:
rComment.top == 540;
rComment.left == 113;
The above function should should now set them to 0 should it not? But on the following breaks:
rComment.top == 146;
rComment.left == 87;
I cannot understand why this is happening? This is the only part of the program that could possibly change these values, yet it is not being done as I want it to.
|
|
|
|
|
I think you are mixing up two issues.
1. The WM_SIZE is called repeatedly. Eahc time you get a window rectangle, it is not its ORIGINAL size you obtain but its most RECENT size. This is the same for the controls.
2. Your calculations must be based upon some ORIGINAL rectangle, which you can store somewhere, or abolute 'relative' calculations with resonable adjustments, like 'this contol is always from top to halfway down window', or 'this control is always 10 pixels high starting at bottom of window but always as wide as window'.
A quick glance at your code seems to use CURRENT control locations with some adjustments, so over time, they will 'float' to incorrect positions.
When hand-coding dynamic control layout, I usually favor using a relative position type algorithm to determine the location of each control. Some may be relative to each other, some may be relative to the window's new size.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
Well I figured out the problem, but I haven't found the solution yet. But for anybody else having the same problem:
GetClientRect()
gets the client rectangle (0,0,width-border,height-border) which is your dialog window
GetWindowRect() // passing hwnd of dialog
gets the position and size of the dialog window relative to the screen (x-pos,y-pos,width,height);
GetWindowRect() // passing hwnd of control
gets the pos and size of control, relative to the screen and not the dialog!
SetWindowPos()
expects co-ordinates relative to the client area.
My confusing value of 87 in tha above code was coming from the x-pos of the dialog window (83) plus the width of the dialog border (4). In the world of MFC there is a function ScreenToClient(which will convert the rect), but in Win32 it doesn't quite work the same. You would have to convert your rects using some other method.
But here is the best solution: http://www.codeproject.com/dialog/dlgresizearticle.asp[^] This simple class has proved invaluable, I'm sure I will be using it in most of my future projects. Thanks go to the author 
|
|
|
|
|
I would suppose in Win32 code you would do the following 
void CWnd::ScreenToClient(LPRECT lpRect) const<br />
{<br />
ASSERT(::IsWindow(m_hWnd));<br />
::ScreenToClient(m_hWnd, (LPPOINT)lpRect);<br />
::ScreenToClient(m_hWnd, ((LPPOINT)lpRect)+1);<br />
if (GetExStyle() & WS_EX_LAYOUTRTL)<br />
CRect::SwapLeftRight(lpRect);<br />
}
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
waldermort wrote: In the world of MFC there is a function ScreenToClient(which will convert the rect), but in Win32 it doesn't quite work the same.
Right. CWnd::ScreenToClient() makes two calls to ::ScreenToClient(). This is what that article is doing, too. That appears to be the biggest difference from how the one I referenced works (aside from it being MFC).
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
LPTSTR ch1;
LPSTR ch2
LPTSTR A(LPTSTR p);
if project Character is ASNI, not wrong,
but if project Character is UNICODE, wrong, how to fix?
and what about if MBCS Character ?
|
|
|
|
|
|
|
I need some libs - code in order to convert a jpg image into a 2d matrix for my medical software. if anyone knows something or have a link to download the code please help me. Thanks for all
SPik
|
|
|
|
|
|
another nice library is cximage[^] which can not only read jpg but many other common images files as well.
-Saurabh
|
|
|
|
|
thanks for all. you save my life
SPik
|
|
|
|
|
|
i'm new to this platform.am a student.need to create a dialog based library system to search for a book,add,delete,and display all from adatabase without creating a dsn.that's the last point i'm stuck on plz help
|
|
|
|
|
RAVISHBHAMBORE wrote: ...without creating a dsn.
There is an example here.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Hi,
had raised a querry for this yesterday, though dint ne good ideas, so thought would share some info I found after trying out all possible things...
To create a dynamicly increasing array of objects, that is the arraysize should increase dynamically. You can follow the below steps in .NET environ
1. Create an arraylist eg
ArrayList arrayObj = new ArrayList();
2. Add the objects in arrayObj
arrayObj.Add( obj1, obj2.... );
3. Copy this arraylist to an object array of the specific class as under
ClassA[] obj1 = new ClassA[arrayObj.Count];
arrayObj.CopyTo( obj1, 0 );
Now obj1 is an array of objects of type ClassA !
Cheers!
|
|
|
|
|
damn !!!
you never said you were working for .NET ! 
simply because you asked this on Visual C++ forum, you got C++ answers.
if you wanted MC++ (Managed C++) code, then you should have asked this in the C++/CLI forum[^], which is dedicated to the new Managed C++ Visual C++ compiler mode...
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.24][3.0 soon...]
|
|
|
|
|
toxcct wrote: you never said you were working for .NET !
Geez, was so used to this forum! was the first time was workin on .NET! dint think of checking the CLI forum...and landed up in "apna" VC++ forum!
But hey look at the bright side, all got to know some .NET info as well eh!
If my query caused some brainknocking...sorry for that!
though this forum has always helped me!!!
Thanx!
|
|
|
|
|
I'm not seeing the correlation between the question and the answer.  The code snippet that you've provided does not look like "a dynamicly increasing array of objects." It looks like one object array being copied to another. Could you not have just used std::array for this? It allows for dynamically growing/shrinking of the array.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: I'm not seeing the correlation between the question and the answer
actually, the question was there[^] (asked yesterday), and shown off his solution there...
and visibly, he wanted to use .net framework, which he never specified...
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.24][3.0 soon...]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
what ???? 
