C / C++ / MFC

CaesarCZ17-Jul-02 10:05

CaesarCZ

17-Jul-02 10:05

Okay, so now I know how to change the drawing.... I don't presume there are chances it is possible to use the text as some kind of anchor, but... is it? I need it to react to a single click (not double) on the text (simply to make the application to handle a click to the icon itself (in icon view mode) handlin a click commonly and to handle the click on the text using some ie. pre-set function... thanks. (my only cue is the HOTTRACK capatibility, but that seems to be too "spread" so that a lot of bug would be involved (handling the mouse separately and checking for the hottrack and keydown and calculating where the item was clicked (btw. that may be important: I always know the size of the item... i can rely on that) thanks

KaЯl17-Jul-02 21:39

KaЯl

17-Jul-02 21:39

CaesarCZ wrote:
I don't presume there are chances it is possible to use the text as some kind of anchor, but... is it?

Yes, it is, but you will have to manage everything in your derived ListView. By catching the message WM_MOUSEMOVE you may know over which item your mouse cursor is, and react accordingly (for example by drawing the item text differently).
If you want to know if the user has clicked over your ListView, you may catch the notification from the embedded ListCtrl object of NM_CLICK...

Have a look to the articles section of this site (www.codeproject.com/listctrl/), you will find a lot of information here.

You know, it's Visual C++, not VB, you may do everything you want Smile | :)

HTH,

K.

We do not inherit the Earth from our ancestors. We borrow it from our children.

Antoine de Saint Exupéry (1900-1944)

CaesarCZ17-Jul-02 23:14

CaesarCZ

17-Jul-02 23:14

thanks... I'll have a look... so the main problem is to catch and handle the related messages. Btw. I have to (yeah, I have to, it wasn't my choice) do it under WinAPI. Anway, I took a quick view over the articles (all headlines, some articles) and there are 10 to 20 about changing colors, but none about handling input... how could I get the item's positions at least (just a keyword suffits) Smile | :)

I never programed under VB either Smile | :)

)) but I completly agree

Re: VC++ Application Design

KaЯl18-Jul-02 2:24

KaЯl

18-Jul-02 2:24

Using the MFC you could use the CListCtrl::GetItemRect method.

This method is defined as

BOOL CListCtrl::GetItemRect(int nItem, LPRECT lpRect, UINT nCode) const
{
ASSERT(::IsWindow(m_hWnd));
lpRect->left = nCode;
return (BOOL) ::SendMessage(m_hWnd, LVM_GETITEMRECT, (WPARAM)nItem,
(LPARAM)lpRect);
}

HTH,

K.

We do not inherit the Earth from our ancestors. We borrow it from our children.

Antoine de Saint Exupéry (1900-1944)

About MS excel

Old Gun17-Jul-02 3:54

Old Gun

17-Jul-02 3:54

Can you help me or give me a sample about to hide or disable Microsoft Excel's menu titles,toolsbars,statusbars in visual c++?

:confused

VC++ Application Design

Paul Ingles17-Jul-02 3:43

Paul Ingles

17-Jul-02 3:43

The application will be based around a data store, probably using MSDE/Access. This is instead of writing my own serialisation code, also provides me with a little flexibility when querying data out of it also.

There will be a main client app (probably written in VC++) as well as other add-ins for MS Office applications. Both of which need to communicate with the DB -- i.e. add-ins add to the DB, the VC++ client reads back from it, as well as adding data into it.

What's the best way of communicating with the data through a single channel, I'd rather not have the data access in both add-ins and client in case it changes at any point, requiring users to update too many things etc.

I've not touched COM with VC++ yet (far too scary from what I've seen) and wasn't sure whether this would be the best way to do it. Are there any suggestions about the best way of doing it?

I had considered writing it using .NET and C#/C++. Thus allowing me to use assemblies registered in the GAC for data access. I had thought about using C# to develop the Office add-ins and C++ for the main client.

I'd really appreciate people's thought on the matter. I'd be quite happy to try and develop it all in VC++ using MFC/ATL for the various parts, provided people can encourage me enough to put myself into so much mental fog Smile | :)

Thanks as always,
Paul

Brian Azzopardi17-Jul-02 3:57

Brian Azzopardi

17-Jul-02 3:57

The best way would be COM as it offers the most flexibility. You can access the object from VB, C++, Office macros, etc. Using COM any updates would be very easy - just push out the new object.

COM is not that hard, just get a good book and use the ATL. Goodluck Smile | :)

bibamus, edamus, cras moriemur

[eat, drink, for tomorrow we die]

Re: VC++ Application Design

Paul Ingles17-Jul-02 5:18

Paul Ingles

17-Jul-02 5:18

Ok, I'm willing to go with it Smile | :)

Suggestions as to a good ATL book then please. Seeing as I'm using ATL to produce the objects, do I need a great understanding of COM too (I've got the basics)? If so, recommendations for that too please.

Thanks again,
Paul

A very basic socket question

Dave_17-Jul-02 3:21

17-Jul-02 3:21

If I have two UDP sockets bound in the following manner:

1. INADDR_ANY, port number 0 (all ports?)
2. 10.3.2.1, port number 0 (all ports again)

A. Send a message using socket 2. The source port picked by Windows is 1350 (as an example).

B. Reply comes back to destination port 1350, IP = 10.3.2.1.

Where should this message be rcvd? If a thread is looping doing a rcvfrom on socket 1, it never sees this reply.

I never do a rcvfrom on socket 2, but I am guessing that I would see the reply if I did.

I'm wondering why the first socket cannot rcv this message? I am not an experienced sockets programmer at all, and I am hoping this is a simple issue.

Thanks,

David

Joaquín M López Muñoz17-Jul-02 3:29

Joaquín M López Muñoz

17-Jul-02 3:29

You have to select some predefined UDP port for this to work (some random number should do, as e.g. 27890), and bind both sockets to it before sending and receiving.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

includeh1017-Jul-02 3:39

includeh10

17-Jul-02 3:39

the port 0 is not all, but a default port selected by system.

client must know which port the server is on, otherwise u can't establish a socket connection.

includeh10

Dave_17-Jul-02 3:51

17-Jul-02 3:51

Thank you for the replies.

When my listening socket binds to IN_ADDRANY, and I pass port 0 to the bind call, doesn't that mean that I can rcv messages from any port number? This should be true, since this is the part that has been working for quite a while.

I realize that when I send a message, that the O/S will pick a source port, but when I do a rcvfrom, won't I be able to catch messages from any UDP port?

Sorry for the stupid questions, I can't seem to find any documentation on this type of a bind call.

Thanks again.

includeh1017-Jul-02 4:05

includeh10

17-Jul-02 4:05

think a socket is just a wire from one port of client to one port of server.

client can use port 0 (it may be 1350 actually) but client must know port used by server (server is listening on the port).

server is pastive and client is positive for first connection.

includeh10

Dave_17-Jul-02 4:11

17-Jul-02 4:11

Thanks again.

The software is not really a client/server application, although I guess you could think of it that way. The PC communicates with remote units by sending messages, and waiting for replies, but the PC also looks for any unsolicited messsages, and deals with them as well. So, in this regard the PC must act as the server, and client. This is why the listening socket needs to be able to read messages from unkown sources (and this has been working).

Anyway, I think I'll leave it as it is, and find another way to send and recv the new message (without breaking what has been working).

Thanks again for your replies.

Bubba214617-Jul-02 7:20

Bubba2146

17-Jul-02 7:20

Dave_ wrote:
When my listening socket binds to IN_ADDRANY, and I pass port 0 to the bind call, doesn't that mean that I can rcv messages from any port number? This should be true, since this is the part that has been working for quite a while.

No, that's not correct. When you recieve a message you must use, aka bind to, a port number known to both computers ahead of time. The reason is the client (or sending machine) must know which port to send its message to. The server can only listen on one port at a time. Like someone else pointed out, pick some high random number (below 65535 though) so you don't interfere with ports that have official uses ( those < 1024).

It's like a telephone number. When someone calls you they must know your phone number. You don't care what number they're calling from (that's where IN_ADDRANY comes from), but you'll always be to receive calls at your number.

Don't feel estranged.... socket programming is pretty goofy when you first start doing it.

Dave_17-Jul-02 7:37

17-Jul-02 7:37

Thanks for taking the time to look at this for me.

The application is not actually a server. There are two threads, one for sending, and one for receiving. When the PC sends a message, it will send using a constant source port number of 1594. The hardware responds to that port number, but the PC also needs to listen for unsolicited messages from other port numbersd. This part of the software has been working for years without problems.

I don't understand how I could possibly be recieving messages if when I pass in IN_ADDRANY, and 0 for the port number, and that results in a port number 1679 (for example) after the bind, since most messages (if not all) are coming in on port 1594?

Thanks again, sorry for the lack of knowledge.

Bubba214617-Jul-02 7:58

Bubba2146

17-Jul-02 7:58

Dave_ wrote:
The application is not actually a server. There are two threads, one for sending, and one for receiving.

This is fine and makes sense.

Dave_ wrote:
When the PC sends a message, it will send using a constant source port number of 1594.

This does not. The source port number applies when you are *sending* a message and should be determined by the operating system when you create the socket. This should not be a constant. The reason is you have no way of knowing (realistically) what ports are being used, so the OS takes care of it for you.

To help clarify:
1. Computer A wants to send a message to computer B
2. Computer B binds to a port (say 2000)
3. Computer A opens a socket connection to B and the OS assigns it a port of 47826 (essentially random from A's point of view) to use
4. Computer A sends a message to port 2000 on B

Now, from A's point of view, 2000 is the *destination* port, and 47826 is the *source* port.

Dave_ wrote:
I don't understand how I could possibly be recieving messages if when I pass in IN_ADDRANY, and 0 for the port number, and that results in a port number 1679 (for example) after the bind, since most messages (if not all) are coming in on port 1594?

See, if your messages are coming in on port 1594 then your server must be listening on the same port to receive them. That's why, for the receiving computer, it doesn't make sense to dynamically let the OS determine the port to bind to. You'll want to explicitly bind to port 1594, not 0.

Forgive me if I'm missing something, but I hope that clears up what I'm trying to say.

Dave_17-Jul-02 8:11

17-Jul-02 8:11

We (here at my company) have talked about the reasons why the original programmer bound the sending port to 1594. I realize this is not the normal thing to do, but given that it is currently done this way, does the rest of it make sense?

We have officially "reserved" UDP 1594 for our systems, so that's why we are not randomly picking one. So when we send, we know that the units are going to reply to port 1594, since we know that we sent on 1594.

The only thing left to sort out is how the listening socket works. If it is bound with IN_ADDRANY, and port 0, there is next to no chance that it is picking 1594 (at least not every single time). So, given that it does actually get messages from 1594, I'm assuming that doing a rcvfrom on this type of bind will let me recv. from unkown port numbers, and not just 1594, since I never used the number "1594" anyhwere near the listeners source code.

This is where I am confused. Most people use sockets the way you described, where the client sends to a known server port, and things interact from there, but this is done differently. In this case, the PC sends most of the initial messages, and waits for replies, but it also collects messages from other ports, such as 502 (Modbus protocol).

I hope I am not sounding like I know more than you do, because I'm sure this is not true, but when it comes to the operation of the existing code, I do know that it works as I described. There are probably better ways to do it, however.

When I wanted to add a third socket to send a broadcast message, things didn't work, so I started to look further into it. The broadcast would go out each NIC, but the source IP was always the primary NIC's IP. So the new socket was created and bound to each NIC's IP, and port 0. The broadcasts were sent properly, but the replies were never seen by the listener. That's how I got to this point.

Sorry for the novel. I'll understand if you want to ignore me now.

Thanks again,

David.

Bubba214617-Jul-02 8:27

Bubba2146

17-Jul-02 8:27

Heh, I fear this is a case where you have too many "unique" details for me to be much help. It seems like you get the drift of what I was saying, but it doesn't directly apply to you. Frown | :(

Dave_17-Jul-02 8:29