any suggestion?
-
Hi, I'm studying C++, VC++, COM, ACTIVEX + OLE. I would like to know real world examples of various assignments programmers have worked on. For example, what the application did what role did they play. The examples would be using these kinds of technologies. If any programmers could provide some insight into their "real world VC++, MFC, COM experiences it would be very helpful. Any one who has worked on large scale apps, developing controls, database interfaces, or anything else they have done using these technologines, who can lend some insight into how they real world of programming is.
-
Hi, I'm studying C++, VC++, COM, ACTIVEX + OLE. I would like to know real world examples of various assignments programmers have worked on. For example, what the application did what role did they play. The examples would be using these kinds of technologies. If any programmers could provide some insight into their "real world VC++, MFC, COM experiences it would be very helpful. Any one who has worked on large scale apps, developing controls, database interfaces, or anything else they have done using these technologines, who can lend some insight into how they real world of programming is.
The company I work for builds high speed ink jet printers[^]. We use a central industrial PC to act as the controller for the various subsystems. I'm responsible for the user interface for the controller. We have three primary product lines, based roughly on the source of the data to be printed and the customer's workflow. Also, quite a few of our customers have/want custom hardware that we need to integrate. We therefore needed a flexible architecture for the UI that can support a common set of functionality, yet adapt to specific customer needs. After a lot of research and a fair amount of test-benching, we settled on using COM to build a framework for the UI. The primary UI application enumerates the COM objects that implement a component category[^]. Each object specifies how it participates in the UI by the interfaces it implements. Using this technique, we essentially construct the UI at run-time. We base the final UI layout on the components that are installed and hardware discovery that happens during the startup process. This approach has worked really well. Most of our UI components are in-process servers (DLL's). A couple of our components have been local servers (EXE's). The local servers are good for fail-safe mechanisms, since the EXE runs in a separate process. The component is isolated from faults in the primary UI application, and vice versa. In our first product that we used COM as an interface method, we used DCOM between the controller and one of the subsystem PC's. This didn't work out as well. DCOM has poor connection fault behavior. If one of the endpoints of a DCOM connection fails, it can require up to six minutes for the other endpoint to find out, depending on the circumstances. In our later products, we've switched to a classic TCP/IP sockets communication method that is much more responsive.
Software Zen:
delete this; -
The company I work for builds high speed ink jet printers[^]. We use a central industrial PC to act as the controller for the various subsystems. I'm responsible for the user interface for the controller. We have three primary product lines, based roughly on the source of the data to be printed and the customer's workflow. Also, quite a few of our customers have/want custom hardware that we need to integrate. We therefore needed a flexible architecture for the UI that can support a common set of functionality, yet adapt to specific customer needs. After a lot of research and a fair amount of test-benching, we settled on using COM to build a framework for the UI. The primary UI application enumerates the COM objects that implement a component category[^]. Each object specifies how it participates in the UI by the interfaces it implements. Using this technique, we essentially construct the UI at run-time. We base the final UI layout on the components that are installed and hardware discovery that happens during the startup process. This approach has worked really well. Most of our UI components are in-process servers (DLL's). A couple of our components have been local servers (EXE's). The local servers are good for fail-safe mechanisms, since the EXE runs in a separate process. The component is isolated from faults in the primary UI application, and vice versa. In our first product that we used COM as an interface method, we used DCOM between the controller and one of the subsystem PC's. This didn't work out as well. DCOM has poor connection fault behavior. If one of the endpoints of a DCOM connection fails, it can require up to six minutes for the other endpoint to find out, depending on the circumstances. In our later products, we've switched to a classic TCP/IP sockets communication method that is much more responsive.
Software Zen:
delete this;Gary R. Wheeler wrote: In our first product that we used COM as an interface method, we used DCOM between the controller and one of the subsystem PC's. This didn't work out as well. DCOM has poor connection fault behavior. If one of the endpoints of a DCOM connection fails, it can require up to six minutes for the other endpoint to find out, depending on the circumstances. In our later products, we've switched to a classic TCP/IP sockets communication method that is much more responsive. I had a similar experiences with DCOM. I was lead to believe it was the holy grail - Remote Object Invocation - sounds sexy but I had problems with security issues, connectivity, and speed. I would stongly recommend to everybody "steer clear of DCOM".
-
Gary R. Wheeler wrote: In our first product that we used COM as an interface method, we used DCOM between the controller and one of the subsystem PC's. This didn't work out as well. DCOM has poor connection fault behavior. If one of the endpoints of a DCOM connection fails, it can require up to six minutes for the other endpoint to find out, depending on the circumstances. In our later products, we've switched to a classic TCP/IP sockets communication method that is much more responsive. I had a similar experiences with DCOM. I was lead to believe it was the holy grail - Remote Object Invocation - sounds sexy but I had problems with security issues, connectivity, and speed. I would stongly recommend to everybody "steer clear of DCOM".
I haven't attempted to use DCOM since '98. It sounded so good in theory but didn't stand up to the real world. Mind you I was using 9.x clients so that was just asking for trouble. Michael 'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
-
I haven't attempted to use DCOM since '98. It sounded so good in theory but didn't stand up to the real world. Mind you I was using 9.x clients so that was just asking for trouble. Michael 'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
Yeah, it sounds great. We were using two boxes, private network, Win2K on both. It still wasn't robust enough for our requirements.
Software Zen:
delete this;