Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 10 total
Thread External code interface changed?
Fri, May 1 2015 7:52 AMPermanent Link

Matthew Jones

I'm having a problem with code that works in EWB1, but not in the
preview. If it is complicated to resolve, it can wait.

Basically, the RemObjects interface code appears to be working to
create objects, but they are being set as "undefined" in the variables.

procedure TfrmModel.CreateConnection;
var
  szServer : String;
  szHostAddress : String;
begin
 szHostAddress := window.location.host;
 szServer := 'https://' + szHostAddress + '/JSON';
 FChannel := Remobjects.SDK.HTTPClientChannel.Create(szServer);  
 FMessage := Remobjects.SDK.JSONMessage.Create;
 m_xNewUserService := MatthewService.Create(FChannel, FMessage,
'MatthewService');
end;

This ends up as

fmodel_tfrmmodel.$p.tfrmmodel_createconnection = function()
{
  var $t = this, szserver = "", szhostaddress = "";
  szhostaddress = window.location.host;
  szserver = "https:\/\/" + szhostaddress + "\/JSON";
  $t.tfrmmodel_fchannel = RemObjects.SDK.HTTPClientChannel(szserver);
  $t.tfrmmodel_fmessage = RemObjects.SDK.JSONMessage();
  $t.tfrmmodel_m_xnewuserservice = new
MatthewService($t.tfrmmodel_fchannel, $t.tfrmmodel_fmessage,
"MatthewService");
};

Now, if I step into those constructors, it is setting up the variables
etc, and "this" appears to be okay. But when I step out of the
constructor in Chrome, the _fchannel and _fMessage variables are
"undefined", so the next bit fails.

I think I've got it all right, but may not have. But is there a know
issue or change in this version?

Thanks, Matthew
Fri, May 1 2015 8:00 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< I'm having a problem with code that works in EWB1, but not in the
preview. If it is complicated to resolve, it can wait. >>

The way that the compiler deals with class types has completely changed, and
so there may or may not be an issue with some external interfaces that were
using class properties, etc. to "fudge" access to namespaces in external
javascript.  I ran into this problem in the documentation, which also had a
RemObjects example, and had to strip out the example because the old way
didn't work anymore.

I'll have to revisit this after things settle down with the release.

Tim Young
Elevate Software
www.elevatesoft.com
Fri, May 1 2015 8:23 AMPermanent Link

Matthew Jones

Tim Young [Elevate Software] wrote:

> I'll have to revisit this after things settle down with the release.

Okay, thanks.
Sat, May 2 2015 2:36 PMPermanent Link

Bruno Larochelle

Tim.. info when you do get around to this..

I ran into what is probably the same thing when trying to recompile (v1 to v2) the 'geolocation' example posted by Chris Holland a few moons ago:

http://www.elevatesoft.com/forums?action=view&category=ewb&id=ewb_demos&page=1&msg=139#139

Throwing errors about properties etc. If nothing else might serve as a good example to 'test' Smile

thanks again, i'm having so much fun with v2 so far!

/////////

"Matthew Jones" wrote:

Tim Young [Elevate Software] wrote:

> I'll have to revisit this after things settle down with the release.

Okay, thanks.
Logiciels Bitwise Software
Edmonton, AB, Canada
Tue, May 19 2015 5:46 PMPermanent Link

Doug B

<<
The way that the compiler deals with class types has completely changed
>>

I understand some things have changed, however shouldn't I be able to model external declarations as is done the WebDOM unit?

How do I properly declare an external reference to a simple class like this?

MyExternalJs.js:

var MyExternalClass = function () {
 this.data = '';
};

MyExternalClass.prototype.setData = function(theData) {
 this.data = theData;
};

MyExternalClass.prototype.getData = function() {
 return this.data;
};

EWB 2:
  external TMyExternalClass emit MyExternalClass = class
  public <---------------------------------------------------------------------- ERROR HERE
    procedure setData(theData: string);
    function getData: string;
  end;

I get the following error:

[Error] MyExternalJsTest.wbs (9,4): The referenced type object does not exist

Thanks,
Doug
Wed, May 20 2015 3:41 AMPermanent Link

Chris Holland

SEC Solutions Ltd.

Avatar

Team Elevate Team Elevate

Hi Doug,

I had an email from Tim about this earlier, this is the answer:

It's the way that the base external "object" class is now declared that
is tripping up your code.  There's now a WebDesign unit for declaring
that base external object for design-time usage, and the old WebDOM unit
for declaring
that base external object for run-time usage.   So, just include the
WebDOM unit in your unit's uses clause, like this:

uses WebDOM, WebCore;

and that will resolve your issue.


Chris Holland
[Team Elevate]

On 19/05/2015 22:46, Doug B wrote:
> <<
> The way that the compiler deals with class types has completely changed
>>>
>
> I understand some things have changed, however shouldn't I be able to model external declarations as is done the WebDOM unit?
>
> How do I properly declare an external reference to a simple class like this?
>
> MyExternalJs.js:
>
> var MyExternalClass = function () {
>    this.data = '';
> };
>
> MyExternalClass.prototype.setData = function(theData) {
>    this.data = theData;
> };
>
> MyExternalClass.prototype.getData = function() {
>    return this.data;
> };
>
> EWB 2:
>     external TMyExternalClass emit MyExternalClass = class
>     public <---------------------------------------------------------------------- ERROR HERE
>       procedure setData(theData: string);
>       function getData: string;
>     end;
>
> I get the following error:
>
> [Error] MyExternalJsTest.wbs (9,4): The referenced type object does not exist
>
> Thanks,
> Doug
>
Wed, May 20 2015 9:26 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Doug,

<< I understand some things have changed, however shouldn't I be able to
model external declarations as is done the WebDOM unit? >>

See Chris's answer.

I've made sure to point out the WebDOM unit requirement in the EWB2 manual.

Tim Young
Elevate Software
www.elevatesoft.com
Thu, May 21 2015 11:34 PMPermanent Link

Bruno Larochelle

I've attached here a conversion of Chris Holland's 'geolocation' example (EWB1), converted to EWB2.

Other than adding 'webDom' in a couple of the units, I also had to add a return type to the three external functions in the 'geolocationinterface' unit:

external function GetPosition(PositionSuccess: TGetPositionSuccess; PositionError: TGetPositionError): integer;
external function StartWatchingPosition(PositionSuccess: TGetPositionSuccess; PositionError: TGetPositionError): integer;
external function StopWatchingPosition(): integer;

I don't understand 'beans' about JavaScript (hence my love of EWB!), but this gave me something that works. I do note that doing the same thing (adding a return type) on the EWB1 version of this example compiled fine. So maybe EWB1 was less strict than EWB2.

////




"Tim Young [Elevate Software]" wrote:

Doug,

<< I understand some things have changed, however shouldn't I be able to
model external declarations as is done the WebDOM unit? >>

See Chris's answer.

I've made sure to point out the WebDOM unit requirement in the EWB2 manual.

Tim Young
Elevate Software
www.elevatesoft.com

Bruno Larochelle
Logiciels Bitwise Software
Edmonton, AB, Canada



Attachments: geolocation_ewb2.zip
Fri, May 22 2015 3:55 AMPermanent Link

Chris Holland

SEC Solutions Ltd.

Avatar

Team Elevate Team Elevate

Hi Bruno,

That was probably an incorrect declaration on my part in EWB1 which I
got away with, EWB2 picked it up.

I believe that they should have been declared as procedures not functions.

Chris Holland
[Team Elevate]

On 22/05/2015 04:34, Bruno Larochelle wrote:
> I've attached here a conversion of Chris Holland's 'geolocation' example (EWB1), converted to EWB2.
>
> Other than adding 'webDom' in a couple of the units, I also had to add a return type to the three external functions in the 'geolocationinterface' unit:
>
> external function GetPosition(PositionSuccess: TGetPositionSuccess; PositionError: TGetPositionError): integer;
> external function StartWatchingPosition(PositionSuccess: TGetPositionSuccess; PositionError: TGetPositionError): integer;
> external function StopWatchingPosition(): integer;
>
> I don't understand 'beans' about JavaScript (hence my love of EWB!), but this gave me something that works. I do note that doing the same thing (adding a return type) on the EWB1 version of this example compiled fine. So maybe EWB1 was less strict than EWB2.
>
> ////
>
>
>
>
> "Tim Young [Elevate Software]" wrote:
>
> Doug,
>
> << I understand some things have changed, however shouldn't I be able to
> model external declarations as is done the WebDOM unit? >>
>
> See Chris's answer.
>
> I've made sure to point out the WebDOM unit requirement in the EWB2 manual.
>
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
> Bruno Larochelle
> Logiciels Bitwise Software
> Edmonton, AB, Canada
>
Fri, May 22 2015 7:29 AMPermanent Link

Bruno Larochelle

thanks Chris.. I changed that to 'procedure' and that works fine. I was not sure I could do that because JavaScript does not use the keyword 'procedure'.

thanks also for providing the example, very useful!

.. Bruno

Chris Holland wrote:

Hi Bruno,

That was probably an incorrect declaration on my part in EWB1 which I
got away with, EWB2 picked it up.

I believe that they should have been declared as procedures not functions.

Chris Holland
[Team Elevate]

On 22/05/2015 04:34, Bruno Larochelle wrote:
> I've attached here a conversion of Chris Holland's 'geolocation' example (EWB1), converted to EWB2.
>
> Other than adding 'webDom' in a couple of the units, I also had to add a return type to the three external functions in the 'geolocationinterface' unit:
>
> external function GetPosition(PositionSuccess: TGetPositionSuccess; PositionError: TGetPositionError): integer;
> external function StartWatchingPosition(PositionSuccess: TGetPositionSuccess; PositionError: TGetPositionError): integer;
> external function StopWatchingPosition(): integer;
>
> I don't understand 'beans' about JavaScript (hence my love of EWB!), but this gave me something that works. I do note that doing the same thing (adding a return type) on the EWB1 version of this example compiled fine. So maybe EWB1 was less strict than EWB2.
>
> ////
>
>
>
>
> "Tim Young [Elevate Software]" wrote:
>
> Doug,
>
> << I understand some things have changed, however shouldn't I be able to
> model external declarations as is done the WebDOM unit? >>
>
> See Chris's answer.
>
> I've made sure to point out the WebDOM unit requirement in the EWB2 manual.
>
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
> Bruno Larochelle
> Logiciels Bitwise Software
> Edmonton, AB, Canada
>
Image