|
@TV Mogul, thanks for the explanation. But I think my knowledge doesn't let me to understand it completely.
In your answer, port numbers are used for clients.
@Andrew Brock thank you too.
We all know that, IP address is client specific. Every client has a distinct IP address.
- If I am right, port number is application specific. If one application grabs a port no other application can use it.
So, for example,that means one computer mustn't have 2 or more web server that listening port 80. Right?
- But also a lot of clients can connect same port. But sometimes we need to serve them from different ports, ( I think TV Mogul's definition is about that)
Which conditions should i make a decision that I need a new socket?
|
|
|
|
|
sawerr wrote: If one application grabs a port no other application can use it.
Application specific would imply that each application could have its own set of ports. I think you meant to say "System Specific".
sawerr wrote: So, for example,that means one computer mustn't have 2 or more web server that listening port 80. Right?
That is correct. This is called System Specific . 1 per system.
sawerr wrote: But also a lot of clients can connect same port.
Yes, me and you can both connect to www.google.com on port 80 at the same time. (ignore the fact that we would almost certainly get different servers altogether).
When a server is listening, it has the option of setting the maximum number of sessions.
When you look at some code for starting a server you have something like this:
SOCKET sConnection = socket(AF_UNSPEC, SOCK_STREAM, IPPROTO_TCP);
bind(sConnection, pAddress->ai_addr, pAddress->ai_addrlen);
listen(sConnection, SOMAXCONN);
for (;;) {
SOCKADDR saClient;
DWORD nClientAddrLen = sizeof(saClient);
SOCKET sClient = accept(sConnection, &saClient, &nClientAddrLen);
CreateThread();
}
|
|
|
|
|
Andrew Brock gave you a textbook answer. What I am trying to explain is that teh textbooks are WRONG and all the design model examples are wrong in that they only deal with a single client connecting or multiple clients where the data is the same for each client and only a little data is passed.
The simple answer is this: The ip address can be same BUT the port number must change for each client that connects if you want the system to be practical.
This means that you create a console app with a minimum amount of memory as the server and launch a new instance of this for each client that connects so that each client is connecting on a different port number.
For example, I wrote a camera wall recently for the U.S. government and their specs stated that you may NOT use threads--that you must create a new instance of the server for each client connection. The reason for this is so that if one client goes down it will not take the whole system down. Each client uses the same ip address but has a unique port number.
Andrew Brock's answer is a textbook answer which doesn't apply to teh real world. Get real Anrew!
http://www.KabbalahCode.com
|
|
|
|
|
hi everybody
I'm working in Fedora 13 using C
to bind tcl/tk GUI in C program you use this two headers tcl.h and tk.h
when you use Tcl_EvalFile you use after it Tk_MainLoop
but Tk_MainLoop make program stop until it return from the call
so I but it in another thread
but I couldn't to modify the window using Tcl_Eval
what I should do ??
thanx alot
|
|
|
|
|
LRESULT CALLBACK DlgProc(HWND hwnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
case WM_INITDIALOG:
return FALSE;
case WM_COMMAND:
return FALSE;
case WM_CLOSE:
return FALSE;
}
LRESULT CALLBACK DlgProc(HWND hwnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
case WM_INITDIALOG:
return TRUE;
case WM_COMMAND:
return TRUE;
case WM_CLOSE:
return TRUE;
}
LRESULT CALLBACK DlgProc(HWND hwnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
case WM_INITDIALOG:
break;
case WM_COMMAND:
break;
case WM_CLOSE:
break;
}
LRESULT CALLBACK DlgProc(HWND hwnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
case WM_INITDIALOG:
return 0;
case WM_COMMAND:
return 0;
case WM_CLOSE:
return 0;
}
out of these four examples, which one is correct and more accurate, and why.
Some Day I Will Prove MySelf :: GOLD
modified on Sunday, March 6, 2011 12:19 PM
|
|
|
|
|
None of them are correct.
The message determines what you must do.
At the bottom of the DlgProc function there would be a call to DefWndProc() or the original window procedure.
Read the MSDN pages for what the return should be.
WM_INITDIALOG[^]: "The dialog box procedure should return TRUE to direct the system to set the keyboard focus to the control specified by wParam. Otherwise, it should return FALSE to prevent the system from setting the default keyboard focus." Generally you would break and let the default procedure take care of this, but you can return either TRUE or FALSE .
WM_COMMAND[^]: "If an application processes this message, it should return zero." implies that you should break the switch and call the original procedure if you don't handle it.
WM_CLOSE[^]: "If an application processes this message, it should return zero."
LRESULT CALLBACK DlgProc(HWND hwnd, UINT Msg, WPARAM wParam, LPARAM lParam) {
switch (Msg) {
case WM_INITDIALOG:
break;
case WM_COMMAND:
switch (LOWORD(wParam)) {
case IDC_MYBUTTON:
return 0;
}
break;
case WM_CLOSE:
return 0;
}
return pOriginalProcedure(hwnd, Msg, wParam, lParam);
}
|
|
|
|
|
case WM_COMMAND:
{
if(LOWORD(wParam)==frmMainOK && HIWORD(wParam) == BN_CLICKED)
{
MessageBox(NULL,"OK Pressed","Demo",MB_OK);
}
return TRUE;
}
case WM_COMMAND:
{
switch(wParam)
{
case frmMainOK:
MessageBox(NULL,"OK Pressed","Demo",MB_OK);
break;
}
break;
}
Which is the correct and most appropriate way between the two examples given above, and why?
Some Day I Will Prove MySelf :: GOLD
modified on Saturday, March 5, 2011 10:37 PM
|
|
|
|
|
The second bit of code doesn't check the notification code, so if the control sends other codes besides BN_CLICKED, you'll treat those notifications as if they were BN_CLICKED. For buttons, this isn't a problem, but other controls like the edit box send other types of notifications.
--Mike--
Dunder-Mifflin, this is Pam.
|
|
|
|
|
The second one is logically wrong and (by accident) working just for buttons notifying BN_CLICKED .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
How can i move gdi+ objects drawn on window with a mouse? Such objects like: elipse, rectangle. For example, i have an elipse, created with DrawEllipse() , then it filled with GraphicsPath which contains some background color. So for example i have painted a "blue ball" on main application window. Now i am trying to figure out, how can i move this ball within window area with a mouse. I can think of such scenario:
1. On WM_LBUTTONDOWN i am checking if mouse pointer is inside the ball and setting flag to true, if it is
2. And now on WM_MOUSEMOVE , if flag is sat to true, what should i do next? Should i for example, erase this ball and paint it in new position regarding mouse pointer? Or there is a method somewhere to, like, "grab" this ball and literally move it to new position?
I'm just learning GDI+ so this question may look lame, however...
Thanks
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
1. Store your object in vector form, so you can repaint them whenever needed.
2. On left button down, you do hit-testing to figure out which object is selected if any.
3. On mouse move, adjust the coordinates in your vector data, and repaint the screen using double buffering to avoid flicker.
|
|
|
|
|
Storing things in vector sounds interesting - never thought about such approach, thanks
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
I was talking about a vector representation of the graphics, not about storing them in a vector type container, although that could also perform well.
Just to avoid misinterpretations.
|
|
|
|
|
Oh, i see, ok. Yeah, some misunderstanding occurred. But, my misinterpretation of a part of your post gave me some new ideas!
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
The general solution is to just invalidate the window[^] or better yet, the old ball rectangle and the new ball rectangle and then draw it again in the WM_PAINT which is called automatically when you invalidate the area.
1 minor issue with this is that it will do what is called "flickering" where it flashes.
To fix this mute the WM_ERASEBKGND message and use a memory DC. Search codeproject or google for "memory DC" or "flicker free drawing" to see how this is done in code.
|
|
|
|
|
Thanks guys
Looks like invalidating / redrawing window is the only way. This "ball" is actually a part of custom control i am writing (has its own window) - it is already double buffered.
case WM_PAINT:
{
Gdiplus::Graphics graphics(hdc);
Gdiplus::Bitmap *bmp = new Gdiplus::Bitmap(CtrlRect.right, CtrlRect.bottom);
Gdiplus::Graphics *temp = Gdiplus::Graphics::FromImage(bmp);
temp->SetSmoothingMode(Gdiplus::SmoothingMode::SmoothingModeAntiAlias);
Gdiplus::CachedBitmap *cbmp = new Gdiplus::CachedBitmap(bmp, &graphics);
delete bmp;
delete temp;
graphics.DrawCachedBitmap(cbmp, 0, 0);
}
Just thought it could be done a way smoother - without redrawing. Anyway, thanks
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
Well, I know that scrollbars work by moving the screen data, rather than redrawing, in things like ListBox's and web browser controls.
Presumably this behaviour could be implemented into your solution too, but for something so simple, it would not be worth the complexity that I imagine it might take.
|
|
|
|
|
Good point.
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
I was getting a heap corruption error merely doing a new and delete (next to one another) of a class within a dll. After some troubleshooting, I found that I could avoid the error by changing a bool to a BOOL in the base class of the guilty class, which means that specific boolean variable size was being evaluated incorrectly (there's another bool that works fine).
Anyone have any clue as to what would cause this behavior?
Here's the original question posting (see posting for details and solution):
http://www.codeproject.com/Questions/164517/Heap-corruption-detected-in-class-after-delete-but.aspx[^]
modified on Saturday, March 5, 2011 5:41 PM
|
|
|
|
|
I find it hard to believe that the size was incorrectly determined. What you could do is try to change the order of the class' instance variables, since it's more likely it has to do with member alignment, which is influenced by the size difference of bool and BOOL . The rearrangement of the members will not be a solution to your problem, but you might get new ideas for the reason of the problem. If you're lucky the error will turn up in a different way, which will add to the clues.
From what you describe, it sounds very likely that the constructor of the class is the naughty one. Check all non-trivial constructors of your instance members, and possible base class constructor code. Who knows, a 'clever' programmer might have made assumptions about the boolean flag
*(BOOL*)&m_bool = FALSE;
Well, just a few ideas...
|
|
|
|
|
I did a global solution search for the member bool and couldn't find anyone using it improperly, and yep, already tried changing the order. I also commented out the constructor and replaced it with (to make sure the constructor wasn't the one doing it):
class CBaseClass
{
public:
CBaseClass(){}
virtual ~CBaseClass(){}
};
class CClass : public CBaseClass
{
public:
CClass(){}
virtual ~CClass(){}
};
|
|
|
|
|
Is there any #pragma pack(#) or __declspec(align(#)) directive somewhere (may affect it) before your class?
If the base class' implementation is in pre-compiled form or it is an MFC class while using MFC in shared libs, default packing alingment is 4 (for x86). AS you may know, BOOL is defined as type 'int' which is 4 bytes in size while bool is 1 byte.
|
|
|
|
|
Good suggestion, I'll look at directives (and yes I know about size difference)...
|
|
|
|
|
You were right on! A #pragma pack(show) revealed the problem. Someone had a #pragma pack(1) in a header file. I have to look over the code a little closer but the header should probably have a #pragma pack(push,1) and corresponding #pragma pack(pop) .
If you want to place this as a solution in the question (see link above) in the other page I'll accept it, give you some credit. THANKS!
|
|
|
|
|
Please. I'm glad the issue is resolved without posting your class code here.
|
|
|
|
|