Attempting to Automate VSS 2005 w/ VFP9

I'm revisiting a problem that stumped me years ago.

I'd like to automate the sharing of project files within the VFP IDE through
VSS Automation, and everything's good to go except for the VSS "add file to
source control" dialog - I'm hoping I might be able to use some of the new
functionality VFP9 to get past this.

Here are some options AFAIK:

VSS's IVSSEventHandler interface - but would have to write a separate DLL.
BindEvent() - to trap windows messages and perhaps get a reference to the
dialog window.
EventHandler() - but so far, I don't have a COM object to attach to.

I think I need to get a reference to the dialog window's hWnd and do
something like a SendKeys or a SendMessage, but the VSS automation doesn't
seem to expose any objects I can grab a hold of.. Would appreciate all
suggestions.

Thanks.
--
William Fields
Code Contortionist
MCSD - Microsoft Visual FoxPro
US Bankruptcy Court
Phoenix, AZ

".dll hell - .rpm hell - whatever.
The grass is always greener"

Thomas
Mon Feb 06 03:24:36 CST 2006


>
> VSS's IVSSEventHandler interface - but would have to write a separate DLL.
> BindEvent() - to trap windows messages and perhaps get a reference to the
> dialog window.
> EventHandler() - but so far, I don't have a COM object to attach to.
>
> I think I need to get a reference to the dialog window's hWnd and do
> something like a SendKeys or a SendMessage, but the VSS automation doesn't
> seem to expose any objects I can grab a hold of.. Would appreciate all
> suggestions.

What exactly have you tried ? Thee are some odd angles like VSS only
allowing the use of it's objects in it's own thread.

HTH

thomas

William
Mon Feb 06 11:47:04 CST 2006

I've used Spy++ (included in VS6 tools) to identify that the VSS dialog is
running within the same process and is a child window of the VFP IDE. I've
also captured the windows messages generated during the oFiles.Add() method
call which is what causes the VSS dialog to launch.

Another twist is that the VSS dialog is modal - not sure if hooking up a
BindEvent() to the specific windows message that's generated during the
dialog launch would do anything for me, but it does seem like a better
chance than trying to interrogate the child windows of the IDE in order to
send messages that would cause it to just go on without user intervention.


--
William Fields
Code Contortionist
MCSD - Microsoft Visual FoxPro
US Bankruptcy Court
Phoenix, AZ

".dll hell - .rpm hell - whatever.
The grass is always greener"





"Thomas Ganss"
<tganss_at_t_dash_online_dot_de-remove-all-after-first-real-dash@yahoo.com>
wrote in message news:ds74qu$t5c$01$1@news.t-online.com...
>
>>
>> VSS's IVSSEventHandler interface - but would have to write a separate
>> DLL.
>> BindEvent() - to trap windows messages and perhaps get a reference to the
>> dialog window.
>> EventHandler() - but so far, I don't have a COM object to attach to.
>>
>> I think I need to get a reference to the dialog window's hWnd and do
>> something like a SendKeys or a SendMessage, but the VSS automation
>> doesn't seem to expose any objects I can grab a hold of.. Would
>> appreciate all suggestions.
>
> What exactly have you tried ? Thee are some odd angles like VSS only
> allowing the use of it's objects in it's own thread.
>
> HTH
>
> thomas

Thomas
Tue Feb 07 06:31:47 CST 2006

William Fields schrieb:
> I've used Spy++ (included in VS6 tools) to identify that the VSS dialog is
> running within the same process and is a child window of the VFP IDE. I've
> also captured the windows messages generated during the oFiles.Add() method
> call which is what causes the VSS dialog to launch.

Sorry that I missed.
>
> Another twist is that the VSS dialog is modal - not sure if hooking up a
> BindEvent() to the specific windows message that's generated during the
> dialog launch would do anything for me, but it does seem like a better
> chance than trying to interrogate the child windows of the IDE in order to
> send messages that would cause it to just go on without user intervention.

I went the other way and implemented COM event listeners
(via VB >com dll calling vfp com dll calling VFP Com Exe for own UI)
but since this was way back on earlier vfp-versions I am not too sure if
all that is still necessary nowadays.

regards

thomas




>
>