Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Display GUI of object server on client
- Thread starter almoes
- Start date
- Thread starter
- #3
I'm not sure if I understand exactly what you mean.
Your question is titled "Display GUI of object server on client". By that I figured you wanted to show some GUI elements of a remote server on a client machine (especially since you're talking about DCOM). If this is the case, then I'm sorry... this is NOT possible.
But you CAN display GUI elements of a server on the client locally. However, for you to be able to add it as a control to a VB form, the server will have to support all the necessary interfaces to communicate and interact with a container (you would have to write an ActiveX control, since what you want to do should be in-process). You can also pass the handle of the form to the server to set as the parent window and handle everything yourself (in the server as well as in the client).
Greetings,
Rick
Your question is titled "Display GUI of object server on client". By that I figured you wanted to show some GUI elements of a remote server on a client machine (especially since you're talking about DCOM). If this is the case, then I'm sorry... this is NOT possible.
But you CAN display GUI elements of a server on the client locally. However, for you to be able to add it as a control to a VB form, the server will have to support all the necessary interfaces to communicate and interact with a container (you would have to write an ActiveX control, since what you want to do should be in-process). You can also pass the handle of the form to the server to set as the parent window and handle everything yourself (in the server as well as in the client).
Greetings,
Rick
- Thread starter
- #5
In the server I run an Activex EXE, and I dont really care if it runs locally on the client (your suggestion). My goal is to have a component that makes a dial-up conection running on the server (I have this component). Each client should be able to get the the interface to this component, but the real dial-up is done in the server. Could you tell me where I could find more info on 'passing the handle of a form to the server'? Any other ideas are welcome.
- Thread starter
- #7
What I mean is:
Create a method in one of the interface of the server called "ParenthWnd" or something like that. Have it accept a LONG as the argument and pass in the handle to the form you're using. After calling this method your server has a handle to the form....
Greetings,
Rick
Create a method in one of the interface of the server called "ParenthWnd" or something like that. Have it accept a LONG as the argument and pass in the handle to the form you're using. After calling this method your server has a handle to the form....
Greetings,
Rick
- Thread starter
- #9
Well, you said that you wanted to load something on your form. The easiest thing would be to create an ActiveX control for that. But if your server is NOT an ActiveX control, you can make it a child window of your form. For that the server needs to have the handle to the form, so it can set it as its parent window. I don't know which language the server is written in, but if it's in C++ you're probably creating the window with CreateWindow(Ex) and then you could pass the hWnd of your VB form to this function. In VB it would be a bit more difficult, because a form is a dialog, NOT an ordinary window. You would have to go into APIs to create an ordinary window.
Now, if you have the server window and its parent handle, you have to pass the handle to the server window to your VB form via a callback or a connection point (event). This way you can position the window on your VB form with the SetWindowPos API or other window manipulation APIs.
I admit that it ain't easy but it's the only way I can think of doing what you want to do without using an ActiveX control. You cannot manipulate ordinary windows on your VB form (or any other kind of window) the way you would with ActiveX controls (like Left, Width etc.) simply because the interfaces to communicate with the container (and the oter way around) are missing if it isn't an ActiveX control.
Greetings,
Rick
Now, if you have the server window and its parent handle, you have to pass the handle to the server window to your VB form via a callback or a connection point (event). This way you can position the window on your VB form with the SetWindowPos API or other window manipulation APIs.
I admit that it ain't easy but it's the only way I can think of doing what you want to do without using an ActiveX control. You cannot manipulate ordinary windows on your VB form (or any other kind of window) the way you would with ActiveX controls (like Left, Width etc.) simply because the interfaces to communicate with the container (and the oter way around) are missing if it isn't an ActiveX control.
Greetings,
Rick
- Thread starter
- #11
- Thread starter
- #13
Try browing to it from within the components window. Maybe VB will then create the registry info on your system and very maybe you can still use it like it were local. But mind you; the machine name of the pc where the control is actually located should always be available to you (if it works, it's in the path to the control located in YOUR registry.
Greetings,
Rick
Greetings,
Rick
- Thread starter
- #15
I also tried that but its not possible because the files that contain the info of the remote object are .tlb and .vbr and VB doesn't let me add this. The registry paths to the remote host are correct, if not I would get a 'can't create object' error, which i had previously.
regards,
Alejandra
regards,
Alejandra
If that's not the error you're getting, which are you getting?
Or is nothing happening at all?
The problem with what you're trying to do is that an ActiveX control is an in-process server. Those servers need a host process to be loaded into. And since your process does not reach until the remote machine, it will not be able to load into your process space. There is an executable that can host in-proc servers for you, and therefore allowing you to use an inproc server as a local or remote server, but I'm not sure if this also works with ActiveX controls. Also, to be able to do this, COM will have to marshall the interfaces across process boundaries and therefore requires marshalling information. Since it is very easy for you to write a COM server in VB which does NOT comply with the OLE compliant datatypes, you will have to be very carefull to avoid that (or create and register your own proxy-stub dlls, which I've never done in VB so I can't help you with that). Also I can't remember exactly the name of the executable that can host dlls for you, I'll have to look that up when I get home.
Greetings,
Rick
Or is nothing happening at all?
The problem with what you're trying to do is that an ActiveX control is an in-process server. Those servers need a host process to be loaded into. And since your process does not reach until the remote machine, it will not be able to load into your process space. There is an executable that can host in-proc servers for you, and therefore allowing you to use an inproc server as a local or remote server, but I'm not sure if this also works with ActiveX controls. Also, to be able to do this, COM will have to marshall the interfaces across process boundaries and therefore requires marshalling information. Since it is very easy for you to write a COM server in VB which does NOT comply with the OLE compliant datatypes, you will have to be very carefull to avoid that (or create and register your own proxy-stub dlls, which I've never done in VB so I can't help you with that). Also I can't remember exactly the name of the executable that can host dlls for you, I'll have to look that up when I get home.
Greetings,
Rick
- Thread starter
- #17
Now I am completely lost with what you said. If i run the client, it works to create the object with the function 'createObject' but then I dont get the GUI of the displayed. So I thought of adding the control to the form at design time with Controls.Add, and then i get the following error: 'Error 713 - Class not registered. Looking for object with CLSID: {..}'
but the CLSID for the remote files is in the registry and its correct!
Regards,
Alejandra
but the CLSID for the remote files is in the registry and its correct!
Regards,
Alejandra
If everything is correctly registerd you should be able to view it with OLE view.
Check the registry entry in HKEY_CLASSES_ROOT\CLSID\{your guid}\InprocServer32
See if the path to the server is actually the remote machine.
Also check the \TypeLib in the regeistry path.
From there move to HKEY_CLASSES_ROOT\TypeLib\{your type lib}\..\win32. This path should be on YOUR machine.
But to be honest, I'm afraid that you really can't use the ActiveX object remotely. Why don't you just write a remote (EXE) server to be located on the server and an ActiveX control that communicates with the remote server and can be located locally and therefore simply put on the form?
Greetings,
Rick
Check the registry entry in HKEY_CLASSES_ROOT\CLSID\{your guid}\InprocServer32
See if the path to the server is actually the remote machine.
Also check the \TypeLib in the regeistry path.
From there move to HKEY_CLASSES_ROOT\TypeLib\{your type lib}\..\win32. This path should be on YOUR machine.
But to be honest, I'm afraid that you really can't use the ActiveX object remotely. Why don't you just write a remote (EXE) server to be located on the server and an ActiveX control that communicates with the remote server and can be located locally and therefore simply put on the form?
Greetings,
Rick
- Thread starter
- #19
- Status
Similar threads
- Locked
- Question