Accessing VB6 control properties from VC++
-
I have a need to access the properties of controls in a VB6 executable from VC++. I've tried various MFC/Windows calls to do this, and know the classnames of the windows that correspond to the controls, but haven't managed to find a procedure that works as of yet. If anyone has a clue on how to do this, I'd appreciate suggestions... thanks. Bob
-
I have a need to access the properties of controls in a VB6 executable from VC++. I've tried various MFC/Windows calls to do this, and know the classnames of the windows that correspond to the controls, but haven't managed to find a procedure that works as of yet. If anyone has a clue on how to do this, I'd appreciate suggestions... thanks. Bob
This question is better off in the C++ forum. But are you trying to get at the controls of a VB app you've written, or something you don't have the source code to? RageInTheMachine9532
-
This question is better off in the C++ forum. But are you trying to get at the controls of a VB app you've written, or something you don't have the source code to? RageInTheMachine9532
RageInTheMachine9532 wrote: This question is better off in the C++ forum. But are you trying to get at the controls of a VB app you've written, or something you don't have the source code to? I can understand why you think this is more of a C++ question; the truth is, it is at its core a "VB internals" question, and with some info on that I might end up in the C++ forum or the ATL forum... I'm trying to get at properties of objects within a VB executable, and though in my "pilot project" I have access to the source, I need to be able to do this in programs where I do not have source. The base question I have is where this info is stored and/or (more importantly) what structured access, if any, is provided to it. I'm hoping that VB windows and controls are, from the MFC perspective, COM/ATL objects that are wrapped in CWindow objects, and that I can get an IUnknown interface pointer from them and from there explore whatever info they expose. I haven't found any info on how VB implements their objects from a C++/MFC perspective, though, so I'm speculating based on what I can deduce using Spy++ and other similar tools. Any clues? Thanks- Bob
-
RageInTheMachine9532 wrote: This question is better off in the C++ forum. But are you trying to get at the controls of a VB app you've written, or something you don't have the source code to? I can understand why you think this is more of a C++ question; the truth is, it is at its core a "VB internals" question, and with some info on that I might end up in the C++ forum or the ATL forum... I'm trying to get at properties of objects within a VB executable, and though in my "pilot project" I have access to the source, I need to be able to do this in programs where I do not have source. The base question I have is where this info is stored and/or (more importantly) what structured access, if any, is provided to it. I'm hoping that VB windows and controls are, from the MFC perspective, COM/ATL objects that are wrapped in CWindow objects, and that I can get an IUnknown interface pointer from them and from there explore whatever info they expose. I haven't found any info on how VB implements their objects from a C++/MFC perspective, though, so I'm speculating based on what I can deduce using Spy++ and other similar tools. Any clues? Thanks- Bob
BobAshforth wrote: I'm hoping that VB windows and controls are, from the MFC perspective, COM/ATL objects that are wrapped in CWindow objects, I think your on the right track, but I remember seeing soemthing a few years back that said that with VB5 and 6, the standard controls all use vtable COM interfaces. I also remember seeing something about using IDispatch to get to an already running instance but I can't find the article anymore. I haven't found any examples of this on the web either. From what I know about what your doing, you're in for ALOT of work if you have to use IDispatch to "generically" get to the controls. Either way, it's not going to be an easy to solve. RageInTheMachine9532
-
RageInTheMachine9532 wrote: This question is better off in the C++ forum. But are you trying to get at the controls of a VB app you've written, or something you don't have the source code to? I can understand why you think this is more of a C++ question; the truth is, it is at its core a "VB internals" question, and with some info on that I might end up in the C++ forum or the ATL forum... I'm trying to get at properties of objects within a VB executable, and though in my "pilot project" I have access to the source, I need to be able to do this in programs where I do not have source. The base question I have is where this info is stored and/or (more importantly) what structured access, if any, is provided to it. I'm hoping that VB windows and controls are, from the MFC perspective, COM/ATL objects that are wrapped in CWindow objects, and that I can get an IUnknown interface pointer from them and from there explore whatever info they expose. I haven't found any info on how VB implements their objects from a C++/MFC perspective, though, so I'm speculating based on what I can deduce using Spy++ and other similar tools. Any clues? Thanks- Bob
If you are using Managed C++ to access VB.NET control it would definitely easier. Sonork 100.41263:Anthony_Yio
-
BobAshforth wrote: I'm hoping that VB windows and controls are, from the MFC perspective, COM/ATL objects that are wrapped in CWindow objects, I think your on the right track, but I remember seeing soemthing a few years back that said that with VB5 and 6, the standard controls all use vtable COM interfaces. I also remember seeing something about using IDispatch to get to an already running instance but I can't find the article anymore. I haven't found any examples of this on the web either. From what I know about what your doing, you're in for ALOT of work if you have to use IDispatch to "generically" get to the controls. Either way, it's not going to be an easy to solve. RageInTheMachine9532
Thanks for the input...
-
If you are using Managed C++ to access VB.NET control it would definitely easier. Sonork 100.41263:Anthony_Yio
:-D ... Great- now all I have to do is demand that the creators of the apps I need to interact with rewrite them in .NET, and I'll be all set! LOL... Unfortunately, I need to do this with non-.NET apps, so my quest continues...