|
AFAIK, you can't, when receiving a void* you are just receiving a memory address; nothing about the structure of the memory at that point.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Hamed Mosavi wrote: I receive the pointer as (void*), and need to place it's data in to 'a part of memory'with the same size as the structure!! then use each data separately!
what about casting that Void pointer to the Structure.. i.e. something like this :-
void read(void* st)
{
x *objX=(x*)st;
}
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Hi,
Cast to what?!
I don't know any thing of the pointer I get! Even if I know the name, both the size and name of the data elements of the structure are unknown.
Thank you anyway, and excuse me for replying so late.
//This is not a signature
while (I'm_alive) {
printf("I Love Programming");
}
|
|
|
|
|
Hello All,
Pls help me.
How to use event NM_RETURN in the CListCtrl It's not response.
Thank you
|
|
|
|
|
The NM_RETURN notificaton is sent in the form of a WM_NOTIFY message.
"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
|
|
|
|
|
|
Not sure I understand you exactly, but if you are having trouble getting that notification mesage, remember that NM_* notifications are sent via WM_NOTIFY (Win32's WM_COMMAND notification message), so you need to be catching WM_NOTIFY messages being sent from the control.
In MFC you can use the ON_NOTIFY message map macro - look it up in MSDN for examples.
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!)
|
|
|
|
|
Hi guys,
We are using IO Completion Ports in a server application. But I'm not sure exactly when a socket is closed. This is what I mean:
BOOL GetQueuedCompletionStatus(
HANDLE CompletionPort,
LPDWORD lpNumberOfBytes,
PULONG_PTR lpCompletionKey,
LPOVERLAPPED* lpOverlapped,
DWORD dwMilliseconds
);
So according to the MSDN, a socket is closed when
lpOverlapped is not NULL, lpNumberOfBytes == 0 and the value returned by the function GetQueuedCompletionStatus is ERROR_SUCCESS /0/.
But I have cases when GetQueuedCompletionStatus returns 1, lpOverlapped and lpNumberOfBytes is 0 -- does it mean the socket is closed on the other side? Because if I assume that, the other side is notifying that the server side closed the connection.
Someone with any experience with that? Please, help!
Does someone know about any problems with hyper-threading and IOCP?
Cause when I'm running the server application on a dual processor machine with hyper-threading the number of dropped connections increases.
Thanks,
Yani
|
|
|
|
|
Well, I have only used IOCPs themselves, and not associating them directly with another HANDLE-based object, so take what I write at the bottom with a grain of salt... However, about HT processors, one of the things that many people do not understand about HT processors is that they are not the same as a real multiple-CPU system or a multi-core processor.
HTs share an execution engine, so technically, they will compete with each other for an on-die resource (IIRC, they can decode and retire instructions at the same time, but they cannot dispatch them). This contention may be causing unexpected things to happen with your code. (You can find HT documentation that discusses the architecture and differences on Intel's web site.)
Also, note that the documentation you have for GetQueuedCompletionStatus(...) may be incorrect - older docs mentioned that in the case of SOCKET closure, the function returns ERROR_SUCCESS, but the function returns a BOOL value, not a DWORD. I think that it returns TRUE, sets the variable pointed to by lpNumberOfBytes to zero, and GetLastError() will return ERROR_SUCCESS.
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, 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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
what ???? 
