🚀 go-pugleaf

Trevor Keegan escreveu:
> I am filling in a form on a website that invokes events when the field is 
> changed.  When I fill in the form through (say) IHTMLInputTextElement these 
> events are not invoked.
> 
> What do I need to do to get these events to fire?
> 

Take a look at the events.
They must be links or Java functions.

What you can do is when you fill the form, trigger yourself the events. :)

If the event is a link, call the link.

If the event is a java script (what is most common), call it like if it 
was a link:

CppWebBrowser->Navigate("javascript:Myfunc()");

Will work :)

Only a tip... If this operation will be done many times, maybe you must 
consider using another component...

TCppWebBrowser, being a wraper for the ActiveX of IE is horrible... ;)

But will work for many applications :)

Hi Eduardo,

Thanks for your reply

The problem is I have stuff like this:
class=text id="F00043" 
value="TKEEGAN@EALINK.COM"onChange="javascript:this.value=this.value.toUpperCase();" 
OnBlur="return checkEmail(this)"

While this is a fairly simple thing to handle, I am just worried that the 
authors will at some point in time change/add stuff to the script...this 
will then mean that I have to be aware of these changes.  I though that it 
would be better if there was some way to force the execution of these 
events.

Regards
Trevor Keegan 

"Trevor Keegan" <tkeegan@ealink.com> wrote in message
news:45dcef87$1@newsgroups.borland.com...

> What do I need to do to get these events to fire?

Fire them manually.  The browser's DOM interfaces provide access to
them.

Events are normally accessed via the IDispatch interface.  So, for
example, to fire the onblur event, you would call
IHTMLElement2::get_onblur(), which returns a VARIANT containing an
IDispatch interface.  You would then call the IDispatch::Invoke()
method, specifying DISPID_VALUE as the ID to execute.

Alternatively, use the IHTMLElement3::fireEvent() method instead,
which does the above work for you.


Gambit

"Trevor Keegan" <tkeegan@ealink.com> wrote in message
news:45dcf664@newsgroups.borland.com...

> I though that it would be better if there was some way to force
> the execution of these events.

There is.  See my other reply.


Gambit

Always learning something new :)
Good to know :)

Hello Remy,

I did see the Invoke method there, but it looked as though I needed to send 
in a whole bunch of parameters. So I thought there might be another way :)

> Alternatively, use the IHTMLElement3::fireEvent() method instead,
> which does the above work for you.
I like the sound of this....but please help me, how do I get to the 
IHTMLElement3....I current have this:

        TComInterface<IHTMLInputTextElement> TextInput;
        Disp->QueryInterface( IID_IHTMLInputTextElement, 
(LPVOID*)&TextInput );

        if( TextInput )
        {
          //Set the value in the field
          TextInput->put_value( WideString( Value ) );
        }

Should I add something like IHTMLElement3::fireEvent( "OnBlur", TextInput ) 
?

Regards
Trevor Keegan 

"Trevor Keegan" <tkeegan@ealink.com> wrote in message
news:45dd392b@newsgroups.borland.com...

> I did see the Invoke method there, but it looked as though I needed
> to send in a whole bunch of parameters. So I thought there might
> be another way :)

Invoke() is a very flexible method.  Just because it has room to
accept parameters does not mean that you have to use them.  In fact,
DISPID_VALUE is a default method, so it does not accept any input
parameters.  You would fill in the DISPPARAMS structure with empty
data.  There is an example in IDispatch's documentation of calling a
method with no parameters.

> I like the sound of this....but please help me, how do I get
> to the IHTMLElement3....

The same way you get any interface from another - via the
QueryInterface() method.

> I current have this:
<snip>
> Should I add something like IHTMLElement3::fireEvent( "OnBlur",
TextInput )
> ?

Please read the documentation for fireEvent():


http://msdn.microsoft.com/workshop/browser/mshtml/reference/ifaces/element3/fireevent.asp


Gambit

Hello Remy,

Thanks for your help :-)

I am sure that there is something fundamental that I am missing here.  When 
I try to compile the code:
          TComInterface<IHTMLElement3> Element;
The comiler complains basically telling me that it does not know what an 
IHTMLElement3 is.  I have found other types (e.g. IHTMLTextElement) in th 
comdef.h header file...but not the IHTMLElement3.

I am using Builder 6, is there something that I need to do that I am not 
doing?

Regards
Trevor Keegan 

"Trevor Keegan" <tkeegan@ealink.com> wrote in message
news:45de9306@newsgroups.borland.com...

> When I try to compile the code:
>           TComInterface<IHTMLElement3> Element;
> The comiler complains basically telling me that it does not
> know what an IHTMLElement3 is.

IHTMLElement3 is not defined in the SDK headers that ship with BCB 6.
You will have to declare the interface manually in your own code.
Alternatively, import mshtml.tlb into the IDE and have it generate
MSHTML_TLB.cpp and MSHTML_TLB.h files that you can use.


Gambit

Hello Remy

OK....I have imported the library using:
tlibimp -Hs- -Hr- -Fe- \windows\system32\mshtml.tlb......And I can see that 
it has created the IHTMLElement3 interface for me :)

The problem that I have now is that code that was compiling ok....now does 
not compile....in particular the compiler now complains that the put_value 
is not a member of the IHTMLInputTextElement......but it is according to
http://msdn.microsoft.com/workshop/browser/mshtml/reference/ifaces/inputtextelement/inputtextelement.asp

        TComInterface<IHTMLInputTextElement> TextInput;
        Disp->QueryInterface( IID_IHTMLInputTextElement, 
(LPVOID*)&TextInput );

        if( TextInput )
        {
          //Set the value in the field
          TextInput->put_value( WideString( Value ) );
        }

The problem appears to be now that I have 2 mshtml.h files.  The original 
one and the new one, is this correct?

Regards
Trevor Keegan 

"Trevor Keegan" <tkeegan@ealink.com> wrote in message
news:45debab4@newsgroups.borland.com...

> The problem that I have now is that code that was compiling ok....
> now does not compile....in particular the compiler now complains
> that the put_value is not a member of the
IHTMLInputTextElement......

Look at the declaration of the IHTMLInputTextElement interface in the
headers.  What do you actually see?


Gambit

Hello Remy,

>> The problem that I have now is that code that was compiling ok....
>> now does not compile....in particular the compiler now complains
>> that the put_value is not a member of the
> IHTMLInputTextElement......
>
> Look at the declaration of the IHTMLInputTextElement interface in the
> headers.  What do you actually see?
I have taken a look and now see what the problem is.....it appears as though 
all the put methods (e.g. put_value) have now been changed to set methods 
(i.e. set_value).  I recently upgraded to IE 7, I guess that this must been 
the cause of this.

Regards
Trevor Keegan 

"Trevor Keegan" <tkeegan@ealink.com> wrote in message
news:45e0fa15@newsgroups.borland.com...

> I have taken a look and now see what the problem is.....it appears
> as though all the put methods (e.g. put_value) have now been changed
> to set methods (i.e. set_value).  I recently upgraded to IE 7, I
guess
> that this must been the cause of this.

No.  Interface methods are not changed once exposed.  That is a core
rule of COM programming in order to ensure backwards compatibility
when releasing new versions of a library.  Are you sure that you are
actually accessing the interface directly, and not the VCL wrapper
that the IDE generated for you?


Gambit

Hello Remy,

> No.  Interface methods are not changed once exposed.  That is a core
> rule of COM programming in order to ensure backwards compatibility
> when releasing new versions of a library.  Are you sure that you are
> actually accessing the interface directly, and not the VCL wrapper
> that the IDE generated for you?
Umm, now that you mention it I had assumed that the correct files would be 
generated would be given the correct thing.....I assume for a start that I 
am importing it the correct way (so it might be that I am not using the 
correct method).  I notice that the original mshtml.h (in the 
Cbuilder6\include directory) was only about 1.5Mb in size......the newly 
generated one is a massive 19.4mb in size.  There were 2 header files 
generated.....a MSHTML.H file (19.4mb) and a MSHTML_OCX.H file (only 6kb) in 
size.

Regards
Trevor Keegan