I have inherited a pair of applications: a client.exe and a server.exe. They run on different PCs and communicate through TCP/IP. The server comes with an OCX file: server.ocx. The client has its own OCX file: client.ocx. (I suspect there could be a mismatch between the two ocx files.) I don't have the server source code, but I do have the client source code. It's a C++ console application that "#import"s the client.ocx file. Also I see that the client advises the server of its sink object. The client then calls methods on the server's interface and all server replies come to the sink object.

My question is: why are there two different OCX files? Could both the server and client utilize the same OCX file, presumably the server one?

Also, can I create a new client application using a wizard that would generate all necessary C++ information given the server OCX file only? In other words, can I circumvent the client.ocx file?


Recommended Answers

All 3 Replies

Since client and server run on different computers how do you think the client is going to be able to use an ocx that's on the server computer? Since we know nothing about either program we don't know if the two ocx files are needed or not. You might be able to do away with both of them if you rewrite the two programs, and that's probably not possible if they are already in production.


Thank you for your reply. I didn't mean the client would reach over to the server for the file. I only meant the server ocx file would be copied over from the remote PC to the client PC, registered there and #import- ed into the client code. Then both the server and the client would essentially be using the same ocx file.

My concern is: when I examine the client.ocx and the server.ocx, I see a peculiar thing. The client.ocx declares "client" interfaces, while the server.ocx declares both "client" and "server" interfaces. But the id's of the corresponding "client" interfaces are different between the two ocx files. Is that ok?


Since both client and server are aparently working together right now the id values shold make no difference.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.