Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder 2 Preview » View Thread |
Messages 1 to 10 of 10 total |
External code interface changed? |
Fri, May 1 2015 7:52 AM | Permanent 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 PM | Permanent 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' 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 PM | Permanent 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 AM | Permanent Link |
Chris Holland SEC Solutions Ltd. 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 AM | Permanent Link |
Chris Holland SEC Solutions Ltd. 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 AM | Permanent 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 > |
This web page was last updated on Wednesday, March 27, 2024 at 05:29 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |