Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread using the window.external object
Thu, Jul 30 2015 12:19 AMPermanent Link

Max Evans

Tim,

I asked you about integrating the "window.external" object a couple of years back now, and I noticed in the webDOM that it is not implemented.

As a refresher, I have (win32/64 based) desktop apps that use embedded IE contained within a TForm within the app.  I communicate with the embedded IE instance via capturing window.external events from a url click on the html page.

For example the url could be  <a href=javascript:window.external.dothis(456)>Click here</a> and my windows app traps this event, reads the parameters and does something useful like display a dialog. The trickiest part is that the parameters of window.external can be anything and so would be potentially undefined at compile/runtime.

Your response at the time was that it could be possible maybe using variants, but of course EWB2 has arrived and perhaps using variants is no longer applicable.

Appreciate your comments.


Cheers

Max Evans
Thu, Jul 30 2015 8:04 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Max,

For anyone reading this, this handy reference illustrates what is being discussed:

http://delphidabbler.com/articles?article=22&part=1

<< For example the url could be  <a href=javascript:window.external.dothis(456)>Click here</a> and my windows app traps this event, reads the parameters and does something useful like display a dialog. The trickiest part is that the parameters of window.external can be anything and so would be potentially undefined at compile/runtime.

Your response at the time was that it could be possible maybe using variants, but of course EWB2 has arrived and perhaps using variants is no longer applicable. >>

EWB 2 actually does have variants (shhh, don't tell anyone), but the issue really isn't variants, but rather just prototyping the external interface to your external methods that you've defined.  Because your external method parameters and return values are typed, variants are of little consequence here.  Variants should always be reserved for the very infrequent edge cases where there is absolutely no way to do it without them.  The reason for this is that they basically cause the compiler to throw its hands up and say "anything goes", which can introduce runtime errors if you're not careful.  EWB uses them in the WebCore unit at runtime for getting/setting property values by name with the persistence layer.

Normally, this would be an issue because the browser window class (TWindow) is defined in the WebDOM unit, which is normally something that is distributed with EWB, so you don't want to modify it, if you can help it.  Partial classes would work here, but we don't have that in EWB yet, so we'll have to do something else, which is to use the fact that "window" is implicitly the global scope in the browser.

uses WebDOM; //  Need this !!!

type

  external TExternal emit external = class
     public
        procedure callMethod(const strParam: String);
     end;

implementation

var
  external external: TExternal;  // Yes, this looks really weird, but is valid

And then you can just call it like this:

procedure TForm1.Button5Click(Sender: TObject);
begin
  external.callMethod('Test');
end;

You can actually do this with any class instance that is attached to the TWindow class as a property.  For example:

var
  external sessionStorage: TStorage;

procedure TForm1.Button5Click(Sender: TObject);
begin
  sessionStorage.setItem('Test','Test value');
  ShowMessage(sessionStorage.getItem('Test'));
end;

Normally, with EWB you would use window.sessionStorage for the sake of clarity, or if you need to access the sessionStorage for a particular window instance (iframes).

Tim Young
Elevate Software
www.elevatesoft.com
Thu, Jul 30 2015 6:39 PMPermanent Link

Max Evans

How superbly elegant Tim.
Sun, May 22 2016 10:37 PMPermanent Link

Trinione

<< For anyone reading this, this handy reference illustrates what is being discussed:

uses WebDOM; //  Need this !!!
type
  external TExternal emit external = class
     public
        procedure callMethod(const strParam: String);
     end;
implementation
var
  external external: TExternal;  // Yes, this looks really weird, but is valid
>>

Hi:
I have spent quite some time attempting to use this thread to access the attached script.js file.

How can the Events and Methods be defined and accessed?

Say the send function (Method), and the onopen Event.

external TsgcWebSocket emit sgcWebSocket = class
 public
   {Properties}
   {Events}
   {Methods}                   
   procedure send(str: string);
 end;

var
 external sgcWebSocket: TsgcWebSocket;


procedure TForm1.Button1Click(Sender: TObject);
begin
 sgcWebSocket('ws://localhost:80');
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
 sgcWebSocket.send('Hello World!');
end;



Attachments: script.js
Mon, May 23 2016 12:55 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com


<< I have spent quite some time attempting to use this thread to access the attached script.js file. >>

Are you trying to implement WebSockets ?  If so, then you should skip all of that and just define an external interface for the web socket support in the DOM:

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

It will be easier that way.

Tim Young
Elevate Software
www.elevatesoft.com
Image