I am trying with tcp sockets. I have one confusion that suppose I open a port (localhost:9200) and if i use that port for reading and writing both then how the same port can be used for that. Will the data collide if I am trying to write on a port and somebody is sending data on that port?
"How" means I want to know how data is handled when sender uses same port for sending and receiving data. I think you have explained it in your second part of the message. So that means when application uses same port for reading and writing at that time data goes from different layers and hence it does not collide.
when communication is established between a sender and receiver over TCP/IP, a unique socket handle is created to identify the communication channel. When you use that socket handle all sending and receiving is unique between you and the machine on the other side.
A socket handle is created (as far as I remember) as a combination of the callers IP address and their outgoing TCP/IP Port, and the receivers IP address and inbound Port. The TCP/IP stack ensures that outgoing addresses are not automatically reused (although you can programmatically force them to be reused, but that gets complicated)
I am very new to C++/MFC, I have a background of C# and I'm having to get to grips with the basics of C++/MFC to work on an older piece of software.
I am trying to create an application that will display a list of customers taken from an Access database, with dialogs to add and edit customers.
So, step 1, I need to get the list of customers.
So far I have done the following:
1 - Using the app wizard (I'm working with VS 2010), I have created an SDI application with document/view and database support, and derived the view from CListView.
2 - During the wizard I have connected to my database and selected a table.
3 - When the solution is generated, member variables are correctly created for the fields in the table, and code is generated for the DoFieldExchange method in the recordset.
4 - I added code to the OnInitialUpdate method of the view to add columns to the list view control.
Now I'm stuck - I don't know how to connect my recordset to this so that I get a list of customers. Currently all I get is an empty list control with just column headers.
Thanks for your post. I have read that article (a couple of times). Unfortunately it does not cover what I am trying to acheive - it uses a dialog and databinds controls on that. I'm using a view derived from CListView. Whilst I can get at the list view control using GetListCtrl(), I can't bind my data in the same way it seems.
I can't actually find any examples of binding a recordset to a CListView view, which is very frustrating. I can't believe it's THAT difficult and I'm sure I'm missing something quite simple here
Years ago I wrote a datamapper in 16 bit C which is still in use. Later I added a debugger that is based on the same code with a user interface in front. When we changed to windows interfaces, I rewrote the interface in c++ (Visual Studio 6) still mixing it with the original C mapping code. Then I migrated to Studio 2005. Works fine. I however recently moved to studio 2010. Now, the system crashes on every "malloc" statement in my C code. It throws an exception at the HEAP_ALLOC (Can't really follow anymore, the last part is in assembly for which there is no source studio says).
Anyone any idea if there has been a change in memory alignment? Is there a compiler option that I should use?? Please help you wise men and women out there!!!!
The program is a Dialog based program that calls the datamapper's main loop (replaced the original "main" in the production datamapper by a routine called "StartMapping" in case of the debugger) from the "OnInitDialog". The dialog is c++, the datamapper is C and it does call some Studio6 built libraries that hold stuff like a standard error handling, license check etc. That has all been passed when at some point in the mapping, I use a malloc (or - after having removed the malloc for a test - a _fullpath with a NULL pointer for the target)
Point is that it all worked fine when compiled in Studio2005, and it no longer works now that I have it compiled by Studio2010. It crashes when calling HeapAlloc in ntdll.dll, which tends me to believe that something changed in memory alignment.
I am trying to alternate an SDI application which is used to operate a spectral camera as part of my diploma thesis. Since it's not my code entirely I tried to simulate a bit of the functionality I want add in a simpler example. So I created an MFC SDI application using Creation Wizard of Visual Studio 2005 (it's a bit old I know but what can you do...). The code I added implements a new class derived from CDialog which creates an invisible message-only, and posts/sends two user-defined messages. These two messages are supposed to be handled by an object of my class CInvisibleWnd. Everything seems to work fine (no errors and no warnings during building) and all my objects are successfully created but the code inside the event handlers is not reached! Do you have any suggestions?
The CDialogMsg object is created by C"MyProjectName"Doc object...
I could not incorporate message-only CWnd to C"MyProjectName"Doc due to multiple inheritance which is, as I found out, very difficult to implement. The best source I found for message-only CWnd in MFC is here: How to make a Message Only Window
Thank you very much!
Ody -- Always look on the bright side of life --
Each one can do pretty much the same thing. In your posted code, you're using the MFC version, but since you're calling the method internal to CDialogMsg, you're posting the message to that specific CDialogMsg object (you have him sending that message to himself), not to any CInvisibleWnd object.
How can you specify to send it elsewhere?
//Use the target pointer to use the MFC SendMessage()
//Or you can use the WinAPI and specify the handle to your target
SendMessage( pWnd->GetSafeHwnd(), ...);
On a related note, you probably shouldn't name your messages with the "WM_" preffix, as that's there to indicate its an internal windows framework message.